AMPLIACIÓN DE
SISTEMAS OPERATIVOS
,
AMPLIACION DE
SISTEMAS OPERATIVOS
José Manuel Díaz Martínez
sanz y torres
MARCAS REGISTRADAS. Los nombres de los productos (hardware, software, sistemas operativos, etc.)
que aparecen en este libro pueden ser marcas registradas por sus fabricantes. El autor ha utilizado
exclusivamente estos nombres con el propósito de identificar los productos y sin intención de infringir
las marcas ni perjudicar a los propietarios de sus derechos.
AMPLIACIÓN DE SISTEMAS OPERATIVOS
Todos los derechos reservados. Queda prohibida, salvo excepción prevista en la ley, cualquier forma
de reproducción, distribución, comunicación pública y transformación de esta obra sin contar con la
autorización de los autores yjo editores. La infracción de los derechos mencionados puede ser cons­
titutiva de delito contra la propiedad intelectual.
© José Manuel Díaz Martínez
© EDITORIAL SANZ Y TORRES, S. L.
cj Pinos Alta, 49 - 28029 Madrid
� 902 400 415 - 91 314 55 99
www.sanzytorres.com
libreria@sanzytorres.com
www.sanzytorres.com/editorial
editorial@sanzytorres.com
ISBN: 978-84-15550-17-4
Depósito legal: M-26492-2012
Portada:
Masterline. S. L. cj Las Minas, 1, 28250 Torrelodones (Madrid)
Composición:
Autor
Impresión:
Jacaryan, S. A., Avda. Pedro Díez, 3, 28019 Madrid
Encuadernación:
Felipe Méndez, S. A., cj Del Carbón, 6 y 8, Poi. lnd. San José de Valderas 2, 28918 Leganés (Madrid)
"
Indice general
Prefacio
XIII
Lista de acrónimos y abreviaturas
XIX
l. Sistemas Operativos Basados en UNIX (SOBUNIX): introducción general
1.1.
1 .2.
1 .3.
1 .4.
1 .5 .
1 .6.
1 .7 .
1 .8 .
l. 9.
1 . 1 O.
1.11.
Introducción . . . . . . . . . . . . . . .
Cronología histórica de los SOBUNIX . . . .
Compatibilidad entre los SOBUNIX . . . . .
Características principales de los SOBUNIX .
Interfaces con los usuarios disponibles e n SOBUNIX
1 .5. 1 . Intérpretes de comandos . . .
1 .5.2. Interfaces de usuario gráficas . . . . . . . .
1 . 5 . 3 . Llamadas al sistema . . . . . . . . . . . .
Introducción a la gestión de archivos en SOBUNIX
Seguridad y protección en SOBUNIX .
l.7 .l. Identificadores reales . . . . . .
1 .7 .2. Máscara de modo de un archivo
1 .7 . 3 . Identificadores efectivos . . . .
l.7 .4. Implementación de la seguridad
Resumen . . . . . . .
Lecturas recomendadas
Autoevaluación
Ejercicios . . . . . . .
2. SOBUNIX: implementación y control de procesos multihilos
2. 1 . Introducción . . . . . . . . . . . . . . . . . . . . . . . . .
2.2. Implementación de los procesos multihilos en SOBUNIX .
2.2. 1 . Conceptos fundamentales . . . . . . . . . . . . .
2.2.2. Estructuras de datos asociadas a los procesos multihilos
2.3. Control de procesos multihilos en SOBUNIX . . . . . . . . . .
VII
1
2
2
5
5
7
7
19
22
23
25
25
27
32
33
35
36
37
40
45
46
46
46
49
56
Ampliación de sistemas operativos
vm
20 30 1 . Creación de procesos e invocación de otros programas
20 3020 Terminación de procesos
20 30 30 Notificación de eventos: señales
20 3 .40 Control de hilos de usuario: librerías de hilos
20 3050 Grupos de procesos y sesiones
20 3060 El sistema de archivos procfs
Resumen
Lecturas recomendadas
Autoevaluación
Ejercicios
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
56
63
67
76
79
81
84
85
85
88
o
2.40
20 50
2060
2070
o
o
o
o
o
o
o
o
o
o
o
o
o
o
3. SOBUNIX: planificación, sincronización y mecanismos IPC
93
30 1 . Introducción
3020 Planificación de procesos multihilos en SOBUNIX
3020 1 . Características generales
302020 Dos ejemplos ilustrativos de la planificación en SOBUNIX
302030 Expropiación del procesador
30 30 Mecanismos de sincronización del núcleo en SOBUNIX
30 30 1 . Cerrojos
30 3020 Semáforos
3.40 Dormir/despertar y colas de hilos dormidos en S OBUNIX
3050 Mecanismos de comunicación entre procesos en SOBUNIX
3050 1 . Mecanismos IPC del System V
30 5020 Otros mecanismos IPC
3060 Resumen
3 7 Lecturas recomendadas
3080 Autoevaluación
3090 Ejercicios
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
94
94
94
95
1 09
1 10
111
1 13
1 16
1 18
1 19
133
135
136
136
1 38
o
o
4. SOBUNIX: administración de memoria
143
40 1 . Introducción
4020 Gestión del espacio de direcciones virtuales de un proceso en
SOBUNIX
40 20 1 . Organización del espacio de direcciones virtuales de un proceso
402020 Mapeado de archivos en memoria
402030 Estructuras de datos gestionadas por el núcleo asociadas al espacio de direcciones virtuales de un proceso
402.40 Memoria anónima
402050 Memoria compartida
40 20 60 Operaciones sobre el espacio de direcciones virtuales de un proceso
402070 Creación del espacio de direcciones virtuales de un proceso
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
1 44
1 45
1 45
1 48
1 52
1 55
1 57
1 59
1 60
Índice general
4.3. Traducción de direcciones virtuales a direcciones físicas en
SOBUNIX . . . . . . . . . . . . . . . . . .
4. 3 . 1 . Tablas de páginas y MMU . . . . .
4.3.2. Tratamiento de los fallos de página
4.4. Gestión de la memoria física en SOBUNIX
4.4. 1 . Estructuras de datos utilizadas en la gestión de la memoria física .
4.4.2. Reemplazamiento de páginas . . .
4.4. 3 . Intercambio de procesos . . . . . . . .
4.4.4. Asignación de memoria principal . . .
4. 5 . Gestión del área d e intercambio en SOBUNIX .
4. 6. Gestión de la memoria perteneciente al núcleo en SOBUNIX
4.6. 1 . Espacio de direcciones virtuales del núcleo
4.6.2. Asignación de la memoria del núcleo
4.7. Resumen . . . . . . .
4.8 . Lecturas recomendadas
4. 9. Autoevaluación
4. 1 0. Ejercicios . . . . . . .
161
161
1 65
1 66
1 66
1 68
171
1 72
173
1 77
1 77
1 78
18 1
182
18 2
184
5. SOBUNIX: gestión de archivos y gestión de la E/S
5. 1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2. Gestión de archivos en SOBUNIX: características principales y
llamadas al sistema
5 .2. 1 . Archivos .
5. 2.2. Directorios
5 . 2 . 3 . Enlaces . .
5 .2.4. Sistemas de archivos
5. 3 . Capa nodo virtual/sistema de archivos virtual
5 . 3 . 1 . Nodos virtuales . . . . . . . . . . . .
5 . 3 .2. S istemas de archivos virtuales . . . .
5 . 3 . 3 . Análisis d e nombres de rutas en SOBUNIX
5.4. El sistema de archivos UFS . . . . . . . . . . . .
5 .4. 1 . Características principales . . . . . . . .
5 .4.2. Estructura de un sistema de archivos UFS
5 .4. 3 . Implementación de directorios e n UFS .
5 .4.4. Gestión de un sistema UFS .
5 . 5 . Gestión d e la E/ S e n SOBUNIX
5 . 5 . 1. Perspectiva general . . .
5.5.2. Archivos de dispositivos
5 . 5 . 3 . Subsistema de E/ S . .
5 .5.4. Drivers de los dispositivos de E/ S
5 . 5 . 5 . Tratamiento d e las interrupciones
.
IX
187
•
•
o
o
o
o
o
o
187
18 8
188
1 95
1 97
200
202
203
206
208
209
209
210
21 1
212
216
216
217
219
220
22 1
x
Ampliación de sistemas operativos
5.6.
5. 7.
5.8 .
5.9.
5. 10.
Conectores . . . . . .
Resumen . . . . . . .
Lecturas recomendadas
Autoevaluación
Ejercicios . . . . . . .
6. SOBUNIX: el sistema operativo Linux
6. 1 . Introducción . . . . . . . . . . . . .
6.2. Consideraciones generales sobre Linux .
6.2. 1 . Orígenes de Linux . . . . . .
6.2.2. Versiones del núcleo de Linux
6.2.3. Distribuciones Linux . . . . .
6 . 3 . Gestión de procesos e hilos en Linux .
6.3. 1 . Estructuras del núcleo asociadas a las tareas .
6.3.2. Creación de procesos e hilos en Linux
6 . 3 . 3 . Hilos del núcleo en Linux . . . . . . . . . .
6.4. Planificación en Linux . . . . . . . . . . . . . . . .
6.4. 1 . Planificador usado en las versiones del núcleo de Linux anteriores a la 2.6.23
6.4.2. Planificador utilizado a partir de la versión 2.6.23 del núcleo de Linux
6.5. Gestión de memoria en Linux . . . . . . . . . . . .
6.5. 1 . Gestión del espacio de direcciones virtuales
6.5.2. Gestión de la memoria física . . . . . . . .
6.6. Gestión de archivos en Linux . . . . . . . . . . . .
6.6. 1 . Implementación de la capa nodo virtual/sistema de archivos virtual en Linux
6.6.2. El sistema de archivos EXT2 .
6.6. 3 . E l sistema d e archivos EXT3 .
6.6.4. El sistema de archivos EXT4 .
6. 7. Resumen . . . . . . .
6.8 . Lecturas recomendadas
6.9. Autoevaluación
6. 1 O. Ejercicios
. . . . . .
.
7. El sistema operativo MS-DOS
7 . 1 . Introducción . . . . . . . . . . . . . . . . .
7.2. Consideraciones generales sobre MS-DOS .
7.2. 1 . Cronología histórica . . . . . . . .
7.2.2. Características principales de MS-DOS
7.2.3. Estructura del sistema operativo MS-DOS .
7.2.4. Llamadas al sistema .
7.2.5. Arranque de MS-DOS
7.2.6. Interfaz con el usuario
222
224
226
226
229
231
23 1
232
232
232
233
233
234
239
240
24 1
242
247
250
250
252
26 1
26 1
263
267
268
269
270
270
272
273
274
274
274
275
276
277
278
279
Índice general
7.3. Implementación y control de procesos en MS-DOS
7 . 3 . 1 . Creación y ejecución de un proceso
7.3 .2. Terminación de un proceso .
7.4. Gestión de memoria en MS-DOS .
7.5. Gestión de archivos en MS-DOS
7 . 5 . 1 . Archivos . . . . . .
7.5.2. Directorios . . . . .
7 . 5 . 3 . Sistemas de archivos
7.6. El sistema de archivos FAT .
7.6. 1 . Estructura de un sistema FAT
7.6.2. Implementación de directorios en un sistema FAT .
7 . 6 . 3 . Localización d e los clusters de datos d e u n archivo en u n sistema FAT
7.7. Gestión de la E/S en MS-DOS . . .
7.7. 1 . Subsistema de E/S . . . . . .
7.7.2. Drivers de dispositivos E/S . .
7 . 7 . 3 . Manej adores de interrupciones
7.8 . Resumen . . . . . . .
7.9. Lecturas recomendadas
7. 1 O. Autoevaluación
7. 1 1 . Ejercicios . . . . . . .
8. El sistema operativo Windows
8 . 1 . Introducción . . . . . . . .
8 .2. Consideraciones generales sobre Windows .
8 .2. 1 . Cronología histórica . . . . . . . .
8 .2.2. Características principales de Windows
8 .2.3. Estructura del sistema operativo Windows .
8 .2.4. Implementación de la API Win32 .
8 .2.5. Interfaz con el usuario de Windows
8 .2.6. Llamadas al sistema en Windows
8 .2.7. El registro de Windows .
8 .2.8 . Arranque de Windows
8 .2.9. Objetos del núcleo . . .
8 .2. 1 0. Seguridad en Windows .
8 .3 . Implementación, control y planificación de procesos multihilos en Windows
8 . 3 . 1 . Implementación de los procesos multihilos en Windows
8 .3.2. Control de procesos multihilos en Windows . . . . . . . . . .
8 . 3 . 3 . Planificación de procesos multihilos en Windows . . . . . . .
8 .4. Sincronización y comunicación entre procesos multihilos en Windows
8 .4. 1 . Mecanismos de sincronización usados por el sistema operativo
8 .4.2. Mecanismos de sincronización entre procesos multihilos disponibles en Windows
XI
28 3
28 3
28 4
28 4
28 7
28 7
28 9
28 9
290
290
29 1
292
292
292
294
294
295
2 96
296
297
299
300
300
300
302
303
305
306
307
308
3 10
3 10
311
313
313
316
319
325
325
325
XII
Ampliación de sistemas operativos
8 .4.3. Mecanismos de comunicación entre procesos multihilos disponibles en Windows
8 .5 . Gestión de memoria en Windows . . .
8 .5 . 1 . Administrador de memoria . .
8 . 5.2. Gestión de la memoria virtual
8 .5 . 3 . Traducción de direcciones . .
8 .5.4. Gestión de la memoria física .
8 .5 . 5 . Respaldo d e páginas e n memoria secundaria .
8 .6. Gestión de archivos en Windows . . . . . . . . . . .
8 . 6. 1 . Funciones de l a API Win32 asociadas a l a gestión de archivos y directorios
8 .6.2. Sistemas de archivos . . .
8 .7. El sistema de archivos NTFS . . . . . . . . . . . .
8 .7. 1 . Características principales . . . . . . . . .
8 .7.2. Estructura en el disco de un sistema NTFS
8 .7 . 3 . Estructura d e un directorio e n NTFS . . . .
8 .7 .4. Localización de archivos en un sistema NTFS .
8 .8 . Gestión de E/S en Windows . . . . . . . .
8 .8 . 1 . Subsistema de E/S . . . . . . . . . . .
8 .8 .2. Drivers de dispositivos en Windows . .
8 .8 . 3 . Gestión d e interrupciones e n Windows .
8 .9. Resumen . . . . . . .
8 . 10. Lecturas recomendadas
8 . 1 1 . Autoevaluación
8 . 1 2. Ejercicios . . . . . . .
327
328
328
329
332
335
338
339
339
340
341
341
344
348
349
35 1
35 1
352
354
356
358
358
361
A. Soluciones completas de los ejercicios
A . 1 . Soluciones ejercicios capítulo 1 .
A.2. Soluciones ejercicios capítulo 2 .
A . 3 . Soluciones ejercicios capítulo 3 .
A.4. Soluciones ejercicios capítulo 4 .
A.5. Soluciones ejercicios capítulo 5 .
A.6. Soluciones ejercicios capítulo 6 .
A.7. Soluciones ejercicios capítulo 7 .
A.8 . Soluciones ejercicios capítulo 8 .
363
Bibliografía
401
Índice alfabético
403
363
375
38 0
38 7
38 9
392
395
397
Prefacio
Sobre el autor
José Manuel Díaz Martínez es profesor titular de universidad en el Departamento de Informática
y Automática de la Escuela Técnica Superior de Ingeniería Informática de la Universidad Nacional de
Educación a Distancia (UNED). Desde el año 2001 imparte docencia en asignaturas relacionadas con
la materia Sistemas Operativos. Asimismo ha escrito diferentes materiales para el aprendizaje de esta
materia entre ellos el libro [Díaz et al., 2011].
A quién va dirigido este libro
Este libro está concebido para ser la bibliografía básica de la asignatura Ampliación de Sistemas
Operativos que se imparte en el tercer curso del Grado en Ingeniería en Tecnologías de la Información
de la UNED. Asimismo puede resultar de utilidad a estudiantes de Escuelas de Ingenierías o Facultades
de Ciencia que tengan en sus planes de estudio asignaturas relacionadas con los sistemas operativos. Por
supuesto este libro también puede ser utilizado por cualquier persona interesada en esta materia.
Objetivos
En el Grado en Ingeniería en Tecnologías de la Información de la UNED la materia Sistemas Opera­
tivos se diversifica en dos asignaturas: Sistemas Operativos y Ampliación de Sistemas Operativos. En la
asignatura Sistemas Operativos que se imparte en el segundo curso se adquieren los fundamentos básicos
de los sistemas operativos: descripción y control de procesos, planificación de procesos, comunicación
y sincronización de procesos, interbloqueo, administración de memoria, memoria virtual, gestión de la
E/S, gestión de archivos y seguridad y protección.
Por otra parte en la asignatura Ampliación de Sistemas Operativos que se imparte en el tercer curso
se pretende consolidar y practicar con los fundamentos básicos de los sistemas operativos adquiridos en
la asignatura Sistemas Operativos. Para lograr este objetivo en esta asignatura se estudian los sistemas
operativos basados en UNIX (BSD, System V, Solaris, Linux, etc) y los sistemas operativos MS-DOS y
Windows. Este estudio se realiza tanto desde un punto de vista interno, describiendo las características
principales del núcleo de estos sistemas operativos, como desde un punto de vista externo, describiendo
y practicando con las llamadas al sistema y comandos disponibles en estos sistemas operativos.
xm
Ampliación de sistemas operativos
XIV
_
__
___
----------
Este libro tiene como objetivo fundamental explicar, de la forma más clara posible, las características
internas y externas de los Sistemas Operativos Basados en UNIX (SOBUNIX) y de los sistemas opera­
tivos MS-DOS y Windows. Como resultado del estudio y aprendizaje de los contenidos de este libro el
estudiante será capaz de:
•
Conocer las características generales de los SOBUNIX.
•
Conocer los comandos básicos de los intérpretes de comandos de los SOBUNIX.
•
Conocer las principales llamadas al sistema disponibles en los SOBUNIX.
•
Conocer la implementación y control de los procesos multihilos de los SOBUNIX.
•
Conocer la planificación de procesos multihilos, los mecanismos de sincronización del núcleo y
los mecanismos IPC de los SOBUNIX.
•
Saber cómo se realiza la administración de memoria en los SOBUNIX.
•
Saber cómo se realiza la gestión de archivos y la gestión de la E/S en los SOBUNIX.
•
Conocer las particularidades del sistema operativo Linux.
•
Conocer las características generales del sistema operativo MS-DOS .
•
Conocer los comandos básicos del intérprete de comandos de MS-DOS .
•
Conocer la implementación y control de los procesos en MS-DOS .
•
Saber cómo se realiza la administración de memoria en MS-DOS .
•
Conocer cómo se realiza la gestión de archivos y la gestión de la E/S en MS-DOS .
•
Conocer las características generales del sistema operativo Windows.
•
Conocer los principales llamadas al sistema del sistema Windows.
•
Conocer la implementación, control y planificación de los procesos multihilos en Windows.
•
Conocer los mecanismos de sincronización del núcleo y los mecanismos de comunicación entre
procesos de Windows.
•
Saber cómo se realiza la administración de memoria en Windows.
•
Saber cómo se realiza la gestión de archivos y la gestión de la E/ S en Windows.
Prefacio
xv
(�onocimientos previos necesarios
Para comprender adecuadamente los contenidos de este libro es necesario conocer los fundamentos
básicos de la materia Sistemas Operativos: [Silberschatz et. al, 2002] , [Stallings, 2005] , [Tanenbaum ,
2009 ] y [Díaz et al., 20 1 1 ] . También es necesario tener conocimientos básicos de programación en C :
1 Kernighan y Ritchie, 199 1 ] y [Gottfried, 2005] .
Organización
Los contenidos de este libro se organizan en ocho capítulos. Conviene señalar que en la organización
propuesta se ha tenido en cuenta el hecho de que muchos SOBUNIX son de código abierto a diferencia
de MS-DOS y Windows que son de código cerrado. Por ello se ha preferido dedicar más de la mitad
del libro al estudio de los S OBUNIX, ya que el estudiante interesado podrá acceder al código fuente de
diversos miembros de esta familia de sistemas operativos.
En el capítulo 1 se realiza una introducción a los SOBUNIX. En primer lugar se comentan la cro­
nología histórica , la compatibilidad y las características principales de los SOBUNIX. En segundo lugar
se describen los interfaces con los usuarios disponibles en los SOBUNIX. En tercer lugar se realiza una
introducción a la gestión de archivos en SOBUNIX. Finalmente, se describe como se implementa la
seguridad y la protección en los SOBUNIX.
El capítulo 2 está dedicado la implementación y control de procesos multihilos en los SOBUNIX . En
la primera parte del capítulo se trata la implementación de los procesos multihilos: conceptos fundamen­
tales y principales estructuras de datos. En la segunda y última parte se trata el control de los procesos
multihilos: creación, invocación y terminación de procesos, notificación de eventos mediante señales,
librerías de hilos, grupos de procesos y sesiones, y el sistema de archivos procfs.
El capítulo 3 está dedicado a la planificación, sincronización y mecanismos IPC de los SOBUNIX.
En la primera parte del capítulo se describen las características generales de la planificación de procesos
multihilos. En esta parte, a modo de ejemplo, se estudia la implementación de la planificación de dos
SOBUNIX ilustrativos : BSD 4.3 y Solaris. Posteriormente se incluyen diferentes consideraciones sobre
la expropiación del procesador. En la segunda parte del capítulo se describen los principales mecanismos
de sincronización del núcleo de los SOBUNIX: cerrojos y semáforos. También se incluyen algunas
consideraciones sobre la implementación de las operaciones de dormir y despertar y sobre las colas
de procesos o hilos dormidos. En la tercera y última parte se describen los principales mecanismos
IPC disponibles en los SOBUNIX: los mecanismos IPC del System V (semáforos, colas de mensajes y
memoria compartida), las señales y las tuberías.
El capítulo 4 está dedicado a la administración de memoria en los SOBUNIX. En primer lugar se
estudia la gestión del espacio de direcciones virtuales de un proceso. En segundo lugar se describe la tra­
ducción de direcciones virtuales a direcciones físicas. En tercer lugar se analiza la gestión de la memoria
física . En cuarto lugar se describe la gestión del área de intercambio. Finalmente se describe la gestión
de la memoria del propio núcleo.
El capítulo 5 está dedicado al estudio de la gestión de archivos y la gestión de la E/S en los SO­
BUNIX. En primer lugar se explican las características principales de los archivos, los directorios, los
XVI
Ampliación de sistemas operativos
enlaces y los sistemas de archivos en los SOBUNIX. Asimismo se enumeran y describen las principales
llamadas al sistema disponibles en los SOBUNIX para la gestión de estos elementos. En segundo lugar
se describe la capa nodo virtual/sistema de archivos virtual utilizada en la mayoría de los SOBUNIX
modernos para poder soportar diferentes tipos de sistemas de archivos. En tercer lugar se explica cómo
se analizan los nombres de rutas en los SOBUNIX. En cuarto lugar se describe el sistema de archivos
UFS , el cual es utilizado en diversos SOBUNIX. En cuarto lugar se describe la gestión de la E/S en
los SOBUNIX. El capítulo finaliza con una introducción a los conectores que son uno de los principales
mecanismos utilizados en S OBUNIX para implementar las conexiones en red.
El capítulo 6 está dedicado al estudio de las particularidades del sistema operativo Linux, uno de los
miembros más populares de la familia de SOBUNIX. En primer lugar se incluyen una serie de conside­
raciones generales sobre Linux. En segundo lugar se describe el modelo de proceso multihilo utilizado
en Linux. En tercer lugar se estudia la planificación de procesos multihilos en Linux. En cuarto lugar
se estudia la implementación de la gestión de memoria. Finalmente se estudian los sistemas archivos
nativos de Linux: EXT2, EXT3 y EXT4.
El capítulo 7 está dedicado al estudio del sistema operativo MS-DOS . En primer lugar se realizan
una serie de consideraciones generales. En segundo lugar se describen la implementación y el control
de procesos. En tercer lugar se estudia la gestión de memoria. En cuarto lugar se estudia la gestión de
archivos y el sistema de archivos FAT- 1 2. Finalmente se estudia la gestión de la E/S.
El capítulo 8 está dedicado al estudio del sistema operativo Windows. En primer lugar se realizan
una serie de consideraciones generales sobre Windows. En segundo lugar se describe la implementación,
control y planificación de procesos multihilos. En tercer lugar se estudian los mecanismos de sincroniza­
ción del núcleo y los mecanismos IPC. En cuarto lugar se estudia la gestión de memoria. En quinto lugar
se describe la gestión de archivos y el sistema de archivos NTFS . Finalmente se estudia la gestión de la
E/S .
E l libro también contiene u n apéndice A en el que s e incluyen las soluciones completas de los ejer­
cicios incluidos al final de cada capítulo, la mayoría de los cuales han sido propuestos en exámenes.
Cómo usar el libro
Este libro está pensado para la educación a distancia, por ello sus contenidos han sido organizados
y seleccionados para un aprendizaje progresivo y secuencial. Además se incluyen bastantes figuras y
ejemplos que ayudan a comprender los contenidos expuestos.
Por otra parte, el estudiante dispone de cuestiones de autoevaluación y de las soluciones de todos
los ejercicios para poder comprobar si efectivamente ha asimilado los contenidos y ha alcanzado los
objetivos marcados.
Todos los capítulos tienen una estructura uniforme. En primer lugar, se enumeran los objetivos do­
centes del capítulo. En segundo lugar, se realiza una introducción a los contenidos del capítulo. En tercer
lugar, se incluyen los contenidos propiamente dichos. En cuarto lugar, se realiza un resumen de los con­
tenidos, el cual ayuda a fijar los contenidos más importantes. En quinto lugar, se incluyen las lecturas
recomendadas. En sexto lugar, se incluyen las cuestiones de autoevaluación, a través de las cuales el estu­
diante puede establecer el grado de asimilación de los contenidos y deducir qué contenidos debe repasar.
Prefacio
XVII
Jiinalmente, se plantean varios ejercicios con los que practicar o ampliar los contenidos aprendidos . Se
recomienda intentar hacer cada ejercicio antes de mirar su solución en el apéndice A.
Sobre las unidades de almacenamiento de la información usadas en este libro
La unidades básicas de almacenamiento u organización de la información son el bit (símbolo b) y el
O o un 1 , que se utiliza para representar una
pareja de posibles estados, por ejemplo: encendido y apagado, presente y ausente, etc. Un byte son ocho
bits contiguos. En la siguiente tabla se incluyen los prefijos que se utilizan en este texto para especificar
los múltiplos de las unidades anteriores, de acuerdo con el SI y el estándar 1 54 1 del IEEE.
byte (símbolo B). Un bit es un dígito binario, es decir, un
Prefijo
kibi
kilo
mebi
mega
gibi
giga
tebi
tera
pebi
peta
exbi
exa
Símbolo
Ki
k
Mi
M
Gi
G
Ti
T
Pi
Valor
21U
10
3
220
1 06
230
10
9
240
1 01
2
250
p
1 01 5
Ei
E
1
10 8
260
Sistema de unidades
IEEE 1 54 1
SI
IEEE 1 54 1
SI
IEEE 1 54 1
SI
IEEE 1 54 1
SI
IEEE 1 54 1
SI
IEEE 1 54 1
SI
Contacto con el autor: envío de erratas, comentarios y sugerencias
Pese al esfuerzo realizado por explicar lo mej or posible los contenidos incluidos en este libro y evitar
la existencia de erratas el autor es consciente de que seguramente habrá fracaso en su objetivo, por este
motivo estará encantado de recibir en la dirección
a s o@di a . uned . e s
todas las erratas, comentarios y sugerencias que los lectores deseen enviar. Además en la página web
h t tp: / / www . uned . e s / 7 1 0 2 3 0 1 6 /ma t e r i a l e s . html
se irán recopilando todas las erratas que se vayan detectando así como las aclaraciones a los contenidos
del libro que sean necesarias.
Lista de acrónimos y abreviaturas
ALPCs
APC
API
ASCII
BCPL
BIOS
BSD
BSS
CD
CDE
CFS
CPU
DACL
DLL
DPC
DVD
E/S
EFS
EGID
EMS
EUID
EXT
EXT2
EXT3
EXT4
FAT
FCB
FFS
FIFO
FSD
GDI
Advanced Local Procedure Calls
Asynchronous Procedure Call
Application Program Interface
American Standard Code for Information
Interchange
Basic Combined Programming Language
Basic Input-Output System
Berkeley Software Distribution
Block Started by Symbol
Compact Disc
Common Desktop Environment
Completely Fair Scheduling
Central Processing Unit
Discretionary Access Control List
Dynamic Link Library
Deferred Procedure Call
Digital Versatile Disc
Encryption File System
Effective Group IDentifier
Expanded Memory Specifications
Effective U ser IDentifier
EXTended filesystem
Second EXTended filesystem
Third EXTended filesystem
Fourth EXTended filesystem
File Allocation Table
File Control B lock
Fast File System
First Input - First Output
File System Driver
Graphics Device Interface
XIX
Llamadas a procedimientos locales avanzados
Llamadas a procedimientos asíncronos
Interfaz de programas de aplicación
Código estándar americano para el intercam­
bio de información
Lenguaje de programación combinado básico
Sistema básico de Entrada/Salida
Distribución de software de B erkeley
B loque inicializado con símbolos
Disco compacto
Entorno de escritorio común
Planificación completamente j usta
Unidad central de procesamiento
Lista de acceso discrecional
Librería de enlace dinámico
Llamadas a procedimientos aplazados
Disco versátil digital
Entrada/Salida
Encriptación del sistema de archivos
Identificador de grupo efectivo
Especificaciones de memoria expandida
Identificador de usuario efectivo
Sistema de archivos extendido
Segundo sistema de archivos extendido
Tercer sistema de archivos extendido
Cuarto sistema de archivos extendido
Tabla de asignación de archivos
B loque de control del archivo
S istema de archivos rápido
Primero en entrar primero en salir
Driver del sistema de archivos
Interfaz de dispositivos gráficos
XX
Ampliación de sistemas operativos
GID
GNU
GPL
GUI
HAL
HAT
IFS
IP
IPC
IRP
IRQL
KDE
LPC
LRU
LSI
LWPID
MFT
MIT
MMU
M S-DOS
msgid
MULTICS
mutex
NFS
NTFS
NUMA
Nodo-i
Nodo-s
Nodo-v
npi
OSF
PAE
PCs
PEB
PID
PFRA
PGID
PnP
POS IX
procfs
PSP
R/W
RAM
RFS
Group IDentifier
GNU is Not Unix
General Public License
Graphical U ser Interface
Hardware Abstraction Layer
Hardware Address Translation
Installable File System
Internet Protocol
InterProcess Communications
1/0 Request Packet
Interrupt Request Level
K Desktop Environment
Local Procedure Call
Least Recently U sed
Large S cale lntegration
LightWeight Process IDentifier
Master File Table
Massachusetts Institute of Technology
Memory Management Unit
MicroSoft-Disk Operating System
Message queue identification
MULTiplexed Information and Computing
Service
mutual exclusion
Network File System
New Technology FileSystem
Non-Uniform Memory Access
Open Software Foundation
Physical Address Extension
Personal Computers
Process Environment Block
Process IDentifier
Page Frame Reclaiming Algoritm
Process Group IDentifier
Plug-and-Play
Portable Operating System Interface based
on UNIX
process file system
Program Segment Prefix
Reader/Wri ter
Random Access Memory
Remote File Sharing
Identificador de grupo
GNU No es Unix
Licencia pública general
Interfaz de usuario gráfica
Capa de abstracción del hardware
Traducción de direcciones hardware
Sistemas de archivos instalables
Protocolo de Internet
Comunicaciones entre procesos
Paquete de petición de E/ S
Nivel de petición de interrupción
Entorno de escritorio K
Llamada a procedimiento local
Usada menos recientemente
Integración a gran escala
Identificación de proceso ligero
Tabla de archivos maestra
Instituto Tecnológico de Massachusetts
Unidad de gestión de memoria
Sistema operativo de disco de Microsoft
Identificación de la cola de mensajes
Servicio de cálculo e información multiplexada
exclusión mutua
Sistema de archivos en red
Sistema de archivos de tecnología nueva
Acceso a memoria no uniforme
Nodo índice
Nodo sombra
Nodo virtual
Nivel de prioridad de la interrupción
Fundación de software abierto
Extensión de dirección física
Computadores personales
Bloque de entorno del proceso
Identificador de proceso
Algoritmo de reclamo de marcos de página
Identificador de grupo de procesos
Conectar y usar
Interfaz de sistema operativo portable basada
en UNIX
sistema de archivos de procesos
Prefijo del segmento del programa
Lector/Escritor
Memoria de acceso aleatorio
Compartición de archivos remotos
Lista de acrónimos y abreviaturas
ROM
RPCs
S5FS
SAV
SAM
SCB
semid
SFT
shmid
SI
SID
SOBUNIX
SUA
Read Only Memory
Remote Procedure Calls
System V FileSystem
sus
Single UNIX Specification
Transmission Control Protocol
Thread Environment Block
Thread Group IDentifier
Task IDentifier
Translation Lookaside Buffer
Terminate and Stay Resident
U ser Datagram Protocol
UNIX File System
User IDentifier
Uniform Memory Access
Universal Serial Bus
Virtual Address Descriptor
Virtual File System
Virtual Memory
Windows Driver Model
Extended Memory Specifications
TCP
TEB
TGID
TID
TLB
TSR
UDP
UFS
UID
UMA
USB
VAD
VFS
VM
WDM
XMS
Security Account Manager
Stream Control Block
Semaphore identification
System File Table
Shared memory identification
Le Systéme International d'Unités
Session IDentifier
Subsystem for Unix-based Applications
XXI
Memoria de sólo lectura
Llamadas a procedimientos remotos
Sistema de archivos del S ystem V
Sistema de Archivos Virtual
Administrador de cuentas de seguridad
B loque de control del flujo
Identificación del semáforo
Tabla de archivo del sistema
Identificación de la memoria compartida
S istema Internacional de unidades
Identificador de sesión
Sistemas Operativos Basados en UNIX
Subsistema para aplicaciones basadas en
UNIX
Especificación única de UNIX
Protocolo de control de transmisión
Bloque de entorno del hilo
Identificador de grupo de hilos
Identificador de tarea
Buffer de traducción de vista lateral
Terminar y permanecer residente
Protocolo datagrama de usuario
Sistema de archivos UNIX
Identificador de usuario
Acceso a memoria uniforme
Bus universal en serie
Descriptor de direcciones virtuales
Sistema de archivos virtual
Memoria virtual
Modelo de drivers de Windows
Especificaciones de memoria extendida
Capítulo 1
Sistemas Operativos Basados en UNIX
(SOBUNIX): introducción general
Objetivos docentes
Los objetivos docentes de este capítulo son los siguientes :
•
Conocer el origen y la evolución del sistema operativo UNIX y de los principales Sistemas Ope­
rativos Basados en UNIX (SOBUNIX).
•
Saber cuáles son los principales estándares de compatibilidad soportados por los SOBUNIX.
•
Conocer las características principales de los SOBUNIX.
•
Conocer el funcionamiento y la implementación de las interfaces de usuario de los SOBUNIX:
interfaz de línea de comandos (intérpretes de comandos) e interfaz gráfica.
•
Conocer las principales acciones que de forma general realiza el núcleo de un SOBUNIX para
atender una llamada al sistema.
•
Conocer los comandos básicos asociados a la gestión de archivos y directorios disponibles en los
intérpretes de comandos de los SOBUNIX.
•
Conocer la estructura básica y las características de los archivos de comandos (shell scripts) de los
SOBUNIX.
•
Conocer los conceptos de objeto de archivo abierto, descriptor de archivo y nodo virtual (nodo-v).
•
Saber cómo se implementa la seguridad y la protección en los SOBUNIX.
1
2
Ampliación de sistemas operativos
1.1.
Introducción
El sistema operativo UNIX nacido a principios de los años setenta ha sido tomado como base de un
gran número de sistemas operativos. En este texto se usará el término SOBUNIX para referirse tanto al
UNIX original como a los diferentes Sistemas Operativos Basados en UNIX.
En este primer capítulo se realiza una introducción general a los SOBUNIX. En primer lugar se
describen la cronología histórica, los estándares de compatibilidad y las principales características de
los S OBUNIX. En segundo lugar se describe el funcionamiento y la implementación de los dos tipos
de interfaz de usuario disponibles en los SOBUNIX: interfaz de línea de comandos e interfaz gráfica.
Además se comentan las acciones que de forma general realiza el núcleo de un SOBUNIX para atender
las llamadas al sistema.
En el caso de la interfaz de línea de comandos se define qué es un intérprete de comandos, se enu­
meran los principales tipos de intérpretes de comandos, se analiza la estructura de los comandos, se
introducen algunos comandos básicos asociados a la gestión de archivos y directorios, se explica qué
son las variables del intérprete de comandos y las variables de entorno, y se explica qué son, cómo se
construyen y cómo se ejecutan los archivos de comandos (shell scripts). En el caso de las interfaces de
usuario gráficas (Graphical U ser Interfaces, GUis) de los SOBUNIX, se describe el sistema X Windows,
las librerías widgets toolkits y los entornos de escritorio.
En tercer lugar se realiza una breve introducción a la gestión de archivos en los SOBUNIX para
presentar los conceptos de objeto de archivo abierto, descriptor de archivo y nodo virtual (nodo-v), los
cuales se utilizan en los siguientes capítulos.
Finalmente se describen los elementos que de forma general utilizan los SOBUNIX para implementar
la seguridad y la protección de los datos de los usuarios: los identificadores reales, los identificadores
efectivos y la máscara de modo de un archivo.
1.2.
Cronología histórica de los SOBUNIX
A finales de los años 60 los laboratorios Bell propiedad de AT&T, General Electric y el MIT cola­
boraron para desarrollar el sistema operativo de tiempo compartido MULTIC S . Las primeras versiones
de este sistema operativo tuvieron un rendimiento deficiente y su éxito comercial fue escaso. Por estos
motivos, entre otros, los laboratorios Bell decidieron desvincularse del proyecto; aunque mantuvieron a
Ken Thompson, uno de los programadores de Bell que había colaborado en MULTICS, pendiente del
proyecto.
Thompson por iniciativa propia decidió escribir en lenguaje ensamblador una versión reducida de
MULTICS para el minicomputador PDP-7. Brian Kernighan, compañero de Thompson en Bell, con­
sideraba al sistema operativo desarrollado por Thompson una versión capada de MULTICS . Por ello,
haciendo gala de un gran sentido del humor, lo bautizó inicialmente con el nombre de UNICS . Nótese
que UNICS en inglés suena igual que la palabra inglesa eunuchs, que significa eunucos en español. Por
simplificar su escritura el nombre de UNICS fue sustituido finalmente por el nombre de UNIX.
Sistemas Operativos Basados en UNIX (SOBUNIX) : introducción general
3
Cuando los responsables de los laboratorios Bell vieron el trabajo de Ken Thompson quedaron gra­
tamente impresionados y decidieron darle apoyo económico para que portara UNIX a la familia de mini­
computadores PDP- 1 1 , bastante popular por aquella época. Puesto que programar en lenguaje ensambla­
dor es bastante tedioso, Thompson decidió que para portar UNIX a la familia PDP- 1 1 reescribiría UNIX
en un lenguaje de alto nivel. En primer lugar se decantó por utilizar el lenguaje B que el mismo había
desarrollado basándose en BCPL; pero este lenguaje tenía algunas deficiencias importantes, por ejemplo
no soportaba estructuras de datos, por lo que pronto se dio cuenta que no era el lenguaj e más apropiado.
Dennis Ritchie, otro programador de laboratorios Bell, desarrolló en 1 972 un lenguaje de progra­
mación de alto nivel al que llamó C. Además escribió un compilador de C para los minicomputadores
PDP- 1 1 . El lenguaje C [Kemighan y Ritchie, 1 99 1 ] es un lenguaje muy flexible que crea un código
bastante eficiente. Ante sus notables ventajas, Thompson decidió reescribir UNIX en C. Para esta tarea
contó con la ayuda de Ritchie. Escrito en C el código de UNIX era mucho más conciso y compacto,
además posibilitaba su portabilidad no solo a la familia PDP- 1 1 sino también a otras arquitecturas.
En 1 974 se dio a conocer públicamente la nueva versión de UNIX [Ritchie y Thompson, 1 974] . Ello
propició que muchas universidades se interesaran por este sistema operativo. Como la legislación esta­
dounidense vigente no permitía a AT &T comercializar directamente UNIX, AT &T no tuvo inconveniente
en otorgar licencias de UNIX a las universidades con fines educativos y de investigación. Las copias de
UNIX que AT &T distribuyó a las universidades incluían también su código fuente lo que propició que la
comunidad universitaria aportara sugerencias e ideas para mej orar UNIX.
El departamento de computación de la Universidad de California en Berkeley, fue mucho más lejos,
ya que modificó tanto el código fuente que desarrolló y distribuyó su propio UNIX al que llamó BSD
(Berkeley Software Distribution). Las versiones BSD 1 .0 y BSD 2.0 no modificaban el UNIX original
de AT&T simplemente consistían en aplicaciones y utilidades. Es la versión BSD 3 . 0 lanzada en 1 979
la que se considera un sistema operativo completo como tal y la que hizo que BSD se convirtiera en
un fuerte competidor del UNIX original de AT&T. Las siguientes versiones de BSD fueron BSD 4.0 en
1 98 0, BSD 4. 1 en 1 98 1 , BSD 4.2 en 1 98 3 , BSD 4.3 en 1 98 6 y BSD 4.4 en 1 993 .
Por su parte AT&T sacó la versión 7 de UNIX en 1 979, que sería la última del UNIX original con
una amplia distribución, ya que la versión 8 que se liberó en 1 98 5 y las versiones 9 y 1 O que se liberaron
a finales de los 8 0 sólo fueron adquiridas por unas pocas universidades.
Aparte de las universidades, algunas empresas fabricantes de computadores y de software también
obtuvieron licencias de UNIX y produjeron sus propias distribuciones. Un ejemplo es el sistema Xenix,
desarrollado por Microsoft Corporation y Santa Cruz Operation (SCO) a principios de los años 8 0, que
era una adaptación del UNIX versión 7 a las máquinas lntel 8 08 6. Xenix fue una de las primeras distri­
buciones comerciales de UNIX. Señalar que Microsoft centró sus esfuerzos en otros sistemas operativos
y vendió sus derechos de Xenix a SCO, con lo que el sistema operativo pasó a llamarse SCO Xenix.
Debido a la proliferación de distribuciones de UNIX, AT &T también decidió entrar en el negocio a
través de una compañía filial. Así en 1 98 1 lanzó el sistema System III, la variante comercial del UNIX
versión 7. Poco después, en 1 98 3, lanzaría el sistema System V Release 1 , o abreviadamente SVR l .
Las siguientes versiones fueron SVR2 en 1 98 4, SVR3 en 1 98 7 y SVR4 en 1 98 8 . Señalar que el sistema
System V incorporó características de otras distribuciones de UNIX, como BSD.
4
Ampliación de sistemas operativos
El conjunto de las principales distribuciones comerciales de UNIX aparecidas en la década de los
ochenta lo completan SunOS , AIX y HP-UX. El sistema SunOS de la compañía Sun Microsystems era
una adaptación de BSD para sus máquinas Sun. El que SunOS se basará en BSD y no en el UNIX de
AT&T no es casual ya que Bill Joy, uno de los socios fundadores en 1 98 2 de Sun Microsystems, era
también uno de los creadores de BSD. Conviene señalar que a partir de su versión 4.0 de 1 98 8 , debido
a un acuerdo entre S un Microsystems y AT&T, S unOS también pasó a incorporar características del
System V. De hecho, la versión 5 . 0 de SunOS , comercializada en 1 992 con el nombre de Solaris 2,
estaba basada exclusivamente en SVR4, en cuyo desarrollo también había colaborado Sun.
El sistema AIX fue distribuido por IBM y el sistema HP-UX por Hewlett-Packard. Ambos esta­
ban basados inicialmente en el sistema System III de AT&T, aunque luego se basaron en el System V
incluyendo también características de BSD.
Otros proyectos y sistemas basados en UNIX aparecidos en la década de los 8 0 y principios de los 90
que merecen ser mencionados por su importancia y porque el objetivo de su desarrollo no era el beneficio
económico son: GNU, MINIX y Linux. El proyecto GNU fue propuesto en 1 98 3 por Richard Stallman y
pretendía crear un sistema parecido a UNIX que pudiese ser distribuido libremente y que hiciese resurgir
el espíritu de colaboración desinteresada que existió a fi nales de los 70. Aunque el proyecto GNU nunca
ha llegado a crear un sistema operativo como tal, ya que en sus inicios no se llegó a escribir un núcleo
adecuado y luego optaron por Linux, si que generó diversas aplicaciones, como el compilador de C gcc
o el editor emacs, que han sido incorporadas en otros SOBUNIX. Actualmente el proyecto GNU sigue
vivo y cuenta con una amplia comunidad de colaboradores.
El sistema MINIX basado en el funcionamiento del UNIX versión 7 fue desarrollado en 1 98 7 por
Andrew S. Tanenbaum con fines educativos; por ello su código es abierto y no muy extenso. Por su parte,
el sistema Linux, también de código abierto fue desarrollado a principios de los 90 por Linus B. Torvalds
(ver sección 6.2. 1 ) .
Volviendo al origen d e todo, e n 1 98 9 AT&T creó la división Unix Systems Laboratories (USL) y en
ella delegó el desarrolló y la comercialización del System V. En 1 99 1 , la compañía Novell adquirió parte
de USL y creo la filial Univel. Univel lanzó en 1 992 el sistema UnixWare para computadores personales.
UnixWare estaba basado en SVR4 y Netware (un sistema operativo de red). En 1 993 Novell se hizo con
el resto de USL, aunque en 1 995 la vendió junto con Univel a SCO la cual continuó con el desarrollo
del System V. De hecho la versión 7.0 de su sistema UnixWare lanzada en 1 997 estaba basada en SVR5 .
SCO también basó su sistema OpenServer en SVR5 .
Con respecto al sistema BSD su desarrolló llegó a su fin con la distribución B S D 4.4-Lite Release 2
aparecida en 1 995. Pese a ello han seguido desarrollándose sistemas operativos basados total o parcial­
mente en BSD. Algunos de estos sistemas son libres y de código abierto, como por ejemplo: NetBSD,
OpenBSD y FreeBSD. Otros son sistemas comerciales, como por ejemplo, Mac OS X de Apple.
En la actualidad la familia de SOBUNIX sigue muy viva y es muy amplia. Algunos son sistemas
comerciales, como por ejemplo: Solaris 1 0 de Sun aparecido en 2005 contando como núcleo con SunOS
5 . 1 0, AIX 7. 1 de IBM aparecido en 20 1 1 , HP-UX 1 1 .3 1 de HP aparecido en 2009 y Mac OS X 1 0.8 de
Apple aparecido en 20 1 2. Otros son sistemas libres como MINIX 3 . 2 de 20 1 2, OpenSolaris 2009.06 de
2009, NetBSD 5 . 1 .2 de 20 1 2, OpenBSD 5.0 de 20 1 1 , FreeB SD 9.0 de 20 1 2 y Linux 3 . 3 . 6 de 20 1 2 .
Sistemas Operativos Basados en UNIX (SOBUNIX) : introducción general
1.3.
5
Compatibilidad entre los SOBUNIX
La gran variedad de SOBUNIX resultaba un serio problema para los desarrolladores de aplicaciones
software. Las diferencias existentes entre unos SOBUNIX y otros propiciaban que una misma aplicación
pudiera no funcionar correctamente en todos los sistemas.
Para intentar resolver este problema se han creado diferentes estándares, también denominados nor­
mas o especificaciones, para definir una API para los SOBUNIX. Una aplicación que es desarrollada
usando una API definida por un determinado estándar tiene garantizado que puede ser ejecutada en todos
los sistema operativos que soporten dicho estándar. Una API queda definida, entre otros elementos, por el
conjunto de llamadas al sistema que pueden invocarse. Aparte del API los estándares también definen las
reglas que deben seguir los intérpretes de comandos (shells) y los archivos de órdenes para los intérpretes
(shell scripts).
Entre los diferentes estándares que aparecieron destaca el estándar POSIX que es soportado por
bastantes sistemas operativos. Este estándar fue desarrollado en 1 98 8 por IEEE teniendo en cuenta las
características comunes existentes en los sistemas System V y BSD. POSIX consta de diferentes docu­
mentos o extensiones los cuales se conocen con el nombre de familia IEEE Std 1 003, siendo el IEEE Std
1003 . 1 su documento base. También POS IX dispone de un conjunto de tests que permiten certificar que
un sistema cumple el estándar.
Otro estándar que cada vez está más en auge es el estándar SUS, sobre todo desde que IEEE cobra
una cantidad no despreciable por proporcionar la documentación del estándar y los test de POSIX. Este
estándar fue desarrollado en 1 997 por The Open Group, un consorcio formado por empresas y agencias
gubernamentales que se creó en 1 996 con la unión de X/Open y OSF. Este consorcio también certifica
que un sistema cumple con el estándar SUS . Dicha certificación identifica y aprueba a un sistema basado
en UNIX.
Desde su versión 3 de 200 1 , SUS es compatible con POSIX, ya que el documento base de ambos
estándares ha sido desarrollado por The Austin Group un grupo de trabajo en el que participan el IEEE
y The Open Group, entre otros. Ejemplos de sistemas operativos que cumplen con SUS versión 3 (equi­
valentemente también se dice que son sistemas UNIX 03) son: AIX 6. 1 , HP-UX 1 1 . 3 1 , Mac OS X 1 0 . 6
y Solaris 10.
Los sistemas basados en UNIX de distribución libre no suelen pasar procesos de certificación pero
suelen soportar algún estándar. Por ejemplo, Linux y MINIX son plenamente compatibles con alguna
versión de POSIX.
1.4.
Características principales de los SOBUNIX
Las características principales de los SOBUNIX son:
•
Son sistemas de tiempo compartido, también denominados sistemas interactivos. Aunque algunos
incluso soportan también aplicaciones de tiempo real.
•
Son sistemas multiprogramados y multiusuario, con soporte para multiprocesamiento.
6
Ampliación de sistemas operativos
•
El núcleo está escrito en su mayor parte en lenguaje C, lo que facilita su portabilidad a distintas
arquitecturas.
•
El núcleo posee una estructura de tipo monolítica o simple.
•
La planificación se realiza a nivel de procesos o de hilos del núcleo usando un algoritmo de plani­
ficación basada en múltiples colas de planificación y realimentación.
•
Disponen entre otros de los siguientes mecanismos de comunicación y sincronización entre proce­
sos: tuberías, semáforos, memoria compartida y colas de mensajes.
•
No suelen implementar ninguna estrategia de tratamiento de interbloqueos. Dichas estrategias si
se quieren implementar deben hacerse a nivel de los programas de aplicación.
•
Administran la memoria principal e implementan la memoria virtual usando la técnica de demanda
de página.
•
Consideran a los archivos como una secuencia de bits y delegan en las aplicaciones la interpreta­
ción de los mismos.
•
Soportan tanto el acceso secuencial como el acceso aleatorio a los archivos .
•
E n los nombres d e archivos distinguen entre minúsculas y mayúsculas.
•
Soportan una estructura de directorios de gráfica acíclica. El directorio raíz se denota con el sím­
bolo' 1 ', que además se usa para separar los componentes del nombre de ruta de un archivo.
•
Los SOBUNIX modernos implementan una capa nodo virtual/sistema de archivos virtual para
poder soportar diferentes tipos de sistemas de archivos.
•
Cada sistema de archivos se monta en un directorio del sistema de archivos principal. Con lo que
todos los sistemas de archivos quedan integrados dentro de una única estructura de directorios.
•
Los dispositivos de E/S se integran dentro del sistema de archivos mediante el uso de archivos de
dispositivos modo bloque y archivos de dispositivos modo carácter. Lo que permite operar sobre
ellos con las mismas llamadas al sistema que se utilizan para operar sobre los archivos.
•
Permiten especificar los permisos de acceso (lectura, escritura y ejecución) a un archivo o directo­
rio de forma independiente para el usuario propietario del archivo, el grupo de usuarios propietario
y el resto de usuarios.
Conviene señalar que cada SOBUNIX puede implementar estas características de distinta forma.
Además cada SOBUNIX puede poseer características particulares no disponibles en el resto de SOBU­
NIX.
Sistemas Operativos Basados en UNIX (SOBUNIX) : introducción general
1.5.
7
Interfaces con los usuarios disponibles en SOBUNIX
Los SOBUNIX soportan dos posibles tipos de interfaz de usuario (ver Figura 1 . 1 ) : inteifaz de línea
de comandos implementada mediante un intérprete de comandos e inteifaz de usuario gráfica (GUI) .
Nótese que desde una interfaz gráfica también se puede disponer de una interfaz de línea de comandos.
A través de estos interfaces un usuario puede invocar a otros programas o aplicaciones. Desde el
punto de vista de su ejecución tanto los interfaces como los programas tendrán asociado cada uno al
menos un proceso monohilo o multihilo. Un proceso (o un hilo) para solicitar los servicios del núcleo del
sistema operativo tiene que realizar las llamadas al sistema correspondientes. Típicamente una llamada al
sistema se realiza mediante la invocación de una función de la librería estándar C de llamadas al sistema.
Modo
Usuario
}
Il
Usuarios
Otros programas
Librería estándar C de
llamadas al sistema
f------1
Núcleo del sistema operativo
}
Modo
Núcleo
Hardware
Figura 1.1 - Interacción de los usuarios con un S OBUNIX
En las siguientes secciones se describen los intérpretes de comandos que implementan las interfaces
de línea de comandos, la implementación de las interfaces gráficas y el tratamiento de las llamadas al
sistema.
1.5.1.
Intérpretes de comandos
Definición e intérpretes más conocidos
Un intérprete de comandos (shell) es un programa que acepta un comando 1 introducido por un usua­
rio a través del dispositivo de entrada estándar (por defecto el teclado) y ejecuta su código asociado.
El resultado de la ejecución se muestra, generalmente, en el dispositivo de salida estándar (por defecto
la pantalla) . Una vez finalizada la ejecución del comando el intérprete queda a la espera de recibir otra
orden por parte del usuario.
Cada SOBUNIX suele incluir por defecto en su distribución un determinado intérprete de comandos,
pero el usuario si así lo desea puede utilizar otro. Entre los intérpretes de comandos más conocidos se
encuentran los siguientes:
1 0tro término sinónimo de comando es orden. En este texto se utilizan ambos términos indistintamente.
8
Ampliación de sistemas operativos
•
Bourne shell (sh). Este intérprete fue escrito a finales de los setenta por Steve B ourne. Se distribuyó
inicialmente con el UNIX version 7 de AT &T.
•
e shell (c sh) . Intérprete escrito a finales de los setenta por Bill Joy. Se distribuyó inicialmente con
BSD 2.0.
•
TENEX e shell ( t c sh) . Este intérprete se basa en C shell y supone una mej ora del mismo. La pri­
mera versión de este intérprete fue escrita Ken Greer a finales de los setenta. Aunque en los ochenta
y en los noventa continuaron su desarrollo, Paul Placeway y Wilfredo S ánchez, respectivamente.
Este intérprete se distribuye, entre otros sistemas, en FreeB SD y Mac OS X.
•
Korn shell (ksh) . Este intérprete fue escrito a principios de los ochenta por David Korn. Es com­
patible con B ourne shell e incluye características de C shell. Se ha distribuido, entre otros, en los
sistemas SVR4, AIX y HP-UX.
•
Bourne-Again shell (ba sh) . Fue escrito a finales de los ochenta por Brian Fax para el proyecto
GNU. Este intérprete se distribuye, entre otros sistemas, en Linux.
•
A lmquist shell (ash). Fue escrita por Kenneth Almquist a finales de los ochenta. Se distribuyó
inicialmente con BSD 4.3.
•
Z shell ( z sh) . Fue escrito por Paul Falstad en 1 990. Se considera un intérprete muy completo ya
que incluye características de TENEX C shell, B ourne-Again shell y Korn shell, entre otros.
La mayoría de los intérpretes enumerados se han ido mejorando posteriormente y han incluido tam­
bién, por motivos de compatibilidad, las especificaciones POSIX. El usar un intérprete u otro suele ser
muchas veces una cuestión de gustos, ya que todos incluyen unas características básicas similares. Las
principales diferencias entre los intérpretes se encuentran en las características adicionales y avanzadas
que pueden soportar y cómo las implementan, como por ejemplo: la corrección automática de la sintaxis
de los comandos, el histórico de comandos, el autocomplementado de órdenes y el lenguaje soportado
para la escritura de archivos de comandos (shell scripts).
Estructura de los comandos
Un comando es una cadena de caracteres que de forma general tiene la siguiente estructura:
nombre_c omando - op_l - op_2 . . . - op_M arg_l arg_2
. . . arg_N
En dicha estructura nombre_c omando es el nombre del comando que se desea ejecutar, - op_j con
j = 1 , 2, . . . ,M son opciones que permiten configurar el comportamiento del programa, y arg_i con
i = 1 , 2, . . . ,N son los argumentos que acepta el programa.
Cada opción se escribe con el prefijo' -', aunque existe la posibilidad de agrupar todas las opciones
y usar un único prefijo:
nombre_c omando - op_l op_2 . . . op_M arg_l arg_2 . . . arg_N
Sistemas Operativos Basados en UNIX (SOBUNIX) : introducción general
9
Si se desea conocer el significado, las opciones y los argumentos de un determinado comando, se
puede consultar el manual de ayuda del sistema desde el propio intérprete mediante la orden:
man nombre_c omando
El manual de ayuda se divide en secciones. Cada sección se identifica mediante un entero positivo y
está asociada a un determinado tipo de recurso: comandos, llamadas al sistema, funciones de librerías,
archivos del sistema, macros, etc. A su vez cada sección se divide en páginas, donde cada página está
asociada a un determinado recurso identificado por su nombre. Conviene señalar que no todos los re­
cursos disponibles están documentados en el manual de ayuda. Para acceder a una página dentro de una
determinada sección se debe especificar el número de la sección antes del nombre del recurso:
man número s e c c i ón nombre recurso
En ocasiones un mismo nombre designa a diferentes recursos. Por defecto se muestra la primera
página que se encuentra en el manual asociada a dicho nombre. Para mostrar todas las páginas asociadas
a un mismo nombre hay que usar la opción - a :
man - a nombre
Para ir avanzando por la información de una página del manual se debe ir presionando la tecla
[ intro ] o [ e spac i o ] . Asimismo para volver hacia atrás se debe presionar la tecla [ b ] . Si se desea
salir del manual se debe presionar la tecla [ q l . Para conocer las opciones y el funcionamiento del manual
de ayuda se puede consultar su propia página del manual:
man man
Aparte de este manual de ayuda principal existen otros manuales de ayuda específicos de ciertos
programas que se pueden consultar usando el comando i n f o .
e
Ejemplo 1 . 1
Supóngase que e l directorio d e trabajo actual e s 1 expo r t / home 1 j m y que en e l mismo existen, entre
otros, el subdirectorio Documento s . Para conocer el nombre de ruta absoluta del directorio de trabaj o
actual s e puede usar e l comando pwd. Luego s i e n la línea d e comandos del intérprete s e escribe l a orden
pwd
en la pantalla aparece como respuesta
/ expo r t / home / j m
Nótese que en este caso el comando ha sido escrito sin opciones ni argumentos.
Para acceder a otro directorio, es decir, para cambiar el directorio de trabajo actual, se puede usar el
comando cd, el cual admite como argumento el nombre de ruta absoluto o relativo del directorio. Por
ejemplo, si se desea acceder al subdirectorio Document o s se puede escribir la orden:
10
Ampliación de sistemas operativos
cd / expo rt / home / j m / Documen t o s
o equivalentemente:
c d Do cumen t o s
En el primer caso s e ha utilizado e l nombre d e ruta absoluto del directorio y e n e l segundo e l nombre de
ruta relativo.
Para regresar al directorio de trabaj o anterior se puede escribir la orden
cd / expo r t / home / j m
o equivalentemente la orden
cd . .
Donde " . . " hace referencia el directorio padre del directorio actual.
Para mostrar en pantalla un listado de los nombres de los archivos y directorios contenidos en el directorio
de trabajo actual se puede usar el comando l s . Este comando admite diferentes opciones que permiten
establecer la información que se mostrará sobre los archivos y directorios listados. Por ejemplo, la orden
ls -F
introduce al final del nombre de los directorios e l símbolo 1 para diferenciarlos del resto de archivos.
1
1
Otro ejemplo, la orden
ls -i
muestra el número de nodo-i asociado al archivo o directorio correspondiente.
Las dos órdenes anteriores se pueden escribir en una sola orden de la siguiente forma:
ls
-Fi
Para conocer todas las opciones que acepta e l comando l s s e puede consultar su página del manual de
ayuda
man l s
Para borrar l a pantalla del intérprete de comandos se puede usar l a orden c l ear. S i se desea cerrar la
ventana del intérprete se puede pulsar la combinación de teclas [ c ontro l ] + [ dl o usar el comando
exi t .
•
Sistemas Operativos Basados en UNIX (SOBUNIX) : introducción general
11
E l número d e comandos soportados por los intérpretes de los SOBUNIX e s elevado. En l a Tabla 1 . 1
se recopilan algunos comandos básicos asociados principalmente a la gestión de archivos y directorios.
A lo largo de éste y los restantes capítulos se irán presentando más comandos para la realización de otras
tareas.
Comando
cat
cd
cp
f ind
grep
ls
more
mkdir
mv
mvdi r
pwd
rm
rmdir
Utilidad
Encadenar y mostrar el contenido de archivos
Cambiar de directorio de trabaj o
Copiar archivos o directorios
B uscar un archivo
B uscar una cadena de texto en varios archivos
Listar los archivos y directorios de un directorio
Mostrar página a página el contenido de un archivo
Crear directorio
Mover de directorio o renombrar archivos
Cambiar de ubicación u n directorio
Mostrar el nombre de ruta del directorio de trabaj o actual
Borrar archivos o directorios
B orrar directorio
Tabla 1.1 - Algunos comandos básicos asociados a la gestión de archivos
y
directorios en SOBUNIX
Con el fin de reducir la longitud de la cadena de caracteres asociada a una orden, la mayoría de los
intérpretes de comandos de SOBUNIX soportan el uso de comodines (wild cards) en los argumentos de
las órdenes. Un comodín es un carácter especial que hace que el intérprete trate el argumento de una
determinada forma. Entre los comodines más frecuentemente soportados se encuentran los siguientes :
•
e
' *' . Este comodín sustituye a cualquier cadena de caracteres.
•
' ? ' . Este comodín sustituye a cualquier carácter.
•
" [ c l c 2 . . . eN ] " . Este comodín significa que se debe sustituir por uno solo de los caracteres c j
j = 1 , . . . , N incluidos dentro de los corchetes.
Ejemplo 1.2
Supóngase que en el directorio de trabajo actual existen los archivos prueba . e, t raba j o l . txt y
t raba j o 2 . txt . Supóngase además que se desea copiar en el subdirectorio Document o s los archivos
con extensión txt. Para realizar esta acción se podría usar la siguiente orden:
.
cp t raba j o l . txt t rabaj o 2 . txt Documen t o s
También s e podría reducir la longitud d e l a orden haciendo u s o del comodín' *' :
12
Ampliación de sistemas
operativos
cp * . txt Document o s
En este caso e l comodín 1 * 1 sustituye a todas las cadenas de caracteres posibles, por lo que el intérprete
busca en el directorio de trabajo todos los archivos cuyo nombre terminan en 11 • txt 11 •
Asimismo si se sabe que el subdirectorio Document o s es el único que empieza por el carácter 1 D 1 enton­
ces la orden se podría haber escrito aún de forma más reducida:
cp * . txt D *
Usando e l mismo ejemplo s e puede ilustrar el uso de los comodines 1 ? 1 y 11 [ l 11 :
cp trabaj o ? . txt Documen t o s
cp traba j o [ 1 2 ] . txt Documentos
En la primera orden el comodín 1 ? 1 permite sustituir a los caracteres 1 1 1 y 1 2 1 • En la segunda orden se
fuerza a que se sustituya por los caracteres 1 1 1 y 1 2 1 •
•
En los SOBUNIX cuando se ejecuta un programa se crea un proceso para el cual se abren por defecto
tres archivos (ver sección 5 . 2 . 1 ) : el archivo de entrada estándar, el archivo de salida estándar y el archivo
de salida de errores estándar. El archivo de entrada estándar está asociado por defecto al teclado (ver
sección 5 .5), mientras que los archivos de salida estándar y salida de errores estándar están asociados por
defecto a la pantalla.
Los intérpretes de comandos en los SOBUNIX soportan el redireccionamiento de la E/S, es decir,
permite cambiar los archivos de entrada y salida estándar de los comandos que ejecutan. Para ello se
pueden usar los siguientes operadores :
•
Operador 1 < 1 • Permite redireccionar la entrada estándar hacia otro archivo.
•
Operador 1 > 1 • Permite redireccionar la salida estándar hacia otro archivo. La salida se empieza a
almacenar desde el comienzo del archivo, con lo que se sobreescribe su contenido.
•
Operador 1 > > 1 • Permite redireccionar la salida estándar hacia otro archivo. La salida se empieza a
almacenar a partir del final del archivo, con lo que no se eliminan los datos que ya existieran en el
mismo.
•
Operador 1 2 > 1 • Permite redireccionar la salida de errores estándar hacia otro archivo. La salida se
empieza a almacenar desde el comienzo del archivo, con lo que se sobreescribe su contenido.
•
Operador 1 2 > > 1 • Permite redireccionar la salida de errores estándar hacia otro archivo. La salida
se empieza a almacenar a partir del final del archivo, con lo que no se eliminan los datos que ya
existieran en el mismo.
Sistemas Operativos Basados en UNIX (SOBUNIX) : introducción general
13
También es posible encadenar órdenes de tal forma que la salida de una orden se convierta en la
entrada de otra orden. Para ello hay que utilizar una tubería (ver sección 3.5 .2) la cual se representa
mediante el carácter ' 1 '.
e
Ejemplo 1.3
Supóngase que se escribe la siguiente orden:
s o r t < da t o s . da t > o rdenado s . txt
Esta orden invoca al comando s o r t que ordena por orden alfabético las líneas del archivo da t o s . da t
pasado como entrada. L a salida del comando s e guarda e n e l archivo o rdenado s . t x t .
Por s u parte l a orden
l s -F 1 sort
utiliza una tubería para que la salida d e la orden l s - F s e convierta e n la entrada d e la orden s o r t cuya
salida se mostrará en la salida estándar, en este caso la pantalla.
•
Otra característica de los intérpretes de comandos de los SOBUNIX que resulta muy útil para aho­
rrarse escribir ordenes largas o complicadas de recordar que se usen frecuentemente, es la posibilidad de
asignar un nombre o alias a una determinada orden o cadena de órdenes. De esta forma, las invocaciones
de dicha orden se realizan usando su alias correspondiente.
Para asignar un alias a una orden o cadena de órdenes se usa el comando a l i a s . También es posible
deshacer la asignación de un alias, para ello se debe usar el comando una l i a s . Es importante tener
en cuenta que por defecto la asignación de un alias tiene un carácter temporal, es decir, desaparece al
cerrarse el intérprete de comandos. Para hacer la asignación de un alias persistente, es decir, para que se
pueda utilizar un alias sin ser definido previamente cada vez que se abra el intérprete, se debe incluir su
asignación en los archivos de configuración del intérprete.
e
Ejemplo 1 .4
Supóngase que un usuario tiene que escribir con frecuencia la siguiente secuencia de órdenes:
cp * . txt Do cumen t o s ; cd Document o s ; l s - F
Para ahorrarse s u escritura puede asignarles u n alias, al que s e va a llamar por ejemplo c op i ar_txt, de
la siguiente forma:
a l i as copi ar_txt
=
' cp * . txt Document o s ; cd Document o s ; l s - F '
Si se desea quitar este alias simplemente habría que usar la orden:
una l i a s c op i ar_txt
•
14
Ampliación de sistemas operativos
Funcionamiento
Un intérprete de comandos de SOBUNIX es un archivo ejecutable que reside en un cierto directorio
del sistema de archivos, típicamente en el directorio / b i n . Cuando se invoca a un intérprete se crea
un proceso asociado a su ejecución. Este proceso en primer lugar ejecuta las órdenes establecidas en
los diferentes archivos de configuración del intérprete (ver la página del manual de ayuda del intérprete
correspondiente) con el objetivo de configurar las variables del intérprete de comandos. A continuación
muestra el apuntador (prompt) en pantalla que es un carácter o cadena de caracteres cuya aparición en
la pantalla sirve para indicar al usuario que ya puede escribir una orden.
El funcionamiento del intérprete depende del tipo de comando que se escriba. En general se distin­
guen dos tipos de comandos: externos e internos. Señalar que el comando type permite conocer el tipo
(interno o externo) de un comando.
Un comando externo es aquél cuyo código de ejecución se encuentra en un archivo ejecutable que
debe ser buscado por el intérprete. En general un comando externo es cualquier archivo ejecutable, como
por ejemplo: los programas de utilidad y aplicaciones suministrados en la distribución del S OBUNIX y
los programas de aplicación descargados o creados por los usuarios. También entran en esta categoría los
archivos de comandos (shell scripts) .
Un comando interno (built-in command) e s aquél cuyo código d e ejecución forma parte del código
del intérprete de comandos . En consecuencia no requiere ser buscado en un archivo ejecutable por el
intérprete, puesto que ya se encuentra cargado en su espacio de direcciones. Ejemplos de comandos
internos son cd, pwd y a l i a s .
Cuando s e teclea u n comando el intérprete lee el nombre d e l a orden y comprueba s i e s una orden
interna. En dicho caso analiza la sintaxis de la orden y si es correcta la ejecuta, en caso contrario muestra
un mensaje de error en la salida estándar.
Si no es un comando interno, entonces el intérprete busca el archivo ejecutable asociado al comando
externo. En el caso de que no lo localice mostrará un mensaje de error en la salida estándar. Si lo en­
cuentra crea un nuevo proceso asociado a la ejecución del archivo ejecutable y le pasa los indicadores y
argumentos del comando como parámetros.
En los SOBUNIX se suele usar el término trabajo (job) para designar al proceso o grupo de procesos
que se crean asociados a la ejecución de un comando introducido por el usuario en un intérprete de
comandos.
Un trabajo se puede ejecutar en primer plano (foreground) o en segundo plano (background). Si un
trabaj o se ejecuta en primer plano entonces puede interactuar con el usuario esperando por la recepción
de entradas y mostrando salidas. Por el contrario un trabaj o ejecutándose en segundo plano no puede
interactuar con el usuario.
En un intérprete de comandos, en un determinado instante de tiempo, solamente puede existir un
trabaj o ejecutándose en primer plano. Por el contrario pueden existir múltiples trabajos ejecutándose en
segundo plano.
Si un usuario escribe una orden en el intérprete de comandos, el trabajo asociado a dicha orden se
ejecuta por defecto en ptimer plano. Si se desea que el trabajo se ejecute en segundo plano la orden se
debe escribir seguida de un espacio y del carácter'&' , es decir:
Sistemas Operativos Basados en UNIX (SOBUNIX) : introducción general
15
c omando &
Un trabajo puede ser pasado de segundo plano a primer plano usando el comando f g . Asimismo
el trabajo en primer plano puede ser pasado a segundo plano usando el comando bg. Nótese que para
poder realizar este cambio el trabajo en primer plano debe ser previamente parado pulsando las teclas
[ c ontr o l ] + [ z ] .
Para obtener información sobre los trabajos que se están ejecutando en un intérprete se puede usar el
comando j obs . Si se desea terminar el trabajo que se está ejecutando en primer plano se deben pulsar
las teclas [ c ontro l ] + [ e ] .
Variables y entorno
Cuando se inicia la ejecución de un intérprete de comandos se crean y se inicializan un conjunto de
variables denominadas variables del intérprete de comandos a partir de los archivos de configuración
del intérprete. Estas variables son locales al proceso asociado a la ejecución del intérprete y pueden ser
utilizadas por los comandos internos. El comando s e t permite visualizar un listado de todas las variables
del intérprete. En la página del manual de ayuda asociada al intérprete se describe el significado de cada
una de estas variables.
Un usuario puede cambiar el valor de algunas de las variables del intérprete. Otras variables, sin
embargo, no pueden ser modificadas. Además un usuario también puede definir nuevas variables.
Si se desea que los cambios que se realicen en las variables o que las nuevas variables definidas sean
persistentes se deben definir en los archivos de configuración del intérprete.
e
Ejemplo 1.5
Supóngase que se ha iniciado una sesión de trabaj o con un determinado intérprete de comandos. Si se
teclea el comando:
set
s e mostrará en l a salida estándar e l listado de todas las variables del intérprete.
Si se desea conocer el valor de una determinada variable se puede usar el comando echo. Por ejemplo,
para conocer el valor de la variable PATH, la cual contiene los nombres de ruta de los directorios donde
el intérprete busca los comandos externos, se debe escribir la siguiente orden:
echo $ PATH
Nótese que el valor de una variable se referencia escribiendo ' $ ' delante del nombre de la variable.
Si se desea añadir un directorio a la variable PATH, por ejemplo el directorio de trabaj o actual, se puede
usar la siguiente orden:
PATH= $ PATH : .
16
Ampliación de sistemas operativos
----��---------------------------------------------------------
Recuérdese que el nombre de ruta 1 1 hace referencia al directorio de trabajo actual.
•
Se puede comprobar que la variable ha sido cambiada escribiendo de nuevo la orden:
echo $ PATH
También se puede definir una nueva variable MI_VARIABLE y asignarle un cierto valor, de la siguiente
forma:
MI_VARIABLE= l O
Si se escribe de nuevo la orden
set
s e puede comprobar que la nueva variable h a sido incorporada al listado de variables del intérprete y que
la variable PATH contiene los cambios realizados.
Señalar que si se cierra el intérprete y se vuelve a iniciar se puede comprobar usando la orden set que
los cambios realizados no son persistentes .
•
Como se describirá en la sección 2.3 . 1 , cuando se invoca a otro programa desde un proceso ya creado
se le puede pasar como argumentos una serie de cadenas de caracteres asociadas a variables inicializadas
a un cierto valor. A dicho conjunto de variables se le denomina entorno del proceso, y a cada variable
del conjunto se le denomina variable de entorno. Las variables de entorno pueden ser leídas o escritas
durante la ejecución del proceso.
Un intérprete de comandos, como cualquier otro programa, tiene asociado un proceso a su ejecución
y en consecuencia dispone de un entorno de ejecución. Para conocer las variables de entorno de un
intérprete se puede usar el comando env.
Algunas variables del intérprete proceden del entorno del proceso asociado al intérprete. Asimismo
también es posible exportar una variable del intérprete a su entorno; para ello se debe usar el comando
exp o r t .
Si se desea eliminar una variable del intérprete se debe usar el comando uns e t . Este comando
también borra a la variable del entorno, si había sido exportada allí.
e
Ejemplo 1.6
Si se teclea el comando:
env 1 s o r t
s e mostrará e n l a salida estándar e l listado d e todas las variables d e entorno del proceso asociado al
intérprete ordenadas alfabéticamente.
Para exportar al entorno las variables PATH y MI_VARIABLE del ejemplo anterior se debe escribir la
siguiente orden:
Sistemas Operativos Basados en UNIX (SOBUNIX): introducción general
17
export PATH MI_VARIABLE
Si se teclea de nuevo el comando env 1 s o r t se puede comprobar que dichas variables han sido in­
cluidas en el entorno.
Si se desea eliminar la variable MI_VARIABLE se debe usar la orden:
uns e t MI_VARIABLE
Usando el comando s e t se puede comprobar que MI_VARIABLE ha sido eliminada. Además usando el
comando env se puede comprobar que también ha desaparecido del entorno.
•
Cuando se ejecuta un comando externo en un intérprete, el proceso asociado al intérprete crea un
proceso hijo asociado al comando que recibe como entorno una copia del entorno del intérprete. Los
cambios que realice el nuevo proceso en su copia del entorno no afectan al entorno del proceso padre ya
que en los SOBUNIX los procesos poseen espacios de direcciones independientes.
Obviamente si se desea que el proceso asociado al comando externo pueda hacer uso de alguna
variable del intérprete ésta debe ser exportada al entorno del intérprete antes de ejecutar el comando.
Recuérdese que las variables del intérprete son locales al proceso asociado a la ejecución del intérprete.
Shell scripts
Usualmente los intérpretes de comandos, aparte de ser capaces de ejecutar comandos internos y
externos, también disponen de un completo lenguaje de programación con sentencias del tipo i f , f o r ,
whi l e , etc. Además también soportan la definición de funciones. Para conocer los detalles de la sintaxis
del lenguaje de programación de un intérprete se debe consultar su página del manual de ayuda.
Un shell script es un archivo ASCII que contiene comandos y sentencias del lenguaje de programa­
ción del intérprete. Para crear un shell script se puede usar cualquier editor de texto. Una vez escrito el
código del shell script se debe guardar en un archivo, al que hay que proporcionarle permiso de ejecución
(ver sección 1 .7.2) . Además hay que incluir (si no lo estaba ya) dentro de la variable PATH el nombre de
ruta del directorio donde reside el shell script.
La ejecución de un shell script se puede realizar de dos formas. La primera forma consiste en pasar
el nombre de ruta del shell script como argumento de entrada del comando s ourc e :
s ource s he l l_s c r i p t
Dicho comando carga el shell script en el espacio de direcciones del intérprete y lo ejecuta. Nótese
que en este caso la ejecución del shell script es similar a la de un comando interno, por lo que no hay que
crear un nuevo proceso.
La segunda forma de ejecución de un shell script consiste en invocarlo como un comando externo:
s he l l_s c r i p t
18
Ampliación de sistemas operativos
En este caso el intérprete invoca a otro intérprete, a veces denominado subintérprete (subshell), para
que ejecute el shell script. Nótese que el subintérprete recibe una copia del entorno del intérprete, por lo
que las variables del intérprete que no hubieran sido exportadas a su entorno no serán heredadas por el
subintérprete.
También se puede invocar directamente el subintérprete y pasarle como argumento de entrada el
nombre de ruta del shell script que se desea ejecutar. Por ejemplo si el shell script se desea ejecutar en
un subintérprete bash entonces la orden sería:
bash she l l_s c r i p t
L a utilidad d e los shell scripts e s evidente. Por u n lado, s i u n usuario ejecuta frecuentemente la
misma secuencia de comandos puede evitarse su escritura creando un shell script que contenga dicha
secuencia. De esta forma solo tendría que escribir el nombre del shell script. Por otra parte, gracias a que
un intérprete soporta un lenguaje de programación, se pueden escribir shell scripts para la realización de
todo tipo de tareas.
e
Ejemplo 1.7
En la Figura 1 .2 se muestra el código de un shell script sencillo que únicamente contiene comentarios y
algunos comandos descritos en las secciones anteriores.
# ! / b i n / ba s h
# Mo s t rar ordenadame n t e a l f abé t i c amen te y p á g i n a a p á g i n a l a s var i ab l e s
# de l e n t o rno de l i n t érpr e t e
env
1
sort
1
mo r e
# C r e a r u n a nueva var i ab l e M I V
MIV= l O
#Ver e l va l o r de l a var i ab l e
echo $MIV
# Expo r t a r l a a l entorno
exp o r t MIV
Figura 1.2 - Ejemplo de shell script
Los comentarios se introducen en el código del shell script precedidos del símbolo' # ' . El primer comen­
tario indica al intérprete el nombre de ruta del subintérprete que debe invocar para ejecutar este shell
script. En este caso es un intérprete bash. Nótese que si se omite esta orden el subintérprete que se
invoca es del mismo tipo que el intérprete. Este comentario es importante ya que un shell script escrito
con el lenguaje de programación de un cierto tipo de intérprete puede que produzca errores si se ejecuta
con otro tipo de intérprete.
Supóngase que el shell script de la Figura 1 .2 se encuentra almacenado en el archivo e j _s c r i p t . Para
poder ejecutarlo se debe habilitar el permiso de ejecución del archivo (ver sección 1 .7 . 2), usando la
siguiente orden:
chmod 0 7 4 4 e j ernp l o_s c r i p t
Sistemas Operativos Basados en UNIX (SOBUNIX) : introducción general
19
Además hay que asegurarse que el directorio donde se encuentra el shell script se encuentra añadido en
la variable PATH.
Si se cumplen estas dos condiciones, el shell script se puede invocar, por ejemplo, mediante su nombre
de ruta:
e j emp l o_s c r i p t
En este caso se ha supuesto que el shell script se encuentra en el directorio de trabaj o actual, por ello se
ha podido invocar mediante su nombre de ruta relativa.
•
1.5.2.
Interfaces de usuario gráficas
El sistema X Window
Las interfaces de usuario gráficas (GUis) de la mayoría de SOBUNIX se basan en el sistema X
Window, también conocido abreviadamente como X. El sistema X Window fue desarrollado a mediados
de los años ochenta por el MIT. La primera versión, denomina X 1 apareció en 1 984. En el momento de
escribir este texto la última versión de X Window es la X 1 1 R7.7 de 20 1 2 . Nótese que la versión 1 1 (X 1 1 )
aparecida en 1 987 h a sido sobre l a que s e han ido haciendo las sucesivas modificaciones.
El sistema X Window es un sistema de ventanas (windowing system), es decir, la capa de software
más interna de una GUI que se encarga de enviar y recibir datos del hardware (pantalla, teclado y ra­
tón). Además contiene las funciones primitivas básicas para la representación gráfica de líneas y fuentes
asociadas a las ventanas y al puntero del ratón.
El sistema X Window se caracteriza por su alta portabilidad ya que se ejecuta fuera del espacio de
direcciones del núcleo. Está diseñado siguiendo una arquitectura del tipo servidor-cliente (ver Figura
1 . 3). El servidor X es la parte del software del sistema X Window que se ejecuta en la máquina del
usuario y se encarga de leer datos procedentes del teclado y del ratón, así como de escribir mapas de bits
en la pantalla. Además se comunica con los clientes X.
Un cliente X es un determinado programa (gestor de ventanas, navegador web, gestor de correo
electrónico, emulador de terminal, etc) que invoca (bien directamente o a través de librerías gráficas)
funciones de la librería Xl ib para comunicarse con el servidor X. Un cliente X puede estar ejecutándose
en la misma máquina que el servidor X o en una máquina remota. En este último caso la comunicación
se realiza a través de la red. En una misma máquina pueden existir varios clientes X.
Cada cliente X envía al servidor X la información que debe mostrar en la pantalla. Además recibe del
servidor X información procedente del teclado y el ratón. Nótese que el servidor X hace un seguimiento
del puntero del ratón y la posición de las ventanas para determinar qué ventana es la que se encuentra
activa y saber a qué cliente X debe enviar la información procedente del teclado y el ratón. Además el
servidor X almacena en unas estructuras de datos denominadas recursos información sobre diferentes
objetos: ventanas, fuentes, paletas de colores, cursor, etc. Cada recurso tiene un identificador numérico
entero que lo identifica de forma única.
20
Ampliación de sistemas operativos
Protocolo X
Cliente X
Figura 1.3
-
Cliente X
Arquitectura cliente-servidor del sistema X Window
El intercambio de información entre un servidor X y un cliente X sigue el protocolo de comunicación
denominado protocolo X (Xprotocol). El cliente X solicita la conexión con el servidor X enviándole un
primer mensaje. El servidor X responde con otro mensaje para aceptar o rechazar la conexión, o para
obtener una comprobación de la identidad del cliente X. El mensaje de aceptación de la conexión por
parte del servidor X contiene información que el cliente X utilizará en las siguientes comunicaciones con
el servidor X. Una vez que la conexión se ha establecido, el servidor X y el cliente X pueden intercambiar
cuatro tipos de mensajes:
•
Mensajes de petición. Son enviados por el cliente X para pedir información al servidor X o para
solicitarle que dibuje algo en la pantalla.
•
Mensajes de respuesta. Son enviados por el servidor X en respuesta a algunos mensajes de petición
del cliente X.
•
Mensajes de aparición de eventos. Son enviados por el servidor X a un cliente X cuando se produce
algún evento asociada a la ventana asociada al cliente X: entrada de ratón o teclado, cambio de
posición o de tamaño de la ventana, etc.
•
Mensajes de error.
Por ejemplo, si un cliente X desea crear una ventana, enviará un mensaje de petición al servidor X.
É ste creará la ventana y su recurso asociado, y le asignará un identificador que enviará en el mensaje de
respuesta al cliente X. De esta forma el cliente X utilizará este identificador para referirse a la ventana
en posteriores mensajes de petición.
Los mensajes son cadenas de bytes que deben ser interpretados. Por ejemplo los mensaj es de apari­
ción de eventos tienen una longitud de 32 bytes. El byte más significativo, es decir, el situado más a la
izquierda, especifica el tipo de evento y los 31 bytes restantes especifican información adicional asociada
al evento. Obviamente desde el punto de vista del programador de aplicaciones trabajar directamente
con cadenas de bytes es muy tedioso. Afortunadamente el sistema X Window incluye una librería de
primitivas básicas de manej o del protocolo X denominada X l ib.
Sistemas Operativos Basados en UNIX (SOBUNIX) : introducción general
21
Widgets toolkits
Aparte del sistema de ventanas otra parte fundamental de una GUI son las librerías denominadas
widgets toolkits, que proporcionan al programador de aplicaciones funciones para crear y manipular
desde un nivel de abstracción superior los objetos gráficos típicos de una interfaz gráfica (ventanas,
menús, botones, barras de desplazamientos, etc) a los cuales se les denomina de forma general widgets.
En las interfaces gráficas basadas en el sistema X Window las widget toolkits se ejecutan por encima
de la librería Xl ib. Es decir, un programa de aplicación (cliente X) invoca a una función de una widgets
toolkit que a su vez invoca a una función de la librería Xl ib.
Entre las librerías widgets toolkits más conocidas que se ejecutan sobre el sistema X Window se
encuentran Mo t i f , Q t y GTK + .
El sistema X Window también incluye una librería widgets toolkit básica denominada X Too/kit
Intrinsics (o más abreviadamente Xt o X toolkit). Motif se ejecuta sobre Xt. En la Figura 1 .4 se muestran
las librerías gráficas más comunes de un cliente X.
Programa de aplicación
1
1
1
Qt
GTK+
1
1
Motif
1
Widgets
toolkits
Xt
1
Xlib
¡ Protocolo X
Figura 1.4 - Librerías gráficas más comunes de un cliente X
Entornos de escritorio
Cada aplicación define en su ventana asociada la interfaz gráfica específica que le desea ofrecer al
usuario. Sin embargo, la apariencia de los marcos de las ventanas y la interacción del usuario con los
mismos son controladas por una capa de software que se denomina entorno de escritorio. Algunos de los
entornos de escritorio más usados en SOBUNIX son: CDE que usa la librería Motif, KDE que usa Qt y
GNOME que usa GTK+.
Un entorno de escritorio también se encarga de controlar el fondo, la barra de tareas y los iconos del
escritorio. Consta, entre otros, de los siguientes componentes:
22
Ampliación de sistemas operativos
•
Gestor de ventanas (window manager). Es un cliente X que se encarga, entre otras tareas, de
posicionar las ventanas, colocar los marcos alrededor de las ventanas y atender la interacción del
usuario con los marcos de las ventanas, con los iconos y con la barra de tareas. También se encarga
de tratar los clics del ratón y las pulsaciones de teclas fuera de una ventana determinada, es decir, no
asociadas a un cliente X determinado. Por otra parte, ciertas peticiones de los clientes X al servidor
X son redireccionadas al gestor de ventanas, como por ejemplo, la creación o la eliminación de
ventanas.
•
Gestor de archivos (file manager), también denominado explorador de archivos (file browser).
Es un cliente X que suministra al usuario una interfaz gráfica amigable para la realización de
operaciones básicas con archivos y directorios: creación, eliminación, copia, visualización, etc.
1 .5.3.
Llamadas al sistema
Los procesos de los usuarios, tanto los que se crean para implementar las interfaces con el usuario
como los que se crean al interactuar el usuario con las interfaces, tienen que realizar llamadas al sistema
para solicitar los servicios del sistema operativo. De esta forma, las llamadas al sistema disponibles en un
sistema operativo establecen la interfaz de programación entre los procesos de los usuarios y el núcleo
del sistema operativo. Cada llamada al sistema tiene asociado un número entero positivo para poder ser
identificada por el núcleo.
En los SOBUNIX un proceso para hacer una llamada al sistema invoca a una función de envoltura o
2
redireccionamiento (wrapper function) de la librería e estándar, también denominada abreviadamente
l ib e . Cada llamada al sistema tiene asociada al menos una función de envoltura. Varias funciones de
envoltura pueden estar asociadas a la misma llamada al sistema, la diferencia entre ellas radica en los
argumentos de entrada que reciben y que pasan a la llamada. Por ejemplo, las funciones de envoltura
execv y execve invocan ambas a la llamada exe c . La diferencia entre ambas funciones es que execve
admite un mayor número de argumentos de entrada que execv.
La función de envoltura, cuando se ejecuta, copia el identificador de la llamada al sistema a la que
está asociada en algún registro o en la pila de usuario. A continuación ejecuta una trampa (trap) que
provoca la conmutación hardware de modo usuario a modo supervisor y transfiere el control al núcleo.
É ste invoca al manejador de llamadas al sistema, el cual se implementa mediante una rutina denominada
sys c a l l ( ) en la mayoría de SOBUNIX.
El manejador de llamadas al sistema, sys c a l l ( ) , realiza, entre otras, las siguientes acciones :
l . Copia los argumentos de la llamada al sistema en el área de usuario del proceso (ver sección
2.2.2) y guarda el contexto hardware del proceso, es decir, los valores actuales de los registros del
procesador, en la pila del núcleo asociada al proceso.
2. Utiliza el identificador de la llamada para acceder a la entrada adecuada de la tabla de llamadas al
sistema del núcleo. Cada entrada de esta tabla contiene, entre otros datos, la dirección de comienzo
2En programación una función
función.
de envoltura o redireccionamiento
es aquella cuya principal finalidad es invocar a otra
S istemas Operativos Basados en UNIX (SOBUNIX): introducción general
23
de la rutina del núcleo específica que hay que ejecutar para atender una determinada llamada al
sistema.
3. Cuando termina la ejecución de la rutina del núcleo que atiende a la llamada al sistema, entonces
sys c a l l ( ) copia los valores de retomo (o los códigos de error si se produjo algún error) en los
registros oportunos. A continuación restaura el contexto hardware del proceso y conmuta a modo
usuario devolviendo el control a la función de envoltura.
Cuando se devuelve el control a la función de envoltura, ya en modo usuario, ésta comprueba leyendo
los valores almacenados en los registros oportunos si la llamada al sistema se ejecutó correctamente o
si se produjeron errores. Si la llamada se ejecutó con éxito la función de envoltura retoma y se continúa
con la ejecución de la siguiente instrucción del proceso. Si se produjeron errores la función de envoltura,
antes de retomar, invoca a una función de notificación de errores, la cual almacena un identificador
numérico del error producido, en la forma de constante simbólica, en una variable global denominada
generalmente errno 3 y establece que el valor de retomo de la función de envoltura sea el valor - l . Por
ejemplo si una llamada al sistema es interrumpida por la recepción de una señal entonces en la variable
e rrno se almacena la constante E INTR.
Cada sistema operativo establece las llamadas al sistema que soporta, las cuales se pueden agrupar en
diferentes categorías: control de procesos, comunicación de procesos, gestión de archivos y directorios,
gestión de dispositivos, etc. Afortunadamente para los programadores de aplicaciones si un programa
utilizada las funciones de envoltura definidas en las especificaciones POSIX, se podrá ejecutar sin pro­
blemas en todos los sistemas operativos que cumplan con estas especificaciones.
1 .6.
Introducción a la gestión de archivos en SOBUNIX
La gestión de archivos en los SOBUNIX será descrita en detalle en el capítulo 5, en esta sección
únicamente se introducen aquellos conceptos que requieren ser conocidos antes de llegar a este capítulo.
En los SOBUNIX la información contenida en un archivo se estructura como una secuencia de bytes.
El núcleo no interpreta dicha información, simplemente se limita a operar con ella a nivel de byte. La
interpretación de los bytes recae sobre los procesos que solicitan al sistema operativo las operaciones
sobre los archivos mediante la realización de las llamadas al sistema oportunas. Por ejemplo, para leer
y escribir el contenido de un archivo se utilizan las llamadas al sistema read y wr i t e , respectivamente
(ver sección 5.2. 1 ) .
E l nombre de u n archivo e s una cadena d e caracteres ASCII. En los SOBUNIX s e pueden usar todos
los caracteres excepto los caracteres 1 y \ O Además se distingue entre caracteres en mayúsculas y en
minúsculas. La longitud máxima de un nombre depende del tipo de sistema de archivos al que pertenezca
el archivo. Los SOBUNIX modernos soportan el uso de diferentes tipos de sistemas de archivos.
A diferencia de otros sistemas operativos, en los SOBUNIX los nombres de archivos no tienen por
qué tener una extensión ya que el núcleo no las interpreta. De nuevo, el uso de extensiones en el nombre
1
3En el fichero de cabecera
errno.
errno .
1
1
1•
h puede encontrarse una descripción de los posibles valores que puede tomar la variable
Ampliación de sistemas operativos
24
de los archivos y su interpretación recae en los procesos. En este sentido, conviene señalar que un nombre
puede tener más de una extensión. Teniendo en cuenta lo anterior los nombres prueba, prueba . e y
prueba . e . g z serían nombres de archivos válidos en SOBUNIX.
Para que un proceso pueda operar sobre un archivo, éste primero tiene que ser abierto mediante la
invocación de la llamada al sistema open. La rutina del núcleo que trata esta llamada al sistema crea en
la memoria principal una estructura de datos denominada objeto de archivo abierto. Además asigna a
dicha estructura un número entero positivo pequeño denominado descriptor de archivo para identificarla.
Nótese que si un proceso abre el mismo archivo dos veces, o si dos procesos abren el mismo archivo, el
núcleo creará una estructura de objeto abierto y un descriptor de archivo en cada invocación de la llamada
al sistema open. Luego se tendrían dos objetos de archivo abierto, cada uno con su correspondiente
descriptor de archivo.
La llamada al sistema open devuelve el descriptor del archivo abierto al proceso que invocó la
llamada. Para poder operar sobre un archivo abierto el proceso debe pasar el descriptor del archivo como
argumento de las posteriores llamadas al sistema asociadas a las operaciones que desee realizar sobre el
archivo.
Todos los descriptores de archivos asociados a un mismo proceso se indexan en una tabla denomina
tabla de descriptores de archivos. Esta tabla es local a cada proceso, es decir, cada proceso tiene su
propia tabla de descriptores de archivos. Luego un mismo descriptor de archivo puede referirse en dos
procesos distintos a archivos diferentes.
Cada entrada de una tabla de descriptores de archivos contiene un puntero a la estructura de objeto
de archivo abierto a la que está asociado el descriptor. También contiene una serie de indicadores que
especifican el tratamiento que debe dar al descriptor ante la aparición de determinados eventos.
Por su parte, un objeto de archivo abierto contiene, entre otros, los siguientes datos:
•
Puntero de lectura/ escritura. Indica el byte del archivo donde se realizará la próxima operación
de lectura o de escritura. Se especifica como un desplazamiento desde el origen del archivo. En
SOBUNIX el acceso al contenido de un archivo se realiza por defecto de forma secuencial, aunque
es fácil implementar el acceso directo o aleatorio a un determinado byte del archivo usando la
llamada al sistema l s e e k (ver sección 5.2. 1 ) .
•
Puntero a l nodo virtual del archivo. L a mayoría d e S OBUNIX son capaces de soportar y mani­
pular diferentes tipos de sistemas de archivos. Para implementar esta propiedad el subsistema de
archivos del núcleo dispone de una capa de software denominada capa nodo virtual/sistema de
archivo virtual que se encarga de encaminar cada operación sobre un archivo perteneciente a un
determinado tipo de sistema de archivos hacia la función dependiente del sistema de archivos que
implementa dicha operación. Un nodo virtual, o más abreviadamente nodo-v (ver sección 5 . 3 . 1 ), es
una estructura de datos que el núcleo crea en memoria principal para cada archivo distinto abier­
to. En un nodo-v se almacena información que el núcleo necesita conocer para operar sobre un
archivo.
Los S OBUNIX implementan una estructura de directorios de gráfica acíclica. El directorio raíz
es el directorio 1 '. Este carácter también se utiliza para separar cada componente del nombre de ruta
'
Sistemas Operativos Basados en UNIX (SOBUNIX) : introducción general
25
absoluta o relativa de un archivo. Dentro del directorio raíz suelen existir, entre otros, los directorios que
se muestran en la Tabla 1 .2.
Directorio
/bin
/boot
/ dev
/ etc
/ home
/ l ib
/mnt
/ ro o t
/ sbin
/ tmp
/usr
Contenido
Archivos binarios asociados a comandos y programas esenciales del sistema
Archivos necesarios para el arranque del sistema
Archivos de dispositivos
Diferentes archivos de configuración del sistema
Cuentas de los usuarios ordinarios
Diferentes librerías compartidas
Montaje de dispositivos temporales
Directorio borne del superusuario
Archivos binarios fundamentales del sistema
Archivos temporales
Aplicaciones d e usuario
Tabla 1.2 - Algunos directorios existentes en el sistema de archivos de los SOBUNIX
1 .7.
Seguridad y protección en SOBUNIX
Los SOBUNIX son sistemas multiusuario, es decir, pueden atender simultáneamente a múltiples
usuarios. Además también tienen la capacidad de gestionar grupos de usuarios. En las siguientes sec­
ciones se describen los elementos que de forma general se usan en los SOBUNIX para implementar la
seguridad y la protección de los datos de los usuarios : los identificadores reales, la máscara de modo de
un archivo y los identificadores efectivos. También se describe cómo se implementa la seguridad y la
protección haciendo uso de estos elementos.
Señalar que cada SOBUNIX puede implementar mecanismos de seguridad adicionales a los meca­
nismos generales que se describen en las siguientes secciones.
1.7. 1 .
Identificadores reales
Cada usuario tiene asignado un identificador de usuario (User IDentifier, UID) que es un número
entero positivo que lo identifica de manera unívoca. El identificador de usuario UID=O está reservado
para designar a un usuario privilegiado conocido como superusuario o root, el cual dispone de privilegios
que no tienen el resto de usuarios, como por ejemplo: leer, escribir o ejecutar cualquier archivo.
Por otra parte, en los SOBUNIX cada usuario pertenece a uno o varios grupos de usuarios. Cada
grupo de usuarios tiene asignado un identificador de grupo (Group IDentifier, GID) que es otro número
entero positivo.
En los SOBUNIX a cada usuario reconocido en el sistema se le asigna un UID y un GID cuando
se le crea una cuenta de trabaj o en el sistema. A este par de valores se les denomina de forma general
26
Ampliación de sistemas operativos
como identificadores reales. En el caso del superusuario sus identificadores reales son UID=O y GID=O.
Nótese que aunque un usuario solo tiene asociado un GID puede pertenecer a varios grupos.
El núcleo mantiene los identificadores reales de los usuarios en un archivo cuya nombre de ruta
absoluta normalmente es / e t c /pas swd. Además en este archivo también se mantiene la siguiente in­
formación sobre cada usuario: nombre de usuario, contraseña de acceso encriptada, nombre completo
del usuario, nombre de ruta absoluta del directorio de trabaj o inicial y el nombre de ruta absoluta del
intérprete de comandos que utiliza por defecto.
El archivo pas swd puede ser leído por todos los usuarios, sin embargo sólo puede ser modificado
por el superusuario. Para crear un nuevo usuario, el superusuario puede usar, por ejemplo, el coman­
do u s eradd o el comando addu s e r . Para eliminar un usuario puede usar el comando u s erde l o el
comando de l u s e r . Para modificar los datos de un usuario puede usar el comando u s e rmod.
También, es posible impedir el acceso a un usuario sin borrar sus datos. Para ello el superusuario
solo tiene que escribir, en la línea asociada al usuario en el archivo pas swd, el carácter 1 * 1 delante de
la x asociada a la contraseña encriptada del usuario cuyo acceso se desea impedir.
e
Ejemplo 1.8
Supóngase que en un cierto S OB UNIX pueden acceder los siguientes usuarios : roo t , pedro 9 0 , j uan
y mar i . Si el usuario pedro 9 0 ejecuta la orden
cat / e t c / p a s swd
en la pantalla se mostrará el contenido del archivo p a s swd. Este archivo contiene una línea por cada
usuario reconocido por el sistema operativo. Supóngase que la línea asociada al usuario pedro 9 O es la
siguiente:
p edro 9 0 : x : 1 0 1 : 1 0 : Pedro B l anco : / exp o r t / home /pedro 6 9 : / b i n / ba s h
Los datos del usuario s e separan por e l carácter 1 : 1 De izquierda a derecha s e muestran l o s siguientes
datos: pedr o 9 O es el nombre de usuario, x indica que la contraseña se encuentra encriptada dentro del
archivo cuyo nombre de ruta absoluta suele ser / e t c / s hadow, 1 0 1 es el UID, 1 0 es el GID, Pedro
B l anco es el nombre completo del usuario, / expo r t / home / pedro 6 9 es el nombre de ruta absoluta
del directorio de trabaj o inicial, y / b i n / bash es el nombre de ruta absoluta del intérprete de comandos
que utiliza por defecto el usuario.
•
Por ejemplo si se desea impedir el acceso al usuario pedr o 9 O su línea del archivo debería modificarse
de la siguiente forma:
pedro 9 0 : * x : 1 0 1 : 1 0 : Pedro B l anc o : / expo r t / home /pedro 6 9 : / b i n / ba s h
Nótese que s i s e examinan detenidamente las líneas del archivo pas swd s e observará que existen más
líneas que las cuatro esperadas en principio, una por cada usuario habilitado. Esto es así porque en
SOBUNIX la ejecución de ciertos programas requiere de la asignación de un usuario ficticio.
•
Sistemas Operativos B asados en UNIX (SOBUNIX) : introducción general
27
Asimismo, la información sobre la composición de los grupos, es decir, los usuarios que forman parte
de cada grupo, es almacenada por el sistema operativo en un archivo cuyo nombre de ruta absoluta suele
ser 1 e t c 1 group.
El archivo 1 e t c / group puede ser leído por todos los usuarios, sin embargo sólo puede ser modifica­
do por el superusuario. Para crear un nuevo grupo, el superusuario puede usar, por ejemplo, el comando
groupadd o el comando addgroup . Para eliminar un grupo puede usar el comando g roupde l . Si se
desea modificar la composición de un grupo el superusuario puede usar el comando g roupmod. Otra
opción sería editar directamente el contenido del archivo 1 e t c 1 group .
e
Ejemplo 1.9
Considérese el sistema del ejemplo anterior, si un usuario ejecuta la orden:
c a t / e t c / group
en la pantalla se mostrará el contenido del archivo group. Este archivo contiene una línea por cada grupo
de usuarios reconocido por el sistema operativo. Dentro de una línea los datos asociados a un grupo se
separan por el carácter : Supóngase que este archivo contiene, entre otras, la siguiente línea:
1
1
•
s t a f f : : 1 0 : mar i , j uan
Los datos, de izquierda a derecha, contenidos en esta línea son los siguientes: s t a f f es el nombre del
grupo, : : indica que no existe especificada una contraseña de acceso al grupo, 1 0 es el GID, y mar i y
j uan son los nombres de dos usuarios añadidos a este grupo. De acuerdo con esta información al grupo
s t a f f pertenecen todos los usuarios que tengan asignado el GID= 1 0, como era el caso del usuario
pedro 9 0 , y los usuarios mar i y j uan.
Señalar que al igual que sucedía con / e t c /pas swd en / e t c / group existen líneas asociadas a gru­
pos ficticios, creados durante la instalación de ciertos programas y cuya existencia es necesaria para su
correcta ejecución.
•
l. 7 2
.
.
Máscara de modo de un archivo
Representación binaria
En los SOBUNIX cada archivo tiene asociado, entre otros atributos. (ver sección 5 . 2 . 1 ) , un número
binario de 1 6 bits denominado máscara de modo (ver Figura 1 .5). Si un bit de la máscara está a 1 se
considera activado, en caso contrario estará desactivado. La información contenida en la máscara de
modo es la siguiente:
•
Tipo de archivo (B 1 5 B 14B 1 3 B 1 2 ). Algunos de los tipos de archivos más comunes soportados en
los SOBUNIX son: archivo ordinario ( 1 000), directorio (0 1 00), archivo asociado a dispositivo
modo carácter (00 1 0), archivo asociado a dispositivo modo bloque (O 1 1 0), tubería (000 1 ), enlace
simbólico ( 1 0 1 0) y conector (socket) ( 1 1 00).
Ampliación de sistemas operativos
28
•
•
•
•
•
•
Bit s_I SUID (B u ). Si este bit se encuentra activado entonces cuando un usuario ejecute este
archivo su identificador efectivo de usuario (ver sección 1 .7 . 3 ) se hará igual al UID del propietario
del archivo.
Bit S_I SGID (B 1 0 ). Tiene una utilidad semejante al bit S_I SUID pero a nivel de grupo. Es decir,
si este bit se encuentra activado entonces cuando un usuario ejecute este archivo su identificador
efectivo de grupo (ver sección 1 .7.3) se hará igual al GID del propietario del archivo.
Bit S_I SVTX (B 9 ), también denominado bit pegajoso (sticky bit). La activación de este bit indica
al sistema operativo que la región de código del archivo ejecutable va a ser compartida por varios
procesos y en consecuencia debe mantenerse en la memoria principal aunque termine el primer
proceso cuya ejecución produj o que se cargará dicha región de código. En el caso de programas
utilizados por distintos usuarios (editores, compiladores, etc) esta técnica permite ahorrar memoria.
Permisos de acceso del usuario propietario del archivo (BsB 7 B 6 ). Se puede establecer de forma
independiente tres tipos de permisos : lectura (B8), escritura (B 7 ) y ejecución (B 6 ).
Permisos de acceso para los usuarios pertenecientes al grupo propietario del archivo (BsB 4 B 3 ).
Se pueden establecer de forma independiente tres tipos de permisos: lectura (Bs), escritura (B 4 ) y
ejecución (B 3 ). Por defecto el grupo propietario es aquel cuyo GID coincide con el GID asignado
al usuario propietario del archivo. Tanto el usuario propietario como el grupo propietario pueden
ser cambiados usando la llamada al sistema chown o el comando homónimo.
Permisos de acceso para el resto de usuarios (B 2 B 1 Bo). Es decir, para aquellos usuarios que no son
ni el propietario ni pertenecen al grupo propietario. Se pueden establecer de forma independiente
tres tipos de permisos : lectura (B 2 ), escritura (B 1 ) y ejecución (Bo).
Representación binaria
Tipo de archivo
s_r s G I D
+
S
I SU I D
S
Permisos propietario
I SVTX
Permisos otros usuarios
Permisos grupo propietario
Representación octal
Figura 1.5 - Máscara de modo de un archivo en representación binaria y en representación octal
Sistemas Operativos B asados en UNIX (SOBUNIX) : introducción general
29
Nótese que en el caso de que el archivo sea un directorio, entonces el permiso de lectura permite leer
las entradas del directorio, el permiso de escritura permite añadir o borrar una entrada al directorio y el
permiso de ejecución permite buscar una entrada en el directorio.
Representación octal
De los 1 6 bits que componen la máscara de modo de una archivo solo los bits B 1 1 a Bo pueden ser
modificados por el superusuario o el propietario. Estos doce bits se suelen representar mediante cuatro
cifras octales 0 3 0 2 0 1 00 (ver Figura 1 . 5) que tienen el siguiente significado:
•
0 3 . Establece el valor de los bits S_I SUID, s_I SGID y s_I SVTX, ya que es la codificación en
octal de los bits B l 1 B 10B 9 .
•
0 2 . Establece los permisos de acceso del usuario propietario del archivo ya que es la codificación
en octal de los bits BsB7B 6 .
•
0 1 . Establece los permisos de acceso del grupo propietario del archivo ya que es la codificación
en octal de los bits BsB4B 3 .
•
00 . Establece los permisos de acceso al archivo del resto de usuarios ya que es la codificación en
octal de los bits BzB 1 Bo .
Representación simbólica
La máscara de modo de un archivo también se suele representar usando una cadena de 1 O caracteres
(ver Figura 1 . 6) a la que se denomina máscara simbólica. El significado y los valores de cada uno de
estos caracteres es el siguiente:
•
c 9 . Este carácter establece el tipo de archivo. Puede tomar los siguientes valores :
ordinario), 1 d 1 (directorio), 1 e 1 (archivo asociado a un dispositivo modo carácter),
asociado a un dispositivo modo bloque), 1 p (tubería), 1 1 1 (enlace simbólico) y 1 s
1
•
1 - 1 (archivo
1 b 1 (archivo
1 (conector).
c 8 , c5 y c2 . Estos tres caracteres establecen el permiso de lectura para el propietario, el grupo
propietario y el resto de usuarios, respectivamente. Cada uno de estos bits puede tomar de forma
independiente los siguientes valores : r 1 (permiso de lectura concedido) o 1 - 1 (permiso de lectura
denegado) .
1
•
c7 , c4 y e 1 . Estos tres caracteres establecen el permiso de escritura para el propietario, el grupo
propietario y el resto de usuarios, respectivamente. Cada uno de estos bits puede tomar de forma
independiente los siguientes valores : 1 w (permiso de escritura concedido) o 1 1 (permiso de
escritura denegado).
1
•
c 6 . Este carácter establece la activación del bit S_I SUID y el permiso de ejecución para el propie­
tario del archivo. Puede tomar los siguientes valores : 1 - 1 (bit S_I SUID desactivado y permiso de
Ampliación de sistemas operativos
30
Estado
S
Permisos
propietario
I SG I D
-1
o
:.r::.;os
Tipo de archivo
Estado
S
S
I SU I D
I SVTX
Figura 1.6 - Máscara de modo de un archivo en representación simbólica
ejecución denegado), 1 x 1 (bit s_r sum desactivado y permiso de ejecución concedido), 1 s 1 (bit
S_I SUID activado y permiso de ejecución denegado) y 1 s 1 (bit s_r sum activado y permiso de
ejecución concedido).
•
CJ . Este carácter establece la activación del bit s_I S G I D y el permiso de ejecución para el grupo
propietario del archivo. Puede tomar los siguientes valores:
(bit s_I SGID desactivado y per­
miso de ejecución denegado), 1 x 1 (bit S_I SGID desactivado y permiso de ejecución concedido),
1 s 1 (bit S_I SGID activado y permiso de ejecución denegado) y 1 s (bit S_I SGID activado y
permiso de ejecución concedido).
1
-
1
1
•
co . Este carácter establece la activación del bit S_I SVTX y el permiso de ejecución para el resto de
usuarios del archivo. Puede tomar los siguientes valores : - (bit S_I SVTX desactivado y permiso
de ejecución denegado), 1 x 1 (bit s_I SVTX desactivado y permiso de ejecución concedido), 1 T 1
(bit S_I SVTX activado y permiso de ejecución denegado) y 1 t (bit S_I SVTX activado y permiso
de ejecución concedido).
1
1
1
e
Ejemplo 1.10
Supóngase que el archivo / heme / p rueba . txt tiene la siguiente máscara simbólica:
- r - s -ws - - t
El primer carácter ( - ) de la máscara indica que se trata de un archivo ordinario. Los siguientes tres carac­
teres (r - s ) especifican que el propietario tiene permisos de lectura y ejecución sobre el archivo, además
el bit S_I SUID está activado. Los caracteres ( -ws ) indican que el grupo propietario únicamente tiene per­
miso de escritura, además el bit S_I SGID está activado. Los últimos tres caracteres ( - - t) especifican
que el resto de usuarios tienen solo permiso de ejecución, además el bit S_I SVTX está activado.
Sistemas Operativos B asados en UNIX (SOBUNIX): introducción general
31
De acuerdo con esta máscara de modo simbólica la máscara de modo binaria sería:
1000 111 101 010 001
A partir de la representación en binario es sencillo obtener la máscara octal:
7521
•
Configuración de la máscara de modo de un archivo
Cuando un proceso crea un archivo haciendo uso de las llamadas al sistema c r e a t u open, el sistema
operativo se encarga de configurar los cuatro bits de la máscara de modo que especifican el tipo del
archivo. Los doce bits restantes de la máscara son inicializados por el proceso especificando uno de los
argumentos de entrada de estas llamadas al sistema (ver sección 5 . 2 . 1 ) . Posteriormente, el propietario del
archivo o el superusuario pueden cambiar el valor de los 1 2 últimos bits de la máscara de modo haciendo
uso de la llamada al sistema chrnod o del comando homónimo.
e
Ejemplo 1.11
Considérese el archivo / home / prueba . txt del ejemplo anterior. Se desea que todos los usuarios tengan
permiso de lectura sobre dicho archivo. La máscara de modo, expresada en binario, que debería tener el
archivo para tener estos permisos sería:
1000 111 101 110 101
Cuya máscara octal equivalente es :
7565
Para conceder estos permisos el propietario del archivo o el superusuario puede usar el comando chrnod
en un interprete de comandos de la siguiente formé :
chrnod 7 5 6 5 / home / prueba . txt
Si se ejecuta ahora el comando
l s - l / home / prueba . txt
se puede comprobar que la máscara simbólica del archivo tiene los permisos deseados, es decir, que su
máscara de modo simbólica es:
- r - s rwS r - t
•
4Si se consulta la página del comando chmod en el manual de ayuda se puede comprobar que este comando también soporta
otra sintaxis basada en argumentos de tipo carácter que especifican los permisos que se quieren añadir o eliminar en la máscara
de modo. De las dos sintaxis posibles se puede usar la que más se prefiera.
32
Ampliación de sistemas operativos
l. 7 3
.
.
Identificadores efectivos
En los SOBUNIX cada usuario, aparte de los identificadores reales, también tiene asignados un
identificador de usuario efectivo (Effective User IDentifier, EUID) y un identificador de grupo efectivo
(Effective Group IDentifier, EGID). Estos identificadores efectivos son consultados por el núcleo en
diferentes circunstancias, como por ejemplo cuando un usuario intenta crear o abrir un archivo, o si un
proceso desea enviar una señal a otro proceso.
Los identificadores efectivos se inicializan con el valor de sus identificadores reales cuando un usua­
rio inicia una sesión de trabaj o en el sistema. Por otra parte, si un usuario intenta ej ecutar un archivo que
tiene su bit S_I SUID activado entonces el EUID se configura con el valor del UID del propietario del
archivo. Lo mismo ocurre a nivel de grupo si se activa el bit S_I SGID. Esta propiedad resulta muy útil
para permitir a un usuario ej ecutar programas que son propiedad de usuarios más privilegiados, como el
superusuario.
e
Ejemplo 1.12
El programa / bin /pas swd se utiliza para cambiar la contraseña de un usuario. Este programa tiene que
acceder al archivo de texto / e t c / p a s swd que contiene los datos de todos los usuarios. Por motivos de
seguridad este archivo solo puede ser escrito por el superusuario.
Si se ejecuta el comando
ls
-1
/ b i n / p a s swd
se puede comprobar que el propietario de este archivo ejecutable es el superusuario (usuario r o o t ) y que
su máscara simbólica es :
- r-s r-s r-x
Se observa que e l archivo puede ser leído y ejecutado por todos los usuarios. Además están activa­
dos los bits S_I SUID y S_I SGID. En consecuencia cuando un usuario ejecuta el comando pas swd,
sus identificadores efectivos se hacen iguales a los identificadores reales del superusuario, es decir,
EUID=O y EGID=O. Ello posibilita que durante la ejecución del comando se pueda escribir el archi­
vo / e t c /pas swd.
•
Un usuario puede conocer los valores de sus identificadores UID, EUID, GID, EGID usando las
llamadas al sistema getu i d, g e t eu i d, getgid y g e t e g i d, respectivamente. Asimismo para cambiar
los valores de estos identificadores se pueden usar las llamadas al sistema s e tu i d y s e tg i d, respec­
tivamente. Si estas llamadas las invoca el superusuario entonces podrá cambiar el valor de todos los
identificadores, tanto los reales como los efectivos . Si las invoca un usuario ordinario solo podrá conse­
guir que sus identificadores efectivos tomen el valor de sus identificadores reales.
También es posible comprobar, usando la llamada al sistema a c c e s s , si un usuario dispone de acceso
a un archivo. Esta llamada usa para realizar esta comprobación los identificadores reales UID y GID en
lugar de los efectivos EUID y EGID .
Sistemas Operativos Basados en UNIX (SOBUNIX) : introducción general
Utilidad
Comando
chown
chmod
groupadd
groupde l
groupmod
pas swd
su
u s e radd
u s e rde l
u s e rmod
33
Cambiar el propietario de un archivo
Cambiar la máscara de modo de un archivo
Añadir un grupo de usuarios
Eliminar un grupo de usuarios
Modificar la cuenta de un grupo de usuarios
Cambiar la contraseña de un usuario
Cambiar de usuario
Añadir un usuario
Eliminar un usuario
Modificar la cuenta de un usuario
Tabla 1.3 - Algunos comandos básicos asociados a la seguridad y a la protección en S OBUNIX
Llamada al sistema
access
chmod
chown
getegid
g e t eu i d
getgid
getu i d
s e tg i d
s e tu i d
Utilidad
Comprobar s i u n usuario puede acceder a u n archivo
Cambiar el propietario de un archivo
Cambiar la máscara de modo de un archivo
Obtener e l valor del EGID d e u n usuario
Obtener e l valor del EUID d e u n usuario
Obtener e l valor del GID d e u n usuario
Obtener e l valor del UID d e u n usuario
Configurar e l valor del GID y del EGID d e u n usuario
Configurar e l valor del UID y del EUID d e u n usuario
Tabla 1.4 - Algunas llamadas al sistema básicas asociadas a la seguridad y a la protección en SOBUNIX
En las Tablas 1 . 3 y 1 .4 se recopilan los comandos y las llamadas al sistema más utilizadas en los
S OBUNIX asociadas a la seguridad y a la protección. Señalar que algunos comandos tienen el mismo
nombre que algunas llamadas al sistema, estos comandos invocan durante su ejecución a las llamadas al
sistema homónimas.
1 .7.4.
Implementación de la seguridad
Acceso al sistema
El acceso de un usuario a un SOBUNIX se realiza a través de un programa de acceso o programa
de login que puede presentar una interfaz en línea de comandos o una interfaz gráfica. Este programa
se ejecuta con el EUID del superusuario ya que el archivo asociado al programa tiene su bit S_I SUID
activado.
El programa de login en primer lugar solicita al usuario su nombre de usuario y su contraseña. A
continuación encripta la contraseña y comprueba que los valores introducidos por el usuario coinciden
34
Ampliación de sistemas operativos
con los almacenados en el archivo / e t c /pas swd. En caso afirmativo accede de nuevo a este archivo
para leer los identificadores reales del usuario e invoca a las llamadas al sistema s e tu i d y s e tg i d. Con
ello se consigue que los identificadores reales y efectivos del programa de login pasen a tomar los valores
del UID y GID del usuario que desea acceder al sistema. Finalmente, el programa de login invoca a un
intérprete de comandos, en concreto al especificado para el usuario en / e tc / p a s swd. Nótese que el
proceso asociado al intérprete y todos los procesos creados a partir de éste heredarán los identificadores
reales y efectivos del programa de login. También los heredarán los archivos u otros recursos abiertos
debido a la actividad del usuario.
Protección de los archivos
En los S OBUNIX el núcleo implementa la protección de un archivo haciendo uso de la máscara de
modo del archivo y de los identificadores efectivos. Cuando un proceso desea abrir un archivo previa­
mente creado debe invocar a la llamada al sistema open. Esta llamada analiza la mascara de modo del
archivo y los identificadores efectivos para determinar si el proceso puede acceder al archivo y con que
privilegios. En caso afirmativo, devuelve un descriptor de archivo. En caso contrario devuelve el valor
-l.
Cuando se realiza una operación sobre un archivo abierto el núcleo examina el modo de apertura del
archivo almacenado en el obj eto de archivo abierto para verificar si la operación se puede realizar o debe
ser denegada. El modo de apertura se especifica como un argumento de la llamada al sistema open (ver
sección 5 . 2 . 1 ) .
e
Ejemplo 1.13
S upóngase que en el directorio de trabajo actual existe el archivo da t o s l que tiene la siguiente máscara
de modo simbólica:
- rw- rw- rwDe la máscara se deduce que se trata de un archivo ordinario, que los bits S_I SUID, S_I SGID y S_I SVTX
están desactivados y que todos los usuarios tienen permiso de lectura y escritura sobre el archivo.
Supóngase que un proceso de un usuario distinto del propietario realiza la siguiente llamada al sistema
para abrir el archivo dat o s l con permiso de solo lectura ( o_RDONLY ) :
fd= open ( " da t o s l " , O_RDONLY )
En este caso el permiso de apertura especificado por el proceso es más restrictivo que los permisos que
especifica la máscara de modo,
El núcleo consultaría la máscara de modo del archivo y los identificadores efectivos para comprobar si
el proceso puede abrir el archivo. En este caso si que puede abrirlo por lo que el núcleo le asigna un
descriptor de archivo que se almacena en la variable fd y un objeto de archivo abierto.
•
Sistemas Operativos B asados en UNIX (SOBUNIX) : introducción general
35
Señalar que el acceso a un archivo también depende de los permisos de acceso que tengan cada uno
de los componentes (directorios) del nombre de la ruta absoluta de un archivo. Si los componentes de la
ruta no tienen permisos de lectura y ejecución no se podrá acceder al archivo.
e
Ejemplo 1.14
S upóngase que el directorio de trabajo actual es / horne . Si la máscara simbólica de este directorio se
configura a
d rwx - - - - - entonces ningún usuario excepto el propietario del directorio podrá acceder al directorio. De esta forma el
propietario no tiene necesidad de especificar los permisos de los archivos contenidos en dicho directorio
ya que ningún usuario excepto él y el superusuario pueden acceder a dicho directorio.
•
1 .8.
Resumen
El sistema operativo UNIX fue desarrollado por Ken Thompson en los laboratorios B ell de AT&T
a principios de los años setenta. Puesto que debido a la legislación norteamericana vigente AT &T no
podía comercializar UNIX directamente, no tuvo inconveniente en otorgar licencias de UNIX a las uni­
versidades con fines educativos y de investigación. Esto propicio que la comunidad universitaria aportara
sugerencias e ideas a AT&T para mejorar UNIX. De hecho la Universidad de California en B erkeley
introdujo tantos cambios en el código fuente que comercializó su propio UNIX con el nombre de B S D .
Aparte d e las universidades, algunas empresas fabricantes d e computadores y software también obtuvie­
ron sus propias licencias de UNIX y produjeron sus propias distribuciones, como por ejemplo: Xenix,
SunOS, AIX y HP-UX. Debido a la proliferación de distribuciones de UNIX, AT&T también decidió
entrar en el negocio a través de una compañía filial, y lanzó sus propias distribuciones como : System III
y System V.
La gran variedad de S OBUNIX resultaba un serio problema para los desarrolladores de aplicaciones
software. Las diferencias entre unos SOBUNIX y otros propiciaban que una misma aplicación pudiera
no funcionar correctamente en todos los sistemas . Para intentar resolver este problema se han creado
diferentes estándares o especificaciones que definen una API y las características que deben tener los
intérpretes de comandos y los shell scripts . Entre los estándares definidos destacan POSIX y SUS .
Los SOBUNIX comparten una serie de características comunes : son sistemas de tiempo compartido,
son sistemas multiprogramados y multiusuario, soportan multiprocesamiento, el núcleo está escrito en
su mayor parte en lenguaje C y posee una estructura de tipo monolítica, la planificación se realiza a
nivel de procesos o de hilos del núcleo usando un algoritmo de planificación basada en múltiples colas
de planificación y realimentación, administran la memoria principal e implementan la memoria virtual
usando la técnica de demanda de página, soportan una estructura de directorios de gráfica acíclica, el
directorio raíz se denota con el símbolo '/' que además se usa para separar los componentes del nombre
de ruta de un archivo, implementan las abstracciones de nodo virtual y sistema de archivos virtual lo
36
Ampliación de sistemas operativos
que les permite soportar diferentes tipos de sistemas de archivos, y los dispositivos de E/S se integran
dentro del sistema de archivos mediante el uso de archivos de dispositivos modo bloque y archivos de
dispositivos modo carácter.
Los SOBUNIX soportan dos posibles tipos de interfaces con los usuarios : interfaz de línea de coman­
dos e interfaz de usuario gráfica. Nótese que desde una interfaz gráfica también se puede disponer de una
interfaz de línea de comandos . A través de estos interfaces un usuario puede invocar a otros programas o
aplicaciones.
La interfaz de línea de comandos se implementa mediante un intérprete de comandos que es un pro­
grama que acepta un comando introducido por un usuario a través del dispositivo de entrada estándar
(por defecto el teclado) y ejecuta su código asociado. El resultado de la ejecución se muestra, general­
mente, en el dispositivo de salida estándar (por defecto la pantalla) . Una vez finalizada la ej ecución del
comando el intérprete queda a la espera de recibir otra orden por parte del usuario.
Cada S OBUNIX suele incluir por defecto en su distribución un determinado intérprete de comandos,
pero el usuario si así lo desea puede utilizar otro. Entre los intérpretes de comandos más conocidos se
encuentran los siguientes : B oume shell ( sh), C shell ( c s h) , TENEX C shell (tc sh), Kom shell (ksh), y
B oume-Again shell (bash).
Las interfaces de usuario gráficas de la mayoría de SOBUNIX se basan en el sistema X Window,
también denominado abreviadamente como X. El sistema X Window es un sistema de ventanas, es
decir, la capa de software más interna de un GUI que se encarga de envíar y recibir datos del hardware
(pantalla, teclado y ratón) y que contiene las funciones primitivas básicas para la representación gráfica
de líneas y fuentes, asociadas a las ventanas y al puntero del ratón. X Windows se caracteriza por su alta
portabilidad ya que se ej ecuta fuera del espacio de direcciones del núcleo.
Desde el punto de vista de su ejecución tanto los interfaces como los programas tendrán asociado
cada uno al menos un proceso monohilo o multihilo. Un proceso (o un hilo) para solicitar los servi­
cios del núcleo del sistema operativo tiene que realizar las llamadas al sistema correspondientes. En los
S OBUNIX un proceso para hacer una llamada al sistema invoca a una función de envoltura o redireccio­
namiento de la librería C estándar, también denominada l ib e abreviadamente. Cada llamada al sistema
tiene asociada al menos una función de envoltura.
Los S OBUNIX son sistemas multiusuario, es decir, pueden atender simultáneamente a múltiples
usuarios . Además también tienen la capacidad de gestionar grupos de usuarios . Para implementar la
seguridad y la protección de los datos de los usuarios los SOBUNIX utilizan los siguientes elementos:
identificadores reales (UID y GID), identificadores efectivos (EUID y EGID) y máscara de modo de un
archivo.
1 .9.
Lecturas recomendadas
Si se desea obtener una explicación adicional de los contenidos tratados en este capítulo se pue­
den consultar, por ejemplo : el capítulo 10 de [Tanenbaum, 2009] , el capítulo 1 de [Vahalia, 1 995], los
capítulos 1 a 6, 10, 1 2, 1 3 y 14 de [Love et al. , 2005 ] , y los capítulos 1 , 3 y 6 de [Márquez, 2004] .
S istemas Operativos B asados en UNIX (SOBUNIX) : introducción general
1 .10.
37
Autoevaluación
1.1. ¿Cuándo se desarrollo el sistema operativo UNIX? ¿ Quién fue su creador? ¿Qué compañía era la
propietaria de sus derechos? (Respuesta en sección 1 .2)
1.2. ¿Qué motivó la proliferación de diferentes distribuciones de UNIX? (Respuesta en sección 1 .2)
1.3. ¿Qué universidad desarrolló su propia distribución de UNIX? ¿Cómo se llamaba dicha distribu­
ción? (Respuesta en sección 1 . 2)
1.4. ¿Qué distribuciones de UNIX comercializó AT &T a través de una compañía filial ?
(Respuesta en sección 1 .2)
1.5. Enumerar tres ejemplos actuales de distribuciones comerciales de UNIX y tres ejemplos actuales
de distribuciones libres . (Respuesta en sección 1 .2)
1.6. ¿Cuáles son los estándares de compatibilidad más usados en los SOBUNIX?
(Respuesta en sección 1 .3)
1.7. Enumerar las características principales de los SOBUNIX . (Respuesta en sección 1 .4)
1.8. ¿Qué es un intérprete de comandos? ¿Cuáles son los intérpretes de comandos más conocidos en
los S OBUNIX? (Respuesta en sección 1 .5 . 1 )
1.9. ¿Cuál es l a estructura general de un comando? (Respuesta en sección 1 .5 . 1 )
1. 10. ¿Para que sirve el comando roan? ¿ Y el comando i n f o ? (Respuesta en sección 1 .5 . 1 )
1.11. Explique l a utilidad de los siguientes comandos: cd, cp, l s , mkd i r , mv, mvd i r , pwd, rm y rmd i r .
(Respuesta e n sección 1 . 5 . 1 )
1.12. Explique la utilidad de los siguientes comandos : c a t , f i nd, grep, more y s o r t .
(Respuesta e n sección 1 .5 . 1 )
1. 13. ¿Qué es un comodín en los intérpretes de comandos de los SOBUNIX? Explique la utilidad de los
siguientes comodines : ' * , ? y [ J (Respuesta en sección 1 .5 . 1 )
'
'
'
11
11 •
1. 14. ¿Cómo se puede conseguir el redireccionamiento de l a entrada y de l a salida en un intérprete de
comandos? ¿ Y el encadenamiento de órdenes ? (Respuesta en sección 1 .5 . 1 )
1. 15. ¿Cómo se puede asignar un alias a una orden o cadena de órdenes ? ¿Cómo s e elimina dicho alias ?
(Respuesta en sección 1 .5 . 1 )
1. 16. Explicar razonadamente si la asignación de un alias es temporal o permanente.
(Respuesta en sección 1 .5 . 1 )
1. 17. ¿Qué es un comando externo? ¿ Y un comando interno? (Respuesta en sección 1 .5 . 1 )
38
Ampliación de sistemas operativos
1. 18. ¿Qué se entiende por trabaj o (j ob) en el contexto de un intérprete de comandos?
(Respuesta en sección 1 .5 . 1 )
1. 19. ¿Cómo se debe escribir una orden para que sea ejecutada e n segundo plano?
(Respuesta en sección 1 .5 . 1 )
1 .20. Explique l a utilidad de los siguientes comandos : fg, b g y j obs . (Respuesta e n sección 1 .5 . 1 )
1.21. Explique qué sucede e n u n intérprete de comandos s i s e pulsan las teclas :
a) [contro l ] + [ z ] . b) [contro l ] + [ e ] . (Respuesta en sección 1 .5 . 1 )
1 .22. ¿Qué son las variables del intérprete de comandos? ¿Cómo s e pueden visualizar?
(Respuesta en sección 1 .5 . 1 )
1 .23. ¿Qué información contiene l a variable del intérprete PATH? ¿Cómo se puede añadir el directorio
de trabajo actual a dicha variable? (Respuesta en sección 1 .5 . 1 )
1 .24. ¿ Qué son las variables de entorno de un proceso? ¿Cómo s e pueden visualizar las variables de
entorno del intérprete de comandos? (Respuesta en sección 1 .5 . 1 )
1 .25. ¿Cómo s e puede exportar una variable del intérprete a s u entorno? ¿Cómo se puede eliminar una
variable del intérprete? (Respuesta en sección 1 .5 . 1 )
1 .26. ¿Qué es un shell script? ¿Cómo se crea? (Respuesta e n sección 1 .5 . 1 )
1 .27. Explicar razonadamente las diferentes formas posibles d e ejecutar u n shell script.
(Respuesta en sección 1 .5 . 1 )
1 .28. Explicar razonadamente qué es el sistema X Window y cómo funciona. (Respuesta en sección 1 .5.2)
1 .29. ¿Qué es un widget toolkit? Enumerar algunas widgets toolkits usadas en SOBUNIX.
(Respuesta en sección 1 .5 .2)
1 .30. ¿Qué componentes básicos suele incluir un entorno de escritorio de los SOBUNIX? Enumerar
algunos ejemplos. (Respuesta en sección 1 .5 .2)
1.31. Explicar razonadamente cómo se invocan y cómo se tratan las llamadas al sistema en los S OBU­
NIX. (Respuesta en sección 1 .5 . 3 )
1 .32. ¿Cómo s e estructura la información contenida en los archivos e n los SOBUNIX?
(Respuesta en sección 1 .6)
1 .33. Los SOBUNIX ¿distinguen entre mayúsculas y minúsculas en los nombres de los archivos ?
(Respuesta e n sección 1 .6)
1 .34. Explicar razonadamente si en los SOBUNIX los nombres de los archivos pueden usar extensiones.
(Respuesta en sección 1 .6)
Sistemas Operativos B asados en UNIX (SOBUNIX) : introducción general
39
1.35. ¿Qué es un descriptor de archivo? ¿Y un obj eto de archivo abierto? (Respuesta en sección 1 .6)
1.36. ¿Cuántas tablas de descriptores de archivos existen en el núcléo? (Respuesta en sección 1 . 6)
1.37. ¿Qué información contiene un objeto de archivo abierto? (Respuesta en sección 1 .6)
1.38. ¿Qué tipo de estructura de directorios implementan los SOBUNIX? ¿Con que carácter se repre­
senta al directorio raíz del sistema de archivos principal? (Respuesta en sección 1 .6)
1.39. Enumerar y explicar el contenido de cinco de los directorios contenidos dentro del directorio raíz
del sistema de archivos principal de los SOBUNIX. (Respuesta en sección 1 .6)
1.40. ¿Cuáles son los identificadores reales de un usuario? ¿Qué valor toman estos identificadores en el
caso del superusuario? (Respuesta en sección 1 .7 . 1 )
1.41. ¿Qué información contiene el archivo / e t c / pa s swd? ¿ Y el archivo / e t c / gr oup ?
(Respuesta en sección 1 .7 . 1 )
1.42. ¿Cómo s e pueden crear y eliminar usuarios en los SOBUNIX? ¿Es posible impedir el acceso a un
usuario sin eliminar su cuenta? (Respuesta en sección 1 .7 . 1 )
1.43. ¿Cómo s e pueden crear, modificar y eliminar grupos de usuarios en los SOBUNIX?
(Respuesta en sección l . 7 . 1 )
1.44. Explicar razonadamente qué es la máscara de modo de u n archivo y comentar e l significado de
cada uno de los bits en su representación binaria. (Respuesta en sección 1 .7 .2)
1.45. Explicar razonadamente el significado de cada uno de los caracteres de la representación simbólica
de la máscara de modo de un archivo. (Respuesta en sección 1 .7 .2)
1.46. ¿Qué comando se utiliza para modificar la máscara de modo de un archivo?
(Respuesta en sección 1 .7.2)
1.47. ¿Cuáles son los identificadores efectivos de un usuario? ¿Cuándo son consultados por el núcleo?
(Respuesta en sección 1 .7 . 3 )
1.48. Explicar l a relación existente entre e l bit s_I SUID d e la máscara d e modo d e un archivo y el
identificador EUID . (Respuesta en sección 1 .7 . 3 )
1.49. Explicar para qué se utilizan las siguientes llamadas a l sistema: getuid, g e t eu i d, getgid,
g e t e g i d, s e tu i d, s e t e u i d y acc e s s . (Respuesta en sección 1 .7.3)
1.50. Explicar cómo se realiza el acceso de un usuario a un SOBUNIX . (Respuesta en sección 1 .7 .4)
1.51. Explicar cómo se implementa la protección de archivos en los S OBUNIX.
(Respuesta en sección 1 .7 .4)
40
Ampliación de sistemas operativos
1.11.
Ejercicios
1.1. Supóngase que en un cierto S OBUNIX el directorio de trabajo actual de un usuario contiene los
archivos da t o s , f o t o smu l , l i s t as . txt, ex l , a l umno s . da t , trabaj o s . txt y asdo, y los
directorios f o t o s , v i d e o s y corre o s . Indicar la orden que se debe escribir en un intérprete de
comandos para realizar cada una de las siguientes acciones :
a) Visualizar la ruta absoluta del directorio de trabaj o actual .
b) Visualizar un listado del contenido del directorio de trabajo que permita diferenciar entre
archivos y directorios.
e) Visualizar un listado que únicamente contenga los nombres de los archivos que acaban con
la letra 'o' o con la letra ' t ' .
d ) Mover al subdirectorio f o t o s los archivos dat o s y f o t o smu l .
e) Hacer que el directorio f o t o s pase a ser el directorio de trabajo actual .
1.2. Explique razonadamente cuál sería el resultado de la ej ecución de las siguientes órdenes :
a) s o r t < fA > f B
b) l s
-1
> asd
e) l s
-i
> > wer t 2 3
d) more � / prueba . tx t
e ) c p par t e { p r imera , s egunda } trabaj o s
1.3. Consulte l a página del manual man o l a bibliografía que considere necesarias y conteste a las
siguientes cuestiones relativas al intérprete de comandos bash:
a) ¿Cómo es posible conocer todos los intérpretes de comandos disponibles en un cierto SO­
BUNIX?
b) ¿Cómo se puede saber dónde se aloj a el intérprete bash?
e) ¿Cómo es posible saber si el intérprete de comandos que estamos utilizando es el intérprete
bash?
d) ¿Cómo se puede saber la versión de bash que estamos utilizando?
e) ¿Qué variables son consideradas especiales en bash?
f) ¿Para qué sirve la sustitución de comandos y cómo se implementa?
g) Explicar la diferencia entre los siguientes entrecomillados: " c adena " y 'c adena'
h) ¿Cómo se pueden introducir datos procedentes del teclado?
i) Enumerar los operadores lógicos, los operadores de comparación de cadenas y los operadores
de comparación de números enteros disponibles en bash.
Sistemas Operativos Basados en UNIX (SOBUNIX) : introducción general
41
j) Enumerar algunos de los operadores de comparación de atributos de archivos disponibles en
bash.
k) Explicar el significado del operador [ expre s i ón J .
1) Explicar cómo se pueden realizar operaciones aritméticas con enteros en bash.
m) Explicar cómo se declara una sentencia condicional de tipo i f.
n) Explicar cómo se declara un bucle de tipo whi l e o de tipo unt i l .
o) Explicar cómo s e declara un bucle de tipo f o r .
p ) Explicar cómo s e declara una sentencia d e tipo c a s e .
q) Explicar cómo s e declara y s e invoca una función que reciba parámetros d e entrada. Explicar
también cómo se pueden retornar valores desde una función.
1.4. Explique razonadamente el funcionamiento del shell script que se muestra en la Figura 1 .7.
1.5. Explique razonadamente el funcionamiento del shell script que se muestra en la Figura 1 . 8 .
1.6. Escribir un shell script para e l intérprete b a s h que muestre l a fecha y l a hora del sistema cada
segundo durante un minuto. Ayuda: para la realización de este ejercicio resulta muy útil el uso de
los comandos s l e ep y da t e .
1.7. Escribir u n shell script para e l intérprete ba sh que muestre e l día d e l a semana que fue ayer. Ayuda:
para la realización de este ejercicio resulta muy útil el uso del comando da t e .
1.8. Buscar l a utilidad d e l a función sys t em y escribir u n programa en C d e ejemplo d e uso d e esta
función.
1.9. La máscara de modo del archivo regular resul t ado s expresada en octal es 6644 :
a) Explique razonadamente el significado de todos los bits de esta máscara de modo.
b) Escriba la máscara de modo simbólica asociada a este archivo.
e) ¿Qué orden se debe escribir en un intérprete de comandos para que la máscara simbólica del
archivo pasase a ser
-
rwx r-
-
- -T?
1.10. La máscara de modo simbólica del archivo ej ecutable s 0 7 que resulta de compilar el programa que
se muestra en la Figura 1 .9 es - rwxrw- rwx y dicho archivo pertenece al usuario Wo l f (UID=50 1 ,
GID=202). Explique razonadamente el funcionamiento del programa en los siguientes casos: a)
El programa lo ej ecuta wo l f . b) El programa lo ejecuta el usuario Fox (UID=502, GID=203) .
42
Ampliación de sistemas operativos
# ! / b i n / ba s h
#
echo
" I n t ro du c e una c adena : "
read CADENA
wc - e )
LONG I TUD= $ ( echo $ CADENA
wh i l e
[
$ L ONGI TUD - g t O
do
X= " $ X " $ ( e cho $ CADENA
J
c u t - c $ LONG I TUD )
LONG I TUD= $ ( ( $ LONG I TUD -
1) )
done
echo
" $X "
Figura 1.7 - Shell script del Ejercicio 1 .4
# ! / b i n / ba s h
#
if
[
$#
-gt O
for i
)
;
then
in $ *
do
mv $ i
if
[
$ HOME / p ap e l e r a 2 >
$?
- eq O
)
;
/ dev / nu l l
then
echo
" $ i ha s i do mov i do a l a pap e l e r a con éxi t o "
echo
" $ i no h a p o d i do s e r movi do a l a p ap e l e ra "
else
fi
done
e ls e
echo
" Error :
echo
" $ 0 archivo 1
hay qu e e s p e c i f i c ar argumen t o s "
[ ar c h i vo 2 )
. . .
"
exi t 1
fi
ex i t O
Figura 1.8 - Shell script del Ejercicio 1 .5
Sistemas Operativos Basados en UNIX (SOBUNIX) : introducción general
f l o a t a l ( f l oa t
( *b )
( float a ) ) ;
f l o a t a 2 ( f l oa t a ) ;
ma i n ( )
{
int u [ 3 ] ;
f l oa t z = O ;
u [ 0 ] =getui d ( ) ;
u [ l ] = g e t eu i d ( ) ;
u [ 2 ] = s e tu i d ( u [ l ] ) ;
if
(u [ 2 ] ==0 )
{
z = a l ( a2 ) ;
p r i n t f ( " \ n [ %d ,
f l oat al ( f l oat
( *b )
!hl ,
!hl ,
% . 2f ] \n" , u [ O ] , u [ l ] , u [ 2 ] , z ) ;
( f loat a ) )
{
f l oat u = 3 0 . 4 ;
u= ( *b ) ( u ) ;
return ( u ) ;
f l oa t a 2 ( f l oa t a )
{
int h ;
f o r ( h= - l ; h< 3 ; h+ + )
{
return ( a ) ;
Figura 1.9
-
Código e del programa S o 7 del Ejercicio 1 . 1 o
43
Capítulo 2
SOBUNIX: implementación y control de
procesos multihilos
Objetivos docentes
Los objetivos docentes de este capítulo son los siguientes :
•
Conocer los conceptos y las estructuras de datos fundamentales que utilizan los SOBUNIX para
implementar los procesos multihilos.
•
S aber cómo se realiza la creación de nuevos procesos y la invocación de programas en los SOBU­
NIX.
•
Saber cómo se realiza la terminación de procesos en los SOBUNIX.
•
Conocer el uso, funcionamiento e implementación de la notificación de eventos mediante señales
en los S OBUNIX.
•
Saber cómo se realiza el control de los hilos de usuario mediante el uso de la librería de hilos
Pthreads de POSIX.
•
Conocer qué son y para qué sirven los conceptos de grupos de procesos y sesiones en los S OBU­
NIX.
•
Saber qué es el sistema de archivos de procesos (procfs), conocer la información que contiene y
cómo se consulta.
45
Ampliación de sistemas operativos
46
2. 1.
Introducción
Uno de los principales servicios que debe proporcionar un sistema operativo es posibilitar la eje­
cución de los programas de los usuarios. Para lograr este objetivo se utiliza el modelo de proceso. Un
proceso es una instancia de un programa en ejecución que requiere la asignación de diferentes recursos
para poder existir y progresar. El modelo de proceso utilizado en los primeros S OBUNIX consideraba
que un proceso únicamente sigue una determinada traza o ruta de instrucciones en su ej ecución, es decir,
tiene un único hilo de control. Sin embargo los SOBUNIX desarrollados con posterioridad comenzaron
a utilizar diferentes modelos de procesos multihilos ya que permiten mejorar el rendimiento del sistema.
Este capítulo está dedicado al estudio de la implementación y control de los procesos multihilos
en los SOBUNIX. En primer lugar se introducen los conceptos fundamentales necesarios para entender
los posibles modelos de procesos multihilos . En segundo lugar se describen las estructuras de datos
que se utilizan para implementar los procesos multihilos. En tercer lugar se describe la creación de
procesos y la invocación de programas. En cuarto lugar se describe la terminación de procesos. En
quinto lugar se estudia la notificación de eventos mediante el uso de señales. En sexto lugar se describe
el control de los hilos de usuario mediante el uso de librería de hilos, en concreto se toma como ejemplo la
librería Pthreads de POSIX. En séptimo lugar se estudia los conceptos de grupos de procesos y sesiones.
Finalmente se describe el sistema de archivos de procesos (procfs).
2.2.
2.2.1.
Implementación de los procesos multihilos en SOBUNIX
Conceptos fundamentales
Un programa es un archivo ejecutable que típicamente se encuentra almacenado en memoria secun­
daria. Considerado como archivo, un programa es una entidad pasiva o estática. Cuando un programa es
ej ecutado se convierte en una entidad activa o dinámica denominada proceso que va pasando por dife­
rentes estados y utiliza distintos recursos del computador. En definitiva, un proceso es un programa en
ej ecución.
Un proceso se puede considerar como una entidad computacional básica que tiene asignado un con­
j unto de recursos y que durante su existencia ejecuta una serie de instrucciones. Así un proceso queda
caracterizado por dos elementos que se pueden tratar de forma independiente:
•
Conjunto de recursos asignados. Un proceso tiene asociado un espacio de direcciones de memo­
ria virtual (código, datos, pila, . . . ) y otros recursos, tales como archivos abiertos, procesos hijos,
manejadores de señales, información de contabilidad, etc.
•
Hilos de control o simplemente hilos (thread). Un hilo es un subconjunto de instrucciones del có­
digo del proceso que se puede ej ecutar independientemente del resto de instrucciones del proceso.
En un computador con N procesadores es posible ejecutar en paralelo N hilos pertenecientes a uno
o varios procesos .
En general se distinguen los siguientes tipos de hilos en función de sus propiedades y usos :
SOBUNIX: implementación y control de procesos multihilos
47
•
Hilos del núcleo (kernel threads) . Son hilos asociados al código del núcleo del sistema operativo
que son creados y gestionados por el propio núcleo para la realización de funciones especificas,
como por ej emplo: dar soporte a procesos, atender operaciones de E/S , tratamiento de interrup­
ciones, etc . Los hilos del núcleo no necesitan estar asociados a ningún proceso.
•
Hilos de usuario (user threads) . Son parte del código de un determinado proceso de usuario. El
programador al diseñar un programa es el encargado de establecer el número de hilos de usuario
en que se va descomponer el código del programa. Si el código de un programa consta de un único
hilo de usuario entonces al proceso asociado se le denomina proceso monohilo. M ientras que si se
descompone en varios hilos de usuario se denomina proceso multihilo. Para la gestión de los hilos
de usuario el programador utiliza una librería de hilos, como por ej emplo la librería Pthreads de
POSIX (ver sección 2 . 3 .4). Una librería de hilos contiene funciones para la creación, destrucción,
planificación y sincronización de los hilos de usuario, entre otras operaciones . El sistema operativo
generalmente no suele conocer la existencia de los hilos de usuario, aunque debe dar servicio a las
llamadas al sistema que pueda realizar la librería de hilos para implementar la gestión de los hilos.
Además internamente la librería de hilos puede crear hilos cuya existencia es desconocida por los
hilos de usuario que gestiona.
•
Procesos ligeros (lightweight processes). También denomi nados procesadores virtuales. Son hilos
de usuario cuya gestión es realizada por el núcleo 1 del sistema operativo. Un proceso ligero puede
estar asociado a uno o varios hilos de usuario. Es la librería de hilos la que se encarga de multiplexar
los hilos de usuario de un determinado proceso en un número menor o igual de procesos ligeros.
Los procesos ligeros solo se pueden utilizar en aquellos sistemas operativos cuyo núcleo soporte
hilos del núcleo, ya que cada proceso ligero tiene que tener asociado un hilo del núcleo para poder
ser planificado y ej ecutado.
Los SOBUNIX desarrollados hasta mediados de los ochenta usaban el proceso como unidad de
planificación y ej ecución. El principal inconveniente de estos sistemas es que el bloqueo de un hilo de
usuario de un proceso produce el bloqueo del proceso completo.
Posteriormente se comenzaron a desarrollar SOBUNIX que usaban al hilo del núcleo como unidad
básica de planificación y ejecución. Estos sistemas también pueden soportar, por lo tanto, procesos lige­
ros . La principal ventaj a de soportar hilos del núcleo es que el bloqueo de un hilo del núcleo asociado
a un proceso ligero de un proceso no supone el bloqueo de todos los procesos ligeros de dicho proceso;
por lo que se evita tener que realizar un cambio de proceso. B asta con realizar un cambio de hilo, el cual
introduce una menor sobrecarga. Además en un computador con varios procesadores (o un procesador
con varios núcleos) es posible obtener un verdadero paralelismo durante la ej ecución de un proceso, ya
que cada proceso ligero de un proceso se puede planificar, a través de su hilo del núcleo asociado, en un
procesador.
El principal inconveniente de los hilos del núcleo es que, a diferencia de los hilos de usuario, consu­
men recursos del núcleo y su gestión implica la ej ecución del núcleo. Por este motivo, muchos sistemas
1 En algunos sistemas operativos el te1mino proceso ligero también se utiliza como sinónimo del término
independientemente de si el núcleo conoce la existencia y gestiona dicho hilo.
hilo de usuario
48
Ampliación de sistemas operativos
reciclan los hilos de núcleo existentes . Cuando un hilo del núcleo finaliza su ejecución, se marca como
no planificable, pero sus estructuras de datos asociados no son eliminadas . Cuando se tiene que crear
un nuevo hilo del núcleo, lo que se hace es que se reactiva algún hilo del núcleo marcado como no
planificable con el objetivo de ahorrarse la sobrecarga de asignar estructuras de datos al nuevo hilo.
e
Ejemplo 2. 1
Un ej emplo de SOBUNIX que soporta hilos del núcleo y procesos ligeros es el sistema operativo Solaris.
Desde su versión 2.2 hasta su versión 8.0 soportaba un modelo de proceso multihilo en el cual los hilos
de usuario eran multiplexados en un número menor de procesos ligeros.
La gestión de los hilos de usuario se realiza mediante el uso de una librería de hilos . Solaris dispone de su
propia librería de hilos l ibthread, aunque también soporta la librería p threads de POSIX. Haciendo
uso de las funciones de estas librerías es posible crear, destruir, planificar y sincronizar hilos de usuario.
Una librería de hilos también se encarga de crear por defecto un conj unto de procesos ligeros asociado a
cada proceso, y de multiplexar los hilos de usuario sobre los procesos ligeros. El tamaño de ese conjunto
depende del número de hilos de usuario y del número de procesadores del computador.
Los procesos ligeros son invisibles por defecto al programador, con lo que solo se tiene que preocupar
de programar los hilos de usuario. Aunque si lo desea puede especificar el número de procesos ligeros
que se deben crear. También puede asociar un proceso ligero a un único hilo de usuario, garantizando de
esta forma que dicho hilo siempre tendrá un proceso ligero asociado .
En la Figura 2. 1 a se representa, a modo de ejemplo, un proceso multihilo que consta de cuatro hilos de
usuario. Uno de los hilos está asociado a un proceso ligero. Los tres hilos restantes son multiplexados
sobre dos procesos ligeros. Cada proceso ligero tiene a su vez un hilo del núcleo asociado.
Usar un modelo de proceso multihilo con un mayor número de hilos de usuario que procesos ligeros
resulta útil para aplicaciones en las cuales no es necesario que la mayoría de sus hilos se ejecuten concu-
Proceso multihilo
Proceso multihilo
Hilo de usuario
Proceso ligero
Hilo del núcleo
(a)
(b)
Figura 2.1 - Ejemplo de proceso multihilo soportado en: a) Solaris 2.2. b) Solaris 1 0 .
SOBUNIX : implementación y control de procesos multihilos
49
rrentemente. Por ejemplo, cada elemento de la interfaz gráfica de una aplicación (ventana, iconos, barra
deslizadora, menús, etc) puede ser programado como un hilo de usuario. En un cierto instante solo unos
pocos de dichos elementos se encontrarán activos, luego solo los hilos de usuario asociados a dichos
elementos deben estar ej ecutándose y en consecuencia necesitan tener asignado un proceso ligero.
Este modelo de proceso no resulta adecuado para aplicaciones que requieren que la mayoría de sus hilos
se ejecuten concurrentemente, ya que la librería de hilos gastaría un tiempo de ejecución importante en la
planificación y en los cambios de hilos. Recuérdese que al existir un mayor número de hilos de usuario
que de procesos ligeros, la librería de hilos debe decidir que hilos de usuarios van a tener un proceso
ligero asociado.
En defi nitiva, este modelo de proceso multihilo presenta como principal ventaj a que permite implementar
la concurrencia sin usar demasiados recursos del núcleo. Su principal inconveniente es que la implemen­
tación de un buen planificador de hilos en la librería de hilos es compleja y costosa computacionalmente.
También con este modelo resulta bastante laborioso implementar el tratamiento de las señales (ver sec­
ción 2 . 3 . 3 ) a nivel de la librería de hilos.
Con el fin de evitar los inconvenientes de este modelo Solaris a partir de su versión 8.0 comenzó a
soportar también un modelo de proceso multihilo donde cada hilo de usuario tiene asociado un único
proceso ligero (ver Figura 2. 1 b) . Desde Solaris 10 este es el único modelo soportado.
En este modelo de proceso multihilo la planificación y sincronización de los hilos de usuario, entre otras
tareas de gestión, se delega en el núcleo. Ello ha permitido simplificar el código fuente de la librería de
hilos l i bthread.
•
2.2.2.
Estructuras de datos asociadas a los procesos multihilos
La implementación de un modelo de proceso multihilo requiere la creación y manejo de diferentes
estructuras de datos tanto para el proceso como para los hilos de usuario. Además si el sistema operativo
soporta hilos del núcleo y procesos ligeros entonces también debe mantener estructuras de datos aso­
ci adas a los mismos. En las siguientes secciones se comentan las principales estructuras de datos que
generalmente se mantienen en los S OBUNIX para implementar los procesos multihilos.
Estructuras asociadas a los procesos
Los SOBUNIX suelen mantener en el espacio de direcciones del núcleo una estructura de datos
denominada tabla de procesos que tiene una entrada por cada proceso existente en el sistema. Dicha
entrada se implementa como una estructura de datos, la cual se denomina en algunos SOBUNIX como
estructura pro c . Esta estructura contiene, entre otros, los siguientes datos sobre un determinado proceso :
•
Localización del espacio de direcciones virtuales del proceso. Se mantiene un puntero a una es­
tructura que contiene información sobre la ubicación del espacio de direcciones virtuales de un
proceso (ver sección 4 . 2 . 3 ) .
50
Ampliación de sistemas operativos
•
Identificadores del proceso. Cada proceso tiene asociado un número entero positivo que lo identi­
fica de manera univoca. A dicho identificador se le conoce generalmente con el nombre de identi­
ficador del proceso (Process IDentifier, PID). El número máximo de procesos que pueden existir
de manera simultánea está limitado y suele ser configurable por el superusuario. En consecuencia
el PID puede tomar valores comprendidos entre O y un cierto valor máximo PIDmax . Este límite
máximo no supone generalmente un problema ya que como el tiempo de vida de algunos procesos
es corto sus PIDs pueden ser reutilizados. También un proceso tiene asociado un identificador de
grupo de procesos y un identificador de sesión (ver sección 2 . 3 . 5) .
•
Credenciales del proceso. Generalmente quedan definidos por los identificadores d e usuario y de
grupo reales y efectivos, es decir, UID, GID, EUID y EGID. Estos identificadores relacionan a un
proceso con un determinado usuario y grupo.
•
Estado del proceso. El tiempo de vida de un proceso puede descomponerse en un conjunto de
estados que definen su comportamiento. Las transiciones entre los estados se realizan debido a la
aparición de diferentes eventos. El número y el nombre de los estados soportados dependen de
cada S OBUNIX. Algunos estados habituales son: inicial o creado, preparado para ej ecución, ej e­
cutándose en modo usuario, ejecutándose en modo núcleo, dormido (bloqueado), parado y zombi
(terminado).
•
Parámetros de planificación. Es la información que utiliza el planificador para decidir que proceso
planificar, como por ej emplo, la prioridad de planificación del proceso o el tiempo de uso del
procesador.
•
Información estadística. Como el tiempo de ejecución en modo usuario y el tiempo de ejecución
en modo supervisor del proceso y de sus procesos hijos.
•
Información sobre los procesos ligeros en que se descompone el proceso. Esta información solo se
mantiene si el núcleo soporta hilos del núcleo.
•
Información genealógica. Como el PID del proceso padre y punteros a las estructuras proc de su
proceso padre, de sus procesos hijos y de sus procesos hermanos.
•
Información para el tratamiento de las señales. Como se verá en la sección 2 . 3 . 3 existen máscaras
de bits que permiten especificar qué señales serán ignoradas, qué señales serán bloqueadas y cuáles
serán capturadas .
•
Información para la implementación del sistema de archivos procfs. El sistema de archivos de pro­
cesos procfs es un pseudosistema de archivos existente en algunos S OBUNIX que permite acceder
a los usuarios a la información que mantiene el núcleo sobre los procesos . Dicha información se
almacena en archivos y se organiza en directorios.
•
Á rea de usuario, denominada abreviadamente área-u. Se trata de una estructura de datos que con­
tiene aquella información asociada al proceso que necesita ser consultada por el núcleo únicamente
SOBUNIX: implementación y control de procesos multihilos
51
cuando el proceso está siendo ejecutado, como por ejemplo: un puntero a la tabla de descriptores
de archivos abiertos por el proceso, información sobre el archivo ejecutable a partir del cual se
generó el proceso, los argumentos pasados a la función principal ma in del código del proceso,
los argumentos de la llamada al sistema exec (ver sección 2 . 3 . 1 ), las variables de entorno, las
direcciones de los manejadores definidos para el tratamiento de las señales capturadas, etc.
En los SOBUNIX que no soportan hilos del núcleo en el área-u también se suelen almacenar
la pila del núcleo asociada al proceso y el contexto hardware salvado del proceso. Una pila del
núcleo es una estructura que contiene los marcos de pila de las funciones invocadas por el núcleo
durante la ej ecución del proceso en modo núcleo. El contexto hardware salvado son los valores
que contenían los registros del computador (contador de programa, registro de pila, registro de
estado del procesador, etc) cuando se interrumpió la ej ecución del proceso debido a un cambio
de contexto. El contexto hardware será restaurado cuando el proceso vuelva a ser planificado y se
continúe con la ej ecución del proceso.
En algunos S OBUNIX el área-u de un proceso se implementa en el espacio de direcciones del
proceso en una estructura externa a la estructura proc del proceso. En dicho caso en la entrada de
la tabla de procesos se mantiene un puntero al área-u .
•
Punteros para implementar listas enlazadas de procesos. E l núcleo mantiene diferentes listas para
poder consultarlas durante la planificación de los procesos o cuando se produce algún evento. Por
ejemplo, pueden existir listas de procesos preparados, listas de procesos dormidos (bloqueados)
por determinados eventos, etc. Estas listas se implementan mediante punteros a las estructuras
proc de los procesos que forman parte de cada lista.
Estructuras asociadas a los hilos de usuario
En el modelo de proceso multihilo, el proceso es entendido como un contenedor de recursos y los
hilos de usuarios como unas secuencias de instrucciones. Los hilos de usuario comparten el espacio de
direcciones virtuales del proceso y todos sus recursos (credenciales, archivos abiertos, etc).
Cada hilo de usuario tiene asignada una pila de usuario, que es una estructura que contiene los
marcos de pila de las funciones invocadas por el hilo durante su ejecución en modo usuario. Además
también es necesario mantener, entre otros, los siguientes datos de cada hilo de usuario :
•
Identificador del hilo de usuario. Es un número entero positivo que identifica de manera univoca a
un hilo de usuario dentro de un proceso.
•
Contexto hardware salvado en modo usuario. Son los valores que contenían los registros del
computador cuando se interrumpió la ejecución del hilo en modo usuario debido a una llamada
al sistema o a un cambio de hilo. El contexto hardware en modo usuario será restaurado cuando se
continúe con la ej ecución del hilo en modo usuario.
•
Prioridad. Es consultada por el planificador implementado a nivel de la librería de hilos, si existe
alguno.
52
Ampliación de sistemas operativos
•
Máscara de señales. Especifica el tratamiento que se realizará cuando llegue una determinada
señal (ver sección 2 . 3 . 3 ) .
La pila d e usuario y la información asociada a u n hilo d e usuario e s mantenida e n e l espacio de
direcciones del proceso por la librería de hilos de usuario.
Estructuras asociadas a los procesos ligeros
Los S OBUNIX que soportan procesos ligeros deben mantener en el espacio de direcciones del núcleo
una estructura de datos por cada uno de los procesos ligeros en que se descompone un proceso. Dicha
estructura, denominada lwp en algunos SOBUNIX, contiene entre otros los siguientes datos: contexto
hardware salvado en modo usuario, un puntero a la estructura proc del proceso del que forma parte, un
puntero al hilo del núcleo que tiene asociado, información estadística de uso de recursos e información
sobre el tratamiento de señales.
Nótese que un proceso ligero no tiene asignado un identificador numérico, esto es así porque real­
mente no le hace falta ya que queda identificado por el hilo del núcleo al que está asociado, el cual si
tiene asignado un identificador numérico, como se verá en la siguiente subsección.
Recuérdese también que es la librería de hilos la que asocia un proceso ligero a un determinado hilo
de usuario. Por otra parte es el núcleo el que asocia un hilo del núcleo a dicho proceso ligero.
Estructuras asociadas a los hilos del núcleo
En los SOBUNIX que soportan hilos del núcleo el sistema operativo debe mantener en su espacio de
direcciones una estructura de datos y una pila del núcleo por cada hilo del núcleo. La estructura de datos
asociada a un hilo del núcleo contiene la siguiente información:
•
Identificador del hilo núcleo. Es un número entero positivo que identifica de manera univoca a
cada hilo del núcleo.
•
Contexto hardware salvado. Son los valores que contenían los registros del computador cuando se
interrumpió la ejecución del hilo del núcleo debido a un cambio de contexto. El contexto hardware
será restaurado cuando el hilo del núcleo vuelva a ser planificado y se continúe con la ejecución
del hilo.
•
Parámetros de planificación. Es la información que utiliza el planificador del núcleo para decidir
qué hilo del núcleo planificar, como por ejemplo, la prioridad de planificación del hilo o el tiempo
de uso del procesador.
•
Punteros para implementar diferentes colas de hilos del núcleo. Como colas de hilos preparados
para ejecución, colas de hilos dormidos, etc.
•
Puntero a la pila del núcleo asociada al hilo.
SOBUNIX : implementación y control de procesos multihilos
•
53
Información sobre el proceso ligero asociado. Como por ejemplo un puntero a la estructura lwp
del proceso ligero al que está asociado y un puntero a la estructura pro e del proceso del que forma
parte el proceso ligero. Si el hilo del núcleo no está asociado a ningún proceso ligero, entonces
estos punteros contienen valores NULL.
Por su parte, una pila del núcleo es una estructura que contiene los marcos de pila de las funciones
invocadas por el hilo durante su ejecución en modo núcleo. Está pila está vacía cuando el hilo del núcleo
se ejecuta en modo usuario.
e
Ejemplo 2.2
El sistema operativo Solaris 1 0 soporta un modelo de proceso multihilo en el que cada hilo de usua­
rio tiene asociado un proceso ligero (ver Figura 2. 1 b) . El núcleo para implementar este modelo utiliza
principalmente las siguientes estructuras de datos:
•
Estructura proc. Se utiliza para implementar una entrada de la tabla de procesos. Algunos de los
campos presentes en una estructura proc son :
- p_exe c . Puntero al nodo-v del archivo ejecutable a partir del cual se creó el espacio de
direcciones virtuales del proceso.
- p_a s . Puntero a una estructura que contiene información sobre la ubicación del espacio de
direcciones virtuales del proceso.
- p_c red. Puntero a una estructura que contiene los credenciales del proceso .
- p_s t a t . Contiene e l estado del proceso. E n un determinado instante d e tiempo e l estado de
un proceso puede tomar uno de los siguientes valores:
o
S I DL (creado). Estado inicial de un proceso mientras está siendo creado.
o
SRUN (preparado para ejecución). El proceso se encuentra preparado para ser planifica­
do.
o
SONPROC (ejecutándose). El proceso está siendo ejecutado en un procesador.
o
SSLEEP (dormido). El proceso se encuentra dormido a la espera de que ocurra un deter­
minado evento, por ejemplo, que se complete una operación de E/ S .
o
S STOP (parado). La ejecución del proceso h a sido detenida por u n depurador de proce­
sos.
o
S Z OMB (zombi) . El proceso ha terminado.
Si un proceso únicamente consta de un único hilo de usuario entonces el estado del proceso
coincide con el estado del hilo de usuario, el cual queda definido por el estado del hilo del
núcleo asociado al proceso ligero del hilo de usuario.
Si se tiene un proceso multihilo, cada hilo puede encontrarse en un estado distinto . En es­
te caso el estado del proceso se fij a al de un hilo del núcleo asociado a un proceso ligero
representativo del proceso seleccionado por el núcleo.
54
Ampliación de sistemas operativos
- p__pp id. PID del proceso padre.
- Información genealógica del proceso. Se implementa mediante punteros a las estructuras
proc de algunos familiares del proceso: puntero al proceso padre ( * p__parent ) , puntero al
primer proceso hijo ( * P_chi l d) , puntero al último proceso hijo ( * P_chi l d_ns ), puntero al
siguiente proceso hermano ( * p_s ibl i ng ) , etc.
- p_s e s sp . Puntero a una estructura que almacena información sobre la sesión de trabaj o del
terminal al que pertenece el proceso (ver sección 2.3.5).
- p__p i dp. Puntero a una estructura que almacena el PID del proceso y otras informaciones
relacionadas .
- p__pgp i dp. Puntero a una estructura que almacena el identificador del grupo de procesos (ver
sección 2.3.5) y otras informaciones relacionadas.
- Información sobre los procesos ligeros asociados al proceso. Como por ejemplo el núme­
ro total de procesos ligeros asociados al proceso (p_lwpcnt ) , el número de procesos lige­
ros bloqueados (p_lwpb l o c ked) , el número de procesos ligeros preparados para ejecución
(p_lwprcnt ) , etc.
- uarea. Puntero al área-u la cual se implementa mediante una estructura u s e r . Contiene,
entre otros, los siguientes datos: puntero a la tabla de descriptores de archivos abiertos, los
argumentos pasados a la función principal ma i n del código del proceso, los argumentos de
la llamada al sistema exec y las variables de entorno.
- Campos para soportar el sistema de archivos procfs.
•
Estructura kl wp . Se utiliza para almacenar información sobre un proceso ligero. Entre la infor­
mación almacenada se encuentra la siguiente: uso de recursos, contexto hardware salvado, infor­
mación para el tratamiento de señales, puntero a la estructura proc del proceso al que pertene­
ce, puntero al hilo del núcleo asociado kthread y campos para soportar el sistema de archivos
proc f s .
•
Estructura kthread. Se utiliza para almacenar información sobre un hilo del núcleo. Algunos de
los campos presentes en esta estructura son:
- t_s tack. Puntero a la pila del núcleo asociada al hilo del núcleo.
- p_s t a t . Contiene el estado del hilo del núcleo. En un determinado instante de tiempo el
estado de un hilo del núcleo puede tomar uno de los siguientes valores (ver Figura 2.2):
o
TS_RUN (preparado para ejecución). El hilo del núcleo se encuentra preparado para ser
planificado.
o
TS_ONPROC (ejecutándose). El hilo del núcleo está siendo ejecutado en un procesador.
o
TS_SLEEP (dormido). El hilo del núcleo se encuentra dormido a la espera de que ocurra
un determinado evento, por ejemplo, que se complete una operación de E/ S .
SOBUNIX: implementación y control de procesos multihilos
Detener ej ecución
55
Ej ecución
finalizada
Continuar
Asignación
del hilo
Figura 2.2 - Diagrama de transición de estados de los hilos del núcleo en Solaris
o
TS_STOPPED (parado). La ejecución del hilo del núcleo ha sido detenida, seguramente
por un depurador.
o
TS_Z OMB (zombi). El hilo del núcleo ha terminado, pero sus datos se encuentran disponi­
bles todavía para ser leídos por los hilos encargados de recopilar información estadística
sobre el uso de recursos. Posteriormente, el hilo será recolectado por el núcleo para
formar parte de la lista de hilos del núcleo libres.
o
TS_FREE (libre) . La estructura del hilo del núcleo se encuentra disponible para ser asig­
nada a un proceso ligero o para la realización de funciones internas del núcleo. En con­
secuencia las estructuras de datos de un hilo del núcleo son reutilizadas, ahorrándose
por tanto su tiempo de su creación.
t_pr i . Prioridad de planificación del hilo del núcleo.
t_t id. Identificador numérico del hilo del núcleo.
t_lwp . Puntero a la estructura klwp del proceso ligero al que estás asociado. Si no está
asociado a ninguno, como cuando ejecuta tareas del núcleo, entonces contiene el valor NULL.
- t_procp. Puntero a la estructura proc del proceso al que estás asociado a través de un
proceso ligero. Si no está asociado a ninguno entonces contiene el valor NULL.
- t_l ink. Punteros a estructuras kthread para implementar diferentes colas de hilos del
núcleo: preparados para ejecución, dormidos y libres.
- t_next . Puntero a la siguiente estructura kthread de la lista global de hilos del núcleo. El
núcleo mantiene una lista enlazada con todos los hilos del núcleo existentes.
- t_prev. Puntero a la anterior estructura kthread de la lista global de hilos del núcleo.
56
Ampliación de sistemas operativos
En la Figura 2.3 se muestra la relación entre las estructuras de datos del núcleo de S olaris asociadas a los
procesos, a los procesos ligeros y a los hilos del núcleo, que han sido descritas en los párrafos anteriores .
Se ha considerado a modo de ej emplo un proceso A que consta de dos hilos de usuario y un proceso B
monohilo. Cada hilo de usuario tiene asociado en el núcleo un proceso ligero . A su vez cada proceso
ligero tiene asociado un hilo del núcleo de la lista global de hilos del núcleo. Señalar la existencia de
hilos del núcleo que no están asociados a ningún proceso ligero. Dichos hi los del núcleo pueden estar
libres o asociados a la ej ecución de funciones del núcleo .
En S olaris la información sobre un determinado hilo de usuario es mantenida a nivel de la librería de
hilos en una estructura u lwp . Esta estructura contiene la pila de usuario, información para la política
de planificación a nivel de hilos de usuario (si existe alguna definida), mecanismos de sincronización y
máscaras de señales.
Otra estructura de datos importante en la implementación del modelo de proceso multihilo es uberda ta.
La librería de hilos crea una estructura uberda t a por cada proceso. En ella almacena la información
necesaria para gestionar y acceder a los datos de todos los hilos de usuario asociados a un proceso.
•
2.3.
Control de procesos multihilos en SOBUNIX
2.3.1.
Creación de procesos e invocación de otros programas
La llamada al sistema
fork
En los SOBUNIX la creación de un proceso se realiza generalmente invocando a la llamada al sistema
f ork. Al proceso que invoca a f ork se le denomina proceso padre y al nuevo proceso que se crea se
le denomina proceso hijo. El proceso hijo recién creado es un copia prácticamente idéntica del proceso
padre y comparte el acceso a todos sus recursos.
La única diferencia entre el proceso hijo recién creado y el proceso padre se encuentra en algunos
campos de su estructura p r o c , es decir, de su entrada de la tabla de procesos . Por ejemplo, el PID del
proceso hij o es distinto del PID del proceso padre. Además, los campos asociados al uso de recursos
tienen que ser configurados a O. También los punteros para mantener la información genealógica tienen
que ser adaptados adecuadamente tanto en la estructura proc del padre como en la estructura del hijo.
El espacio de direcciones virtuales del proceso hij o recién creado es una copia del espacio de di­
recciones del proceso padre. Por lo tanto ambos ej ecutan el mismo programa pero en espacios indepen­
dientes . Esto significa que los cambios que realice el proceso padre en las variables de su espacio de
direcciones no afectan a los valores de las variables del espacio de direcciones del proceso hijo y vice­
versa. De hecho esta característica es un mecanismo de protección característico de los SOBUNIX . Un
proceso no puede acceder al espacio de direcciones de otro proceso, salvo que ambos compartan una
región de memoria compartida.
Para poder diferenciar, desde el punto de vista del usuario, que proceso se ej ecuta, f o rk devuelve
cuando finaliza el valor O al proceso hijo y el PID del proceso hijo al proceso padre. Es el planificador
SOBUNIX: implementación y control de procesos multihilos
57
Lista global de hilos
del núcleo
p ro e
p ro e
·- - - - - - - - - - - - - - - - - -
Figura 2.3
-
Relación entre las estructuras de datos del núcleo de Solaris para el soporte de procesos
multihilos
del núcleo el que determina si debe continuar ejecutándose el proceso padre o debe iniciarse la ejecución
del proceso hijo.
e
Ejemplo 2.3
Considérese el programa prog2 1 cuyo código en lenguaje C se muestra en la Figura 2.4. Este archivo
puede ser compilado en un SOB UNIX usando por ejemplo el compilador gcc del proyecto GNU, para
ello se puede teclear, la siguiente orden desde un intérprete de comandos:
gcc - o prog2 1 prog2 1 . c
Para ejecutar el programa compilado prog2 1 se debe escribir la siguiente orden:
prog2 1
58
Ampliación de sistemas operativos
rna i n ( )
{
int y ,
x=O ;
y= f o rk ( ) ;
if
( y= = - 1 ) {
p r i n t f ( " \nErro r " ) ;
else i f
( y= = O ) {
p r i n t f ( " \ nSoy e l h i j o P I D= %d ,
mi padre t i en e P I D= %d " , g e tp i d ( ) , g e tpp i d ( ) ) ;
x=x+ 1 ;
p r i n t f ( " \ nx= %d " , x ) ;
else {
p r i n t f ( " \ nSoy e l padre P I D= %d " , g e tp i d ( ) ) ;
x=x- 1 ;
p r i n t f ( " \ nx= %d " , x ) ;
p r i n t f ( " \ nF in " ) ;
Figura 2.4 - Código C del programa prog2 1
Nótese que para ejecutar esta orden con éxito en la variable de entorno PATH debe estar incluido el
directorio de trabajo actual. Si no es así se puede incluir escribiendo en el intérprete la siguiente orden :
PATH= $ PATH : .
S upóngase que para ejecutar el programa prog2 1 el intérprete crea el proceso A con un PID igual a 2343 .
Cuando se ejecuta este proceso en primer lugar se invoca a la llamada al sistema f o rk. Si se produjese
algún error durante el tratamiento por parte del núcleo de esta llamada al sistema, f o r k devolvería el
valor - l . Luego la condición del i f se cumpliría y se imprimiría en la salida estándar (la pantalla por
defecto) el mensaje Error. A continuación se imprimiría el mensaje F i n y la ej ecución del proceso A
finalizaría.
Si f ork se ejecuta con éxito se crea un nuevo proceso B . Se va a suponer que su PID es igual 2344.
Puesto que A y B tienen el mismo código, para distinguir su ejecución fork devuelve O al proceso hijo
y el PID del hijo al proceso padre.
S upóngase que el planificador planifica primero al proceso hij o B . En ese caso la variable y= O luego el
proceso B ejecuta el conjunto de instrucciones del bloque e l s e i f . Señalar que las funciones getpid
y g e tpp i d son llamadas al sistema que permiten obtener el PID de un proceso y el PID de su proceso
padre, respectivamente. Así en primer lugar se imprime en pantalla el mensaje:
S oy e l h i j o P I D = 2 3 4 4 , mi padre t i ene P I D= 2 3 4 3
A continuación el proceso B suma 1 a la variable x y almacena su valor en l a misma posición de memoria.
SOBUNIX: implementación y control de procesos multihilos
59
Finalmente se muestra en la pantalla el valor de x (en este caso 1) y el mensaje F in, y el proceso B
finaliza.
Supóngase que finalizado el proceso hijo B se planifica para ej ecución el proceso A. En este caso la
variable y contiene el valor 2344, es decir, el PID del proceso hijo, luego el proceso A ejecuta el conjunto
de instrucciones del bloque el s e . Así en primer lugar se imprime en pantalla el mensaj e :
Soy e l padre P I D = 2 3 4 3
A continuación el proceso resta 1 a la variable x y almacena su valor en la misma posición de memoria.
Finalmente se muestra en la salida estándar el valor de x (en este caso - 1 ) y el mensaj e F in, y el proceso
A finaliza.
Nótese que el proceso padre y el proceso hijo tienen espacios de direcciones idénticos pero indepen­
dientes. Luego los cambios que realice el proceso hij o en sus variables no afectan a los valores de las
variables homónimas del proceso padre y viceversa.
•
Las acciones que realiza la rutina del núcleo que se encarga de tratar la llamada al sistema fork
dependen de cada SOBUNIX, pero en general suele realizar las siguientes acciones [Vahalia, 1 995] :
•
Asignar una entrada de la tabla de procesos al proceso hijo, es decir, una estructura pro c .
•
Rellenar los campos d e l a estructura proc del proceso hij o a partir de l a información contenida en
la estructura proc del proceso padre.
•
Crear el área-u del proceso hij o a partir del área-u del proceso padre.
•
Asignar un PID al proceso hijo.
•
Crear el espacio de direcciones virtuales del proceso hij o a partir del espacio de direcciones del
proceso padre (ver sección 4.2.7).
•
Crear las referencias oportunas a los recursos compartidos con el proceso padre, como por ejemplo
los archivos abiertos y el directorio de trabaj o actual.
•
Inicializar el contexto hardware del proceso hijo con una copia del contexto hardware del proceso
padre para poder iniciar la ejecución del proceso hij o cuando éste sea planificado.
•
Configurar el estado del proceso a preparado para ejecución y colocarlo en alguna cola de planifi­
cación en función de su prioridad.
La llamada al sistema exe c
El proceso hijo creado por f ork ejecuta el mismo código que el proceso padre. Disponer de diferen­
tes instancias de un mismo programa resulta útil en el diseño de algunas aplicaciones, como por ejemplo,
60
Ampliación de sistemas operativos
aquellas con un esquema cliente-servidor. En otras aplicaciones interesa, sin embargo, que el proceso
hijo ej ecute un programa distinto al proceso padre. Un ej emplo típico de este caso es un intérprete de
comandos, desde el cual se invocan a otros programas .
En los S OBUNIX un proceso puede invocar a otro programa haciendo uso de la llamada al sistema
exe c . Esta llamada al sistema básicamente reemplaza las regiones del espacio de direcciones del proceso
invocador por las regiones del programa invocado. Luego cuando finaliza la llamada al sistema exec el
proceso invocador pasa a ej ecutar el código del programa invocado.
La llamada al sistema exec se utiliza en colaboración con la llamada al sistema f ork. Por ejemplo,
cuando un usuario invoca un cierto programa ej ecutable desde la línea de órdenes de un intérprete de
comandos, éste crea un proceso hij o invocando a f o rk y a continuación invoca a la llamada al sistema
exec para que el proceso hijo ejecute el programa invocado.
La llamada al sistema exec puede ser invocada a través de diferentes funciones de envoltura como
por ej emplo: exe c l , execv y exe c l e . La principal diferencia entre todas ellas radica en el número y
tipo de sus argumentos de entrada. Se distinguen tres tipos de argumentos posibles : el nombre de ruta del
archivo ejecutable, los argumentos del programa invocado especificado cada uno como un puntero a una
cadena de caracteres y el entorno que es un array de punteros a cadenas de caracteres. A cada cadena se
le conoce con el nombre de variable de entorno (ver sección 1 .5 . 1 ) .
e
Ejemplo 2.4
Considérense los archivos ejecutables prog2 2 y prog2 3 (ver Figura 2.5). S upóngase que prog2 2 es
invocado desde la línea de órdenes de un intérprete de comandos y que el intérprete crea un proceso A
para ejecutar este programa. En primer lugar el proceso A invoca una llamada al sistema f o rk. Supuesto
que la llamada se ejecuta con éxito se crea un proceso B hij o de A. Qué proceso se planificará primero,
el padre o el hijo, dependerá del planificador.
/ * C ó d i g o de prog2 2 * /
ma i n ( )
{
i f ( f o rk ( } = = 0 )
{
execv ( " prog 3 " , 0 ) ;
p r i n t f ( " \ n men s a j e l " ) ;
p r i n t f ( " \ n mens a j e 2 " ) ;
/ * C ó d i g o de prog2 3 * /
ma i n ( )
{
p r i n t f ( " \ n men s a j e 3 " ) ;
Figura 2.5 - Código C de los programas prog2 2
y
prog2 3
SOBUNIX: implementación y control de procesos multihilos
61
Se va a suponer que se ejecuta primero el proceso padre. En dicho caso, después de f ork el proceso A
evalúa la condición del i f . Como la llamada al sistema devuelve al proceso padre el PID del proceso
hijo, la condición del i f no se cumple por lo que imprime en la salida estándar men s a j e2 y finaliza su
ejecución.
Cuando se planifica el proceso B, éste evalúa la condición del i f . Como fork devuelve O al proceso
hijo, sí se cumple la condición por lo que invoca a la llamada al sistema execv. Esta llamada tiene dos
parámetros de entrada el nombre de ruta del archivo ejecutable, en este caso prog2 3 , y los argumentos
que se pasan al ejecutable, en este caso ninguno. Al atenderse esta llamada al sistema el espacio de
direcciones del proceso B es sustituido por el espacio de direcciones construido a partir de prog2 3 .
Luego, el código del proceso B pasa a ser el de prog2 3 . En consecuencia, el proceso B imprime en la
salida estándar men s a j e3 y finaliza su ejecución.
•
Las acciones que realiza la función del núcleo que se encarga de tratar la llamada al sistema exec
dependen de cada SOBUNIX, pero en general suele realizar las siguientes acciones [Vahalia, 1 995] :
•
Localizar el archivo ej ecutable del programa invocado.
•
Consultar la máscara de modo del archivo para verificar que el proceso dispone de permiso de
ejecución.
•
Leer la cabecera del archivo para comprobar si se trata efectivamente de un archivo ejecutable y
de que tipo. Si detecta que se trata de un shell script entonces invoca a un intérprete de comandos
para que lo ejecute.
•
Configurar el valor de los identificadores efectivos EUID y EGID, de acuerdo con la activación o
no de los bits S_I SUID o S_I SGID de la máscara de modo del archivo ejecutable.
•
Copiar los argumentos y el entorno en el espacio del núcleo.
•
Liberar el espacio de direcciones del proceso.
•
Asignar el nuevo espacio de direcciones del proceso a partir del archivo ejecutable del programa
invocado.
•
Copiar los argumentos y el entorno en la pila de usuario.
•
B orrar las direcciones de los manejadores de las señales y configurar su tratamiento a las acciones
por defecto.
•
Inicializar el contexto hardware salvado del proceso para que el proceso pueda comenzar cuando
vuelva de la llamada al sistema con la ejecución del programa invocado.
62
Ampliación de sistemas operativos
La llamada al sistema vfork
En los primeros SOBUNIX durante el tratamiento de f ork se duplicaban la mayoría de las páginas
del proceso padre cargadas en memoria para que el proceso hij o dispusiera de una copia de las mismas,
independiente de si el proceso hijo las iba a utilizar o no. Esto suponía un desperdició tanto de espacio
en memoria como de tiempo de uso del procesador.
Posteriormente, para evitar este duplicado innecesario de páginas los SOBUNIX comenzaron a im­
plementar la técnica de copiar al escribir ( copy on write) que consiste en aplazar la copia de una página
del proceso padre hasta que el proceso hijo tiene que escribir en la página. Señalar que esta estrategia no
se aplica sobre las páginas pertenecientes a la región de código o las regiones de memoria compartida
del proceso padre, ya que para este tipo de regiones solo se mantiene en la memoria principal una única
copia de la página, la cual es compartida por el proceso padre y sus procesos hijos.
Otra posible solución al problema del duplicado de páginas consiste en usar la llamada al sistema
v f ork. Esta llamada, introducida en el sistema BSD y posteriormente exportada a otros SOBUNIX,
bloquea al proceso padre y presta su espacio de direcciones al proceso hij o. Cuando el hij o invoca a otro
programa con exec o termina su ejecución entonces el espacio de direcciones es devuelto al proceso
padre y éste es desbloqueado.
La llamada vf ork es mucho más rápida que f o rk ya que se ahorra los pasos de configurar un nuevo
espacio de direcciones para el proceso hijo. En consecuencia, está llamada resulta muy útil cuando el
proceso hijo que se crea va a invocar posteriormente a la llamada exec para ej ecutar otro programa.
Consideraciones sobre el diseño de
fork
en procesos multihilos
En un proceso multihilo la invocación de una llamada al sistema fork es realizada por alguno de los
procesos ligeros en que se descompone el proceso. A la hora de tratar esta llamada por parte del núcleo
se plantean dos posibles opciones :
e
•
Duplicar en el proceso hijo todos los procesos ligeros del proceso. Esta opción resulta más conve­
niente cuando el proceso hij o que se crea no va a invocar posteriormente a la llamada exe c para
ejecutar otro programa. Su implementación presenta problemas asociados con el comportamiento
que deben tener los procesos ligeros del proceso hij o que sean duplicados a partir de procesos
ligeros del proceso padre que estuvieran bloqueados en espera de algún evento.
•
Duplicar en el proceso hijo solo el procesos ligero que invocó a f ork. Esta opción resulta más
conveniente cuando el proceso hijo que se crea va a invocar posteriormente a la llamada exec para
ejecutar otro programa. Su implementación puede presentar problemas asociados con la sincroni­
zación de hilos y con el soporte de la librería de hilos.
Ejemplo 2.5
S upóngase que la ejecución de un proceso A se ha descompuesto en dos procesos ligeros A l y A2. El
proceso ligero A l ha realizado una cierta llamada al sistema y se encuentra bloqueado a la espera de
recibir una entrada desde el teclado. Por su parte el proceso ligero A2 invoca a una llamada al sistema
SOBUNIX: implementación y control de procesos multihilos
63
f ork. Supóngase que esta llamada al sistema duplica todos los procesos ligeros del proceso padre. En
dicho caso se crea un proceso B con dos procesos ligeros B 1 y B2, que son duplicados de A 1 y A2,
respectivamente.
El problema surge con el proceso ligero B 1 ya que competirá con A l por obtener la entrada del teclado
produciendo una condición de carrera.
•
e
Ejemplo 2.6
Supóngase que la ejecución de un proceso A se ha descompuesto en dos procesos ligeros Al y A2.
El proceso ligero Al ha realizado una operación wa i t_s em ( s ) (ver sección 3 . 3 .2) sobre un semáforo
binario S . Por su parte el proceso ligero A2 invoca a una llamada al sistema f o rk. Supóngase que esta
llamada al sistema duplica únicamente el proceso ligero del proceso padre que invoca la llamada al
sistema. En dicho caso se crea un proceso B con un proceso ligero B2, que es un duplicado de A2.
El problema surge si el proceso ligero B2 después de ej ecutar f o rk intenta adquirir el semáforo S ha­
ciendo una operación wa i t_s em ( s ) . Como no se ha duplicado en el proceso B el proceso ligero A l el
semáforo S nunca será liberado con una operación s i gnal_s em ( s ) y en consecuencia B2 se quedará
siempre bloqueado.
•
Puesto que es complicado diseñar una única llamada al sistema f o rk que trate adecuadamente ambas
posibilidades, los SOBUNIX suelen soportan diferentes variantes de f o rk. Por ej emplo, en S olaris f o rk
duplica únicamente el proceso ligero que invoca la llamada. Si se desean duplicar todos los procesos
ligeros del proceso padre se debe utilizar la llamada al sistema f o rka l l . Cada variante trata una de las
posibilidades e intenta resolver en la manera de lo posible los problemas que dicha opción puede plantear.
Por ejemplo, durante el tratamiento de la llamada f o rka l l si alguno de los procesos ligeros del proceso
padre estaba realizando una llamada al sistema ésta es interrumpida en el duplicado del proceso ligero
del proceso hijo. Recuérdese (ver sección 1 .5 . 3 ) que si una llamada al sistema es interrumpida retorna
devolviendo el valor - 1 y almacenando un error E INTR en la variable errno . La llamada al sistema
interrumpida puede ser reiniciada por el proceso ligero duplicado si lo considera necesario.
En general, el diseño de las llamadas al sistema en SOBUNIX que soportan hilos del núcleo debe
hacerse teniendo en cuenta si los efectos de una llamada deben aplicarse únicamente al proceso ligero in­
vocador o a todos los procesos ligeros del proceso. Además en ambos casos se debe respetar la semántica
del modelo tradicional de proceso monohilo.
2.3.2.
Terminación de procesos
En los SOBUNIX si un proceso A desea terminar su ej ecución debe invocar explícitamente a la
llamada al sistema exi t. Esta llamada tiene como argumento de entrada un número entero que es puesto
a disposición del proceso padre de A para que lo examine si así lo desea. Este número denominado
generalmente estatus de salida (exit status), permite al proceso hijo especificar al padre la causa por la
que finalizó de acuerdo con un criterio previamente establecido por el programador. Generalmente se
Ampliación de sistemas operativos
64
suele considerar que si el estatus de salida es igual a O entonces el proceso termino normalmente y sin
errores, mientras que el resto de valores se utilizan para especificar los diferentes errores o causas que
produjeron la terminación del proceso.
El sistema operativo también procede de forma implícita a la terminación de un proceso después de
ejecutar la última instrucción del proceso. En este caso el núcleo también configura a un determinado
valor del estatus de salida del proceso, dicho valor depende de cada SOBUNIX.
Asimismo la terminación de un proceso A también se puede producir si el proceso A recibe una
señal (ver sección 2 . 3 . 3 ) cuyo tratamiento especifique la finalización del proceso. En este caso el núcleo
configura el valor del estatus de salida con el número que identifica a la señal que originó la terminación
del proceso.
Independientemente del motivo de la terminación de un proceso, el sistema operativo realiza esta
tarea ej ecutando una rutina del núcleo denominada exi t ( ) en la mayoría de SOBUNIX. Las acciones
que realiza exi t ( ) depende de la implementación de dicha función en cada S OBUNIX. En general
exi t ( ) suele realizar, entre otras, las siguientes acciones [Vahalia, 1 995] :
•
Deshabilitar el tratamiento de las señales.
•
Cerrar los archivos abiertos por el proceso A.
•
Almacenar en la entrada de la tabla de proceso asignada al proceso A los datos estadísticos de uso
de recursos y el estatus de salida.
•
Poner al proceso A en el estado zombi.
•
Hacer que el proceso i n i t adopte a los procesos hijos del proceso A. Conviene señalar que cuando
se arranca un SOBUNIX se crean unos pocos procesos para realizar diferentes tareas asociadas al
arranque del sistema. Entre estos procesos se encuentra el proceso inicial o proceso i n i t cuyo PID
es igual a l . Este proceso se encarga de crear todos los demás procesos necesarios para inicializar
el sistema operativo. El proceso i n i t es el primer antepasado de todos los procesos existentes,
excepto aquellos creados por el sistema operativo al arrancar. Cuando un proceso termina si tiene
hijos activos éstos son adoptados por ini t, que ejerce de proceso padre.
•
Liberar los recursos de memoria asignados al proceso.
•
Enviar una señal S I GCHLD al proceso padre del proceso A para notificarle la terminación de su
hijo.
•
Despertar al proceso padre de A si éste estaba dormido esperando por la terminación de su hijo.
En algunas aplicaciones el proceso padre necesita saber cuándo un proceso hijo ha terminado su
ejecución. Un ejemplo típico es un intérprete de comandos cuya ejecución está asociada a un cierto
proceso A. Si un usuario teclea un comando externo el proceso A crea (invocando a f ork) un proceso
hij o B y le asocia (mediante ex e e ) el código de dicho comando. A continuación ejecuta una determinada
llamada al sistema para entrar en el estado dormido a la espera de que termine su hijo. Cuando el proceso
SOBUNIX: implementación y control de procesos multihilos
65
B termine el proceso A será despertado por el núcleo y mostrará en la pantalla el apuntador del intérprete
para indicar al usuario que ya puede introducir otro comando.
Existen varias llamadas al sistema que permiten a un proceso esperar por la terminación de alguno de
sus proceso hijos, como por ejemplo : wa i t, wa i t 3 , wa i t 4 , wa i t p i d y wa i t i d. La principal diferencia
entre todas estas llamadas al sistema se encuentra en la información sobre el hij o que devuelve cada
llamada y en la posibilidad de especificar el hij o en concreto por el que se desea esperar.
e
Ejemplo 2.7
Supóngase que el programa prog2 4 (ver Figura 2.6) es invocado desde la línea de órdenes de un intér­
prete de comandos de la siguiente forma:
prog2 4 1 0
Supóngase además que a la ejecución de este programa se le asocia un proceso A . En primer lugar el
proceso A comprueba si la variable entera argc es igual a 2. En esta variable está almacenado el número
de argumentos pasados al programa por la línea de comandos. En este caso la condición se cumple ya
que el nombre del programa cuenta como primer argumento.
En segundo lugar invoca a la función de librería a t o i que convierte la cadena de caracteres argv [ 1 ]
en un número entero y almacena el resultado en la variable x . Como argv [ 1 ] contiene el segundo
argumento introducido por la línea de comandos entonces x = 1 O .
En tercer lugar comprueba si l a variable x es igual a 1 0. En caso afirmativo invoca a l a llamada al sistema
f ork para crear un proceso hijo B .
S e va a suponer que después de la llamada al sistema f o r k se continua con la ej ecución del proceso
padre. Entonces como f o rk devuelve al proceso padre el PID del proceso hijo no se cumplen las dos
ma in ( i nt argc ,
char
* argv ( ] )
{
i n t x = O , s = O , var = O ;
if
( argc = = 2 )
x = a t o i ( argv [ l ] ) ;
if
( x= = l O & &
f o rk ( ) = = O )
p r i n t f ( " \ n Pr o c e s o hi j o P I D= %d \ n " , g e tp i d ( ) ) ;
exi t ( 5 ) ;
s = wa i t ( &var ) ;
p r i n t f ( " \ n s= %d var= %d\ n " , s , var ) ;
e l s e p r i n t f ( " \ n Número de paráme t r o s i n c o r r e c t o \ n " ) ;
Figura 2.6 - Código C del programa prog2 4
66
Ampliación de sistemas operativos
condiciones del i f, luego la siguiente sentencia que ejecuta el proceso padre es una invocación de la
llamada al sistema wa i t. Esta llamada si se ejecuta con éxito devuelve en s el PID del primer hijo de
A en estado zombi que encuentra. Además almacena los ocho bits menos significativos del estatus de
salida en la dirección asociada a la variable var. Si el proceso A no tiene procesos hijos o si wa i t es
interrumpida por una señal, entonces se considera que se ha producido un error en la ejecución y la
llamada devuelve en s el valor - l .
El núcleo durante el tratamiento de una llamada al sistema wa i t borra la entrada de l a tabla de procesos
asociado al primer hijo en estado zombi que encuentra. En el caso de que el proceso A tenga procesos hi­
jos pero ninguno se encuentre en el estado zombi entonces pasa al proceso A al estado dormido mientras
espera por la terminación de alguno de sus hijos. Cuando alguno termine la función del núcleo exi t ( )
enviará al proceso A una señal S I GCHLD para notificárselo.
En este programa, supuesto que el proceso padre se ej ecuta antes que su hijo, durante el tratamiento de
wa i t el proceso A entra en el estado dormido ya que su proceso hij o no está todavía en el estado zombi.
Cuando el proceso B es planificado para ej ecución, supuesto que su PID= 3456, imprime en la salida
estándar el mensaje:
Pro c e s o hi j o P I D = 3 4 5 6
e invoca a la llamada al sistema exi t para terminar su ejecución. Nótese que el estatus de salida especi­
ficado por el proceso hijo es igual a 5 .
Durante e l tratamiento de l a llamada al sistema exi t s e despierta al proceso A. Éste al ser planificado
completa la llamada al sistema wa i t que almacena en la variable var el estatus de salida del proceso B
y en la variable s el PID del proceso B . Señalar que en realidad, debido a la implementación que hace
el núcleo de la llamada al sistema wa i t, en la variable var se almacena el estatus de salida especificado
como argumento de entrada de exi t multiplicado por 256, es decir, 256·5 = 1 280.
Por último el proceso A imprime en la salida estándar el mensaj e
s = 3 4 5 6 var = 1 2 8 0
y termina su ej ecución. Nótese que si el proceso hijo se hubiera planificado antes que el padre cuando
se tratara la llamada al sistema wa i t no hubiera hecho falta dormir al proceso A ya que el proceso B ya
estaría en el estado zombi.
Por otra parte, si el programa se hubiese invocado desde la línea de comandos de la forma
prog2 4 5
entonces el proceso hijo nunca se hubiera creado y la llamada a wa i t hubiera devuelto en s el valor - l .
En consecuencia el mensaje que se habría escrito en l a salida estándar sería:
s = - 1 var = O
•
SOBUNIX : implementación y control de procesos multihilos
2.3.3.
67
Notificación de eventos : señales
Descripción general
Las señales son un mecanismo implementado por el núcleo para la notificación de eventos a proce­
sos. Cada evento notificable tiene asociado una determinada señal. A su vez cada señal tiene asignado un
número entero positivo pequeño que la identifica de manera univoca. Además tiene asociada una cons­
tante simbólica que comienza con S IG y va seguida por una abreviatura o una palabra que resume el
evento al que está asociada. Cada S OBUNIX establece el número de señales que soporta, así como el
número entero y la constante simbólica que le asigna a cada una. En la Tabla 2. 1 se muestra a modo de
ejemplo algunas de las señales definidas en las especificaciones POSIX. Los programas que hacen uso
de señales POSIX tienen garantizada su portabilidad en todos los sistemas operativos que cumplan con
POS IX.
El núcleo envía una señal a un determinado proceso A cuando se produce algún evento que deba ser
notificado. Dicho evento puede estar causado por interrupciones, por la ejecución del propio proceso A
o por la ejecución de otro proceso B .
Efectivamente algunas interrupciones pueden producir que el núcleo envíe una señal a un proceso.
Señal
Acción por defecto
S I GABRT
S I GALRM
S I GCHLD
S I GCONT
S IGFPE
S IGILL
S I G INT
S I GKILL
S IGPI PE
S IGQUIT
S IGSEGV
S I GSTOP
S I GTERM
S I GTSTP
S I GTTIN
S I GTTOU
S IGUP
S I GUSRl
S I GUSR2
S I GXCPU
Abortar
Terminar
Ignorar
Continuar
Abortar
Abortar
Terminar
Terminar (*)
Terminar
Abortar
Abortar
Parar (*)
Terminar
Parar
Parar
Parar
Terminar
Terminar
Terminar
Abortar
Tabla 2.1
-
Evento asociado
Abortar un proceso
Alarma de tiempo real
Terminación o suspensión de un proceso
Continuar si estaba parado
Excepción de aritmética en coma flotante
Instrucción ilegal
Señal de interrupción procedente del teclado ( [ c ontro l ] + [ e ] )
Finalizar un proceso
Escritura en una tubería sin lectores
Señal de terminación procedente del teclado ([contro l ] + [ \ ] )
Referencia a una dirección de memoria ilegal
Parar proceso
Finalizar un proceso
Señal de parar procedente del teclado ( [ c ontro l ] + [ z ] )
Lectura del terminal por un proceso en segundo plano
Escritura en el terminal por un proceso en segundo plano
Desconexión del terminal
Señal definida por el usuario
Señal definida por el usuario
Excedido el tiempo de uso de CPU
Algunas señales definidas en POS IX. (*) La acción por defecto no puede ser modificada.
Ampliación de sistemas operativos
68
Por ejemplo, si se está ejecutando un proceso A en primer plano en un intérprete de comandos y el
usuario pulsa las teclas [cont r o l ] + [c ] se genera una interrupción hardware que al ser atendida por el
núcleo produce, entre otras acciones, el envío de una señal S I GINT al proceso A.
Otra de las principales fuentes de envío de señales es la ejecución de un proceso. Entre los principales
eventos asociados a la ejecución de un proceso que causan que el núcleo tenga que enviarle una señal a
dicho proceso se encuentran los siguientes :
•
Excepciones. Si durante la ejecución del proceso se produce por ejemplo una referencia a una
dirección de memoria no válida o se intenta ejecutar una instrucción ilegal, se producirá una ex­
cepción que al ser tratada por el núcleo producirá entre otras acciones el envío al proceso de una
señal. Las señales S IGFPE, S IGILL y S IGSEGV de la Tabla 2. 1 son ejemplos de señales asociadas
a excepciones.
•
Alarmas. Un proceso puede solicitar al núcleo, mediante la invocación de la llamada al sistema
adecuada, que le envíe una señal cuando haya transcurrido una cierta cantidad de tiempo. A este
mecanismo de aviso se le denomina alarma. Por ejemplo, usando la llamada al sistema a l arm
un proceso puede configurar una alarma de tiempo real, es decir, que el núcleo le envíe una señal
S I GALRM cuando hayan transcurrido un número determinado de segundos de tiempo real.
•
Cuotas. Si un proceso supera la cuota de uso de un recurso el núcleo se lo puede notificar mediante
el envío de una señal. Por ejemplo, si un proceso excede su tiempo de uso del procesador, el núcleo
le envía una señal S I GXC PU.
También, un proceso puede solicitar al núcleo, invocando la llamada al sistema oportuna, que envíe
una señal a un determinado proceso o incluso que se la envíe a si mismo. Por ejemplo, las llamadas al
sistema s i g s end y k i l l permiten enviar una determinada señal a un proceso o grupo de procesos (ver
sección 2 . 3 .5) determinado.
Una señal se considera que ha sido recibida o entregada, cuando se ejecuta la acción que se había
establecido ante la recepción de dicha señal. Existen seis posibles acciones :
•
Ignorar. La recepción de la señal no produce la realización de ninguna acción.
•
Terminar. Se finaliza la ejecución del proceso.
•
Abortar. Se crea en el directorio de trabajo actual un archivo donde se almacena información
(espacio de direcciones, contexto hardware, etc) sobre el proceso y a continuación se procede a la
terminación del proceso. El archivo creado, denominado c o r e en algunos SOBUNIX, puede ser
consultado por otros procesos, como por ejemplo, depuradores.
•
Parar. Se suspende la ejecución del proceso y éste pasa al estado parado. Esta acción es la que
se realiza por defecto cuando se recibe una señal S IGSTOP enviada al proceso por un depurador
o ante la recepción de la señal S IGTSTP generada por la pulsación de un usuario de las teclas
[contro l ] + [ z ] .
SOBUNIX: implementación y control de procesos multihilos
69
•
Continuar. Se pasa el proceso al estado preparado para ejecución para que pueda continuar con su
ej ecución cuando sea planificado. Se aplica únicamente si el proceso estaba en el estado parado.
Esta acción es la que se realiza por defecto cuando se recibe una señal S I GCONT .
•
Capturar. Se ejecuta una determinada función definida por el usuario. A dicha función se le deno­
mina manejador de la señal (signal handler) .
Cada señal tiene asociada por defecto una acción a realizar. Por ejemplo, la acción por defecto que
debe realizar el núcleo cuando un proceso reciba una señal S I GUSRl es terminar la ejecución del proceso
(ver Tabla 2. 1 ) . La información sobre la acción asociada a cada señal se almacena en una determinada
estructura de datos dentro del área-u del proceso. En esta estructura también se almacena las direcciones
de los manejadores de las señales que hayan sido especificados.
Un proceso puede configurar diferentes aspectos relativos a la recepción de las señales :
e
•
Especificar la acción asociada a la recepción de una señal. Un proceso puede especificar la acción
que se desea que se realice cuando reciba una determina señal, para ello debe invocar a la llamada
al sistema adecuada. Por ejemplo, se pueden usar las llamadas al sistema s i gna l , s i gac t i on o
s i gvec .
•
Bloquear la recepción de una señal. Un proceso también puede bloquear o enmascarar l a recep­
ción de una señal con objeto de proteger una sección crítica de su código. Para ello debe invocar una
llamada al sistema, como por ejemplo: s i g s e tma sk, s i gma sk y s i gbl o ck. El núcleo mantiene
al menos una mascara de señales bloqueadas por proceso que es un mapa de bits que permite con­
figurar el bloqueo o no de cada tipo de señal. Existen algunas señales especiales, como S IGSTOP
o S I GKILL, cuya recepción no puede ser bloqueada y cuya acción asignada por defecto tampoco
puede ser cambiada.
•
Esperar por la recepción de una señal. Un proceso puede quedarse suspendido a la espera de la
recepción de una señal que no tenga bloqueada o no ignore. Para ello debe invocar una llamada al
sistema, como por ej emplo, pau s e , s i gpau s e o s i g suspend.
Ejemplo 2.8
Supóngase que el programa prog2 5 (ver Figura 2.7) es invocado desde la línea de órdenes de un intér­
prete de comandos y que a la ejecución de este programa se le asocia un proceso A.
En primer lugar el proceso A invoca una llamada al sistema s i gna l . Esta llamada establece la acción
a realizar ante la recepción de una determinada señal. De forma general esta llamada tiene la siguiente
sintaxis :
s = s i gnal ( nombre_s eña l , a c c i ón_r e c epc i ón ) ;
nombre_s eña l es el número entero o la constante simbólica de la señal sobre la cual se desea especi­
ficar la acción a realizar. Por su parte a c c i ón_r e c epc i ón es un número entero o constante simbólica
70
Ampliación de sistemas operativos
# i n c l ude < s i gnal . h>
vo i d fun { i n t s i g ) ;
ma i n { )
{
int r l = O ,
r2 = 0 ;
s i gn a l { S I GUSR2 , fun ) ;
i f { f o rk { ) = = O )
/ * Pr o c e s o h i j o * /
{
s l e ep { 3 ) ;
p r i n t f { " \ n Env i o s eñ a l a mi padre " ) ;
k i l l { ge tpp i d { ) , S I GUSR2 ) ;
e l s e / * Pr o c e s o padr e * /
{
r l = s l e ep ( 7 ) ;
r 2 = s l e ep ( l ) ;
p r i n t f { " \ n r l= %d r 2 = %d \ n " , r l , r 2 ) ;
vo i d fun { i n t s i g )
s l e ep { l ) ;
p r i n t f { " \ n Rec ibo s eñ a l de mi h i j o " ) ;
Figura 2. 7
-
Código C del programa prog2 5
asociada a la acción a realizar al recibir la señal. Puede tomar dos posibles valores : S I G_DFL o o que es­
pecifica que la acción a realizar es la establecida por defecto y S I G_IGN o 1 que especifica que la acción
a realizar es ignorar la señal. También ac c i ón_r e c epc i ón puede ser la dirección de un manej ador de
señal, con lo que se estaría especificando que la acción a realizar es capturar la señal.
Si la llamada se ejecuta con éxito, entonces en s se devuelve la acción que se tenía asignada a la recepción
de la señal antes de ejecutar esta llamada. En caso de error en s se devuelve la constante S I G_ERR
asociada al valor - l .
En el caso de l a llamada s i gnal ( S IGUSR2 , fun ) que realiza el proceso A s e está estableciendo que
ante la recepción de una señal S IGUSR2 se ejecute el manej ador de la señal fun definido por el usuario.
En segundo lugar, el proceso A invoca a la llamada al sistema f ork para crear un proceso hijo. Supóngase
que el planificador planifica al proceso padre antes que al proceso hijo. Entonces el proceso A invoca
a la función s l eep de la librería l ibe que permite suspender la ejecución de un proceso durante un
determinado intervalo de tiempo especificado en segundos. En este caso la ej ecución del proceso A se
suspende durante 7 segundos.
Cuando se planifica el proceso hijo, éste en primer lugar invoca a la función s l eep para suspender su
SOBUNIX: implementación y control de procesos multihilos
71
ejecución durante 3 segundos. A continuación invoca a la función de librería print f para imprimir por
la salida estándar el texto:
Env i o s eña l a mi padre
Acto seguido invoca a la llamada al sistema k i 11 que permite enviar una señal a un determinado proceso
o conjunto de procesos. De forma general esta llamada tiene la siguiente sintaxis :
s =ki l l ( i d , nombre_s eña l ) ;
nombre_señal es el número entero o la constante simbólica de la señal que se va enviar. i d es un
número entero que identifica al proceso o grupo de procesos al que va dirigida la señal. Si i d es mayor
que O, la señal es enviada al proceso cuyo PID=id. Si i d es igual a O la señal es enviada a todos lo
procesos que pertenezcan al mismo grupo que el proceso que invoca la llamada. Si id es igual a - 1 ,
entonces la señal es enviada a todos los procesos cuyo UID sea igual al EUID del proceso que invoca la
llamada. En el caso de que el EUID sea el del superusuario entonces la llamada es enviada a todos los
procesos, excepto a los procesos con PID=O y con PID= l . Por último si id es menor de - 1 , entonces la
señal es enviada a todos los procesos cuyo identificador de grupo (ver sección 2.3.5) es igual a l i dl . Si la
llamada se ejecuta con éxito entonces en s se almacena un O. En caso de error se almacena el valor - 1 .
De acuerdo, con la explicación anterior el significado de la llamada ki 1 1 ( getpp i d ( ) , S I GUSR2 ) que
invoca el proceso hijo sería el de enviar la señal S I GUSR2 al proceso padre. Recuérdese que la llamada al
sistema getpp i d devuelve el PID del proceso padre del proceso que la invoca. Al retornar de la llamada
ki 1 1 el proceso hijo finaliza su ejecución.
Por su parte el envío de la señal S I GUSR2 hace que el núcleo despierte al proceso A antes de completar
sus 7 segundos de suspensión. Al ser planificado de nuevo el proceso A, se ejecuta el manej ador fun
definido para la señal S IGUSR2 . Este manejador realiza dos acciones. En primer lugar invoca a la función
de librería s l e ep para suspender la ejecución del proceso durante 1 segundo. A continuación invoca a
la función de librería p r i n t f que imprime por la salida estándar el texto
Rec ibo s eñal de mi h i j o
Finaliza la ejecución del manejador, se continúa con la ejecución de la instrucción del proceso A que
fue interrumpida por la recepción de la señal. Como s l e ep no se completó con éxito al ser interrumpida
por la señal, entonces devuelve en rl el tiempo de suspensión que le quedaba al proceso, en este caso
4 segundos. A continuación se invoca a otra función de librería s l e ep para suspender la ejecución del
proceso A durante 1 segundo. Como la función se ejecuta con éxito entonces en r2 se almacena el valor
O. Finalmente se invoca a la función de librería print f que imprime por la salida estándar el texto
r 1 = 4 r2 = 0
y finaliza la ejecución del proceso A .
•
72
Ampliación de sistemas operativos
# i n c l ude < s i gnal . h>
vo i d handl e r ( i n t s i g ) ;
ma i n ( )
{
s i gnal ( S I GUSRl , S IG_I GN ) ;
s i gnal ( S I GUSR2 , hand l e r ) ;
pau s e ( ) ;
p r i n t f { " \ n Mens a j e \ n " ) ;
vo i d handl e r ( i n t s i g )
p r i n t f ( " \ n Señal
%s capturada \ n " , s t r s i gn a l ( s i g ) ) ;
Figura 2.8 - Código C del programa prog2 6
e
Ejemplo 2.9
Supóngase que el programa prog2 6 (ver Figura 2.8 ) es invocado de la siguiente forma desde la línea de
órdenes de un intérprete de comandos:
prog2 6 &
El carácter '&' al final de la orden especifica al intérprete que el programa prog2 6 debe ser ejecutado en
segundo plano, con lo que el intérprete puede seguir recibiendo órdenes del usuario. Supóngase que para
ejecutar este programa el intérprete crea un proceso A con PID igual a 980.
En primer lugar el proceso A invoca una llamada al sistema s i gnal para especificar que la acción que se
realice cuando se reciba una señal S IGUSRl sea la de ignorar ( S I G_IGN) la señal. A continuación vuelve
a invocar una llamada al sistema s i gnal para especificar que la acción que se debe realizar cuando se
reciba una señal S IGUSR2 sea la de capturar la señal usando el manejador hand l e r .
A continuación invoca una llamada al sistema pau s e , la cual pasa al proceso al estado dormido a la
espera de recibir una señal que no ignore y que no tenga bloqueada.
Supóngase que se escribe la siguiente orden en la línea de comandos del intérprete:
k i l l - S IGUSRl 9 8 0
El comando k i l l permite enviar una señal a un proceso. En este caso se enviaría la señal S I GUSRl al
proceso con PID=980, es decir, al proceso A. Puesto que el proceso A ha especificado que esta señal
sea ignorada, el proceso A permanece a la espera de recibir una señal que no ignore o que no tenga
bloqueada. Se puede comprobar que el proceso A sigue ejecutándose haciendo uso del comando j obs o
del comando p s (ver sección 2.3 .6) .
Supóngase, ahora, que se escribe la siguiente orden:
SOBUNIX : implementación y control de procesos multihilos
73
ki l l - S IGKILL 9 8 0
En este caso se envía la señal S I GKILL al proceso A, cuya acción asignada a su recepción es la termina­
ción del proceso. Luego el proceso A termina.
Finalmente, supóngase que en vez de la orden anterior se hubiera escrito la siguiente orden:
ki l l - S IGUSR2 9 8 0
En este caso se envía la señal S IGUSR2 al proceso A, cuya acción asignada a su recepción es capturar
la señal ejecutando el manej ador handl er. Cuando se ejecuta este manejador se imprime en la salida
estándar el mensaje:
Señal User de f ined s i gnal 1 c apturada
Nótese que la función s t r s i gnal a la que se invoca en la función print f muestra un mensaje que
describe el tipo de señal, en este caso User de f ined s i gnal 1 para S I GUSRl . A continuación se
imprime en la salida estándar el texto Mens a j e y finaliza la ejecución del proceso A.
•
Una señal que ha sido enviada pero todavía no ha sido recibida se dice que está pendiente. El núcleo
mantiene una máscara de bits para especificar las señales pendientes de un proceso. También mantiene
una máscara de bits para especificar las señales ignoradas por el proceso.
El núcleo comprueba la existencia de señales pendientes de un proceso mediante la invocación de
una rutina del núcleo que en algunos SOBUNIX recibe el nombre de i s s i g ( ) . Esta función se invoca en
varios puntos del flujo de ejecución de un proceso: al retornar del tratamiento de una llamada al sistema,
al retornar del tratamiento de una interrupción hardware, una trampa o una excepción; y al despertar
(desbloquear) a un proceso.
La función i s s i g ( ) inspecciona la máscara de señales pendientes asociada al proceso. Además
consulta la máscara de señales bloqueadas y la máscara de señales ignoradas. Si encuentra una señal
que está pendiente que no sea ignorada y que no esté bloqueada entonces i s s i g ( ) finaliza su ejecución
devolviendo el valor TRUE . En dicho caso el núcleo invoca a otra rutina del núcleo, denominada p s i g ( )
en algunos SOBUNIX, para que ejecute la acción asociada a la recepción de la señal.
En el caso de que la acción asociada a la señal sea capturar la señal entonces p s i g ( ) invoca a
otra rutina del núcleo, denominada s ends i g ( ) en algunos SOBUNIX. Esta función manipula la pila
de usuario para que se pueda ejecutar el manejador de la señal cuando el proceso se ejecute en modo
usuario.
Una vez finalizada la ejecución del manej ador se continuará con la ejecución del código del proceso
justo desde la instrucción donde fue interrumpido por la señal. Si la señal produjo la interrupción de una
llamada al sistema entonces la llamada devuelve el valor - 1 y almacena en la variable errno el error
E INTR.
Nótese que la recepción de una señal por parte de un proceso requiere que dicho proceso sea planifi­
cado para ejecución. Luego desde que se produce un evento que debe ser notificado al proceso hasta que
74
Ampliación de sistemas operativos
el proceso recibe la señal puede transcurrir una cantidad importante de tiempo dependiendo del estado y
de la prioridad del proceso.
Consideraciones sobre la implementación de las señales en procesos multihilo
En la descripción general de las señales realizada en la sección anterior se ha supuesto por simplificar
que se tenía un proceso monohilo. En el caso de proceso multihilos una señal puede ser enviada a un
determinado hilo o a todos los hilos de un proceso. El escoger una opción u otra depende del evento al
que está asociada la señal.
Generalmente, si el evento al que está asociada una señal ha sido causado por un determinado hilo de
un proceso, lo más lógico es enviar la señal a dicho hilo y no a todos los hilos del proceso. Por ejemplo,
si durante la ejecución de un determinado hilo de un proceso A se ha producido una excepción, lo más
lógico es enviar la señal que notifica la excepción solamente a dicho hilo y no a todos los hilos del
proceso, sobre todo si la acción asociada a la recepción de la señal es la de terminar o abortar.
Por el contrario, si el evento está asociado a una interrupción externa no se puede asociar a un hilo
en particular y por ello lo lógico es enviar la señal a todos los hilos del proceso. Por ejemplo, si en
un intérprete de comandos se está ejecutando un proceso multihilo en primer plano y el usuario pulsa
las teclas [contro l ] + [c] para terminar la ejecución del proceso entonces se genera una interrupción
hardware que al ser tratada por el núcleo produce, entre otras acciones, el envío de la señal S I G INT cuya
acción asociada por defecto es la de terminar. Obviamente para terminar con la ejecución del proceso la
señal deberá ser enviada a todos los hilos del proceso no solamente a uno.
Otro aspecto importante a considerar en el caso de procesos multihilos está asociado con las estruc­
turas de datos que se deben mantener para implementar el mecanismo de señales. De acuerdo con la
descripción general de las señales se requiere por cada proceso al menos una estructura de datos para
mantener las acciones establecidas por cada señal y los manej adores de señales, una máscara de señales
pendientes, una máscara de señales ignoradas y una máscara de señales bloqueadas. En el caso de pro­
cesos multihilos surge la posibilidad de que cada hilo tenga sus propias estructuras de datos asociadas a
las señales o que todos los hilos compartan las mismas estructuras. La primera opción con respecto a la
segunda es más versátil aunque su gestión produce una mayor sobrecarga.
En general, se suele optar por una solución híbrida. Por una parte, la estructura de datos que mantiene
las acciones establecidas por cada señal y los manej adores de señales, así como la máscara de señales
pendientes y la máscara de señales ignoradas se implementan a nivel de proceso y son compartidas por
todos sus hilos. Mientras que la máscara de señales bloqueadas se implementa a nivel de hilo, es decir,
cada hilo dispone de su propia estructura.
e
Ejemplo 2. 10
En el Ejemplo 2.2 se describieron las principales estructuras de datos que implementan el modelo de pro­
ceso multihilo en Solaris. Cada proceso tiene asociada una estructura proc que implementa una entrada
de la tabla de procesos. Además tiene asociada una estructura denominada uarea que se implementa
dentro de la estructura pro c .
Cada hilo d e usuario existente e n u n proceso tiene asociado u n proceso ligero y u n hilo del núcleo. E l hilo
SOBUNIX: implementación y control de procesos multihilos
75
de usuario tiene asignada una estructura u lwp en el espacio de direcciones del proceso. Por su parte, el
proceso ligero tiene asignada una estructura klwp en el espacio de direcciones del núcleo. Allí también
se mantiene una estructura k thread por cada hilo del núcleo.
A continuación se enumeran algunos de los campos asociados al mecanismo de señales que contienen
estas estructuras :
•
Estructura proc.
- p_s ig. Máscara de señales pendientes. Se implementa como un mapa de 64 bits. Cada bit
está asociado a una señal. Si el bit se activa significa que la señal asociada está pendiente
para algún hilo del proceso. Nótese que en Solaris existen definidas 48 señales, luego en este
mapa existen 1 6 bits no asignados a ninguna señal.
- p_i gnor e . Máscara de señales ignoradas. Es un mapa de 64 bits que contiene un bit asociado
a cada señal. Si un bit se activa significa que la señal asociada es ignorada.
•
Estructura uarea.
- u_s ignal [ MAXS I G l . Establece las acciones a realizar al recibir cada señal. Cada entrada
puede contener alguno de los siguientes valores : S I G_IGN (si la señal es ignorada), S I G_DEF
(si se realiza la acción asignada por defecto) o la dirección del manejador definido para la
señal .
•
Estructura u lwp .
- u l_s i grna s k. Máscara de señales pendientes para el hilo.
•
Estructura klwp .
- lwp_cur s i g. Señal tratada actualmente.
•
Estructura kthread.
- p_s ig. Máscara de señales pendientes. Su contenido es idéntico al del campo homónimo de
la estructura pro c .
- p_ho l d. Máscara d e señales bloqueadas. E s u n mapa de 64 bits que contiene u n bit asociado
a cada señal. Si un bit se activa significa que la señal asociada está bloqueada.
Analizando la información enumerada se concluye que en el modelo de proceso multihilo de Solaris,
las acciones a realizar ante la recepción de una determina señal {u_s i gnal [ MAXS I G ] ) y la mascara de
señales ignoradas (p_i gno re) se mantienen a nivel de proceso, con lo que es compartida por todos los
hilos.
76
Ampliación de sistemas operativos
Por otra parte, la máscara de señales bloqueadas (p_h o l d) se mantiene a nivel de hilo, en concreto en
el hilo del núcleo. De esta forma cada hilo tiene la posibilidad de especificar las señales cuya recepción
desea bloquear.
La información sobre las señales pendientes se mantiene tanto a nivel de hilo como a nivel de proceso.
En la estructura ulwp se mantienen las señales pendientes para un determinado hilo. Mientras que en las
estructuras proc y kthread se duplica la misma información: la existencia de señales pendientes para
algún hilo del proceso. Esta duplicidad es necesaria para poder tratar de forma más eficiente todas las
situaciones en que se pueden generar señales.
•
2.3.4.
Control de hilos de usuario: librerías de hilos
En las secciones anteriores se han descrito los mecanismos de control de procesos en los SOBUNIX.
Dichos mecanismos han sido explicados en su mayor parte considerando procesos monohilos, aunque se
han realizado diferentes consideraciones asociadas al caso de los procesos multihilos. Queda sin embargo
comentar los mecanismos de control disponibles a nivel de los hilos de usuario. A este nivel los meca­
nismos de control son proporcionados por una librería de hilos, como por ejemplo la librería Pthreads
de POSIX escrita en lenguaje C .
L a librería Pthreads contiene diferentes funciones para la gestión de los hilos d e usuario: control,
sincronización, comunicación, planificación, etc. Cada hilo de usuario tiene asociado un número entero
positivo que lo identifica de forma univoca. Además tiene asociado una serie de atributos : inicialización,
tamaño y dirección de pila, herencia, parámetros y política de planificación, etc. El identificador numéri­
co del hilo de usuario se almacena en una estructura de datos p thread_t . Mientras que los atributos se
almacenan en una estructura de datos pthread_a t tr _t . Las estructuras anteriores y los prototipos de
las funciones incluidas en esta librería se encuentran disponibles en el archivo de cabecera p thread . h.
La librería Pthreads contiene, entre otras, las siguientes funciones para el control de los hilos de
usuario:
•
p thread_c r e a t . Crea un hilo de usuario para ejecutar una función determinada.
•
pthread_s e l f . Obtiene el identificador numérico asociado al hilo de usuario que ha invocado a
esta función.
•
pthread_exi t. Termina la ejecución del hilo de usuario que la ha invocado.
•
pthread_j o in. Suspende la ejecución del hilo de usuario que ha invocado a esta función hasta
que termine la ejecución de un determinado hilo de usuario.
•
pthread_k i l l . Permite enviar una determina señal a un determinado hilo de usuario.
Estas funciones suelen devolver un O si se ejecutan con éxito y un valor distinto de O en caso contrario.
SOBUNIX: implementación y control de procesos multihilos
77
# i nc lude < s t d i o . h>
# i nc lude <p thread . h>
vo i d * funl ( vo i d * i d ) ;
vo i d * fun2 ( vo i d * i d ) ;
rna i n ( )
/ * C ó d i g o de l h i l o 1
( h i l o principal } * /
{
p thread_t hu l , hu2 ;
p thre ad_c r e a t e ( &hu l ,
NULL ,
* funl ,
NULL ) ;
pthread_c rea t e ( &hu 2 ,
NULL ,
* fun2 ,
NULL ) ;
p thre ad_j o i n ( hu l ,
NULL ) ;
pthread_j o i n ( hu 2 ,
NULL ) ;
vo i d * funl ( vo i d * i d )
/ * C ó d i go d e l h i l o 2 * /
for ( ; ; ) ;
vo i d * fun2 ( vo i d * i d )
/ * C ó d i g o d e l hi l o 3 * /
int i = O ;
for ( i = O ; i < 4 ; i + + )
p r i n t f { " \ nMen s a j e 2 " ) ;
pthread_ex i t ( NULL ) ;
Figura 2.9 - Código C del programa prog2 7
e
Ejemplo 2. 1 1
Supóngase que e l programa prog2 7 (ver Figura 2.9) e s compilado con e l compilador g c c invocándolo
de la siguiente forma desde un intérprete de comandos:
g c c - o prog2 7 prog2 7 . c - lp thread
Si la orden se ejecuta con éxito se genera el archivo ejecutable prog2 7. La ejecución de este archivo
produce la creación de un proceso con tres hilos de usuario. El primer hilo de usuario se crea implíci­
tamente para ejecutar la función ma in. É ste se puede considerar como el hilo principal del proceso. La
terminación del hilo principal produce de forma implícita la terminación del proceso y en consecuencia
del resto de hilos del proceso. Afortunadamente es posible habilitar mecanismos de sincronización para
conseguir que el hilo principal termine solo cuando hayan terminado el resto de los hilos creados.
El segundo hilo se crea mediante la invocación por parte del hilo principal de la función
78
Ampliación de sistemas operativos
pthread_c rea t e ( &hu l , NULL ,
* funl , NULL ) ;
Se observa que esta función tiene cuatro argumentos. El primer argumento es la dirección de una estruc­
tura de tipo p thread_t donde se almacenará el identificador del hilo si la función se ejecuta con éxito.
En este caso dicha estructura se denomina hu l . El segundo argumento es la dirección de la estructura de
tipo pthread_at t r_t que contiene los valores de los atributos del hilo. En este caso al pasar un valor
NULL la librería se encarga de asignarle unos valores por defecto a los atributos del hilo. El tercer argu­
mento es un puntero a la función cuyo código ejecutará el hilo. En este caso el hilo ejecutará la función
fun l . Se observa que esta función ejecuta un bucle f o r infinito. El cuarto argumento es un puntero a
los argumentos de la función cuyo código ejecutará el hilo. En este caso al pasar un valor NULL se está
especificando que la función no requiere argumentos.
El tercer hilo se crea también mediante la invocación de p thread_create por parte del hilo principal.
El hilo creado ejecutará el código de la función fun2 que imprime cuatro veces Mens a j e 2 en la salida
estándar e invoca a la función p thread_exi t para terminar la ejecución del hilo. Nótese que dicha
función tiene como argumento un valor NULL. Eso significa que no hay que almacenar ningún valor
para que sea consultado por otro hilo que esté esperando por la terminación de este hilo en una función
pthread_j o in.
Posteriormente, el hilo principal invoca a la función
p thread_j o i n ( hu l , NULL )
para suspender su ejecución hasta que termine el primer hilo creado. Esta función tiene dos argumentos
de entrada. El primer argumento es el identificador del hilo por el que se desea esperar. En este caso se
trata del hilo cuyo identificador se encuentra almacenado en la estructura hu l . El segundo argumento es
un puntero al valor devuelto por el hilo por el que se está esperando. En este caso se pasa un valor NULL
luego se indica a la librería que no se desea conocer dicho valor.
Finalmente el hilo principal invoca otra vez a la función p thread_j o in pero esta vez para esperar por
la terminación del segundo hilo creado, cuyo identificador se encuentra almacenado en la estructura hu2 .
Supóngase un SOBUNIX con un hilo del núcleo por cada hilo de usuario, por ejemplo Solaris. S i el
archivo prog2 7 fuera lanzado en segundo plano
prog2 7 &
y a continuación se ejecutará el comando
ps - L
e n la salida estándar s e mostraría l a salida que s e incluye en l a Figura 2. 1 0. Se observa que la ejecución
de prog2 7 tiene asociado un proceso con PID= 1 3 1 3 cuya ejecución se descompone en tres procesos
ligeros (LWP) con identificadores 1 , 2 y 3. El proceso ligero 1 está asociado al hilo principal que ejecuta
el código de ma in. El proceso ligero 2 está asociado al primer hilo creado que ejecuta el código de fun l .
SOBUNIX: implementación y control de procesos multihilos
79
Por último el proceso ligero 3 está asociado al segundo hilo creado que ha ejecutado el código de fun2 y
que ya ha terminado (de func t). Recuérdese que en Solaris cada proceso ligero está asociado a un hilo
de usuario y a un hilo del núcleo.
PID
LWP TTY
LT IME CMD
9 64
1 pts / 3
0 : 0 0 bash
1313
1 pts / 3
0 : 0 0 prog2 7
1313
2 pts / 3
0 : 0 5 prog2 7
1313
3 pts / 3
0 : 0 0 <de func t>
1316
1 pts / 3
0 : 0 0 ps
Figura 2.10 - Salida del comando p s
-
L
en el Ej emplo 2. 1 1
•
2.3.5.
Grupos de procesos y sesiones
Terminales
Un terminal serie es un dispositivo de E/S orientado a carácter que consta de un teclado y de una
pantalla y que se comunica con el computador mediante una línea serie. En un terminal se trabaja con
una interfaz de línea de comandos implementada con un intérprete de comandos.
Los terminales serie se utilizaban en macrocomputadores y minicomputadores. Actualmente el ter­
minal serie como dispositivo hardware ha sido sustituido por computadores personales que disponen de
software para emular dichos terminales. Por ejemplo xt erm es una aplicación que trabaj a sobre X Win­
dow que emula un terminal en una ventana. Estos terminales emulados o pseudoterminales son bastante
utilizados por programadores y administradores del sistema.
Las operaciones de E/S con un terminal ya sea real o emulado se implementan como operaciones de
E/S sobre un archivo / dev / t ty [ i d ] donde [ i d ] es algún grupo de caracteres que permite distinguir
los diferentes terminales que pueden existir. El valor de [ i d ] depende de cada SOBUNIX.
Grupos de procesos
En los SOBUNIX los procesos son organizados en grupos de procesos. Cada grupo tiene asocia­
do un número entero positivo que lo identifica de manera univoca. A dicho identificador se le conoce
generalmente con el nombre de identificador del grupo de procesos (Process Group IDentifier, PGID).
Para conocer el PGID de un proceso se pueden usar las llamadas al sistema ge tpg i d y ge tpgrp o el
comando p s -j (ver sección 2 . 3 . 6).
Dentro de cada grupo de procesos puede existir un proceso el cual tiene asignado un PID que coincide
con el PGID del grupo, a dicho proceso se le denomina líder del grupo. Normalmente el resto de procesos
que pertenecen al grupo suelen ser los hijos del líder del grupo. Cuando se crea un proceso éste hereda el
PGID de su proceso padre. Luego todos los procesos con relación genealógica pertenecen por defecto al
80
Ampliación de sistemas operativos
mismo grupo de procesos. Para crear un nuevo grupo de procesos o para cambiar a un proceso de grupo
se pueden usar las llamadas al sistema s e tpgid y s e tpgrp.
De forma general un grupo de procesos puede ser creado por el núcleo o por una aplicación de usuario
para la realización de un determinado trabaj o o función. La existencia de grupos de procesos facilita el
envío de señales a todos los miembros del grupo, lo cual resulta de gran utilidad en ciertas aplicaciones.
e
Ejemplo 2. 12
La ejecución de un comando desde la línea de órdenes de un intérprete de comandos de un terminal puede
producir la creación de uno o varios procesos, todos ellos pertenecientes al mismo grupo. Recuérdese
que en el contexto de un intérprete de comandos a dicho grupo de procesos se le denomina trabajo o
tarea.
Si un proceso de un trabaj o en segundo plano intenta leer una entrada del terminal el núcleo envía una
señal S IGTT IN al grupo al que pertenece el proceso. Mientras que si intenta escribir en el terminal el
núcleo envía al grupo una señal S I GTTOU. La acción por defecto asociada a la recepción de estas señales
(ver Tabla 2. 1 ) es parar los procesos. Conviene señalar que algunos intérpretes de comandos hacen caso
omiso de la acción por defecto asociada a la señal S I GTTOU y permiten que un proceso de un trabaj o en
segundo plano pueda escribir en el terminal.
Por otra parte, si un usuario pulsa las teclas [ c ontro l ] + [ z l de un terminal se produce una interrupción
hardware que al ser atendida por el núcleo hace que éste, entre otras acciones, envíe al grupo de procesos
que forman el trabajo en primer plano una señal S IGTSTP cuya acción por defecto es parar los procesos .
•
Sesiones
Los SOBUNIX modernos soportan la abstracción de sesión. Una sesión está formada por uno o va­
rios grupos de procesos asociados a un determinado terminal de control. Cada sesión tiene asociado un
número entero positivo que la identifica de manera univoca. A dicho identificador se le conoce general­
mente con el nombre de identificador de sesión (Session IDentifier, SID). El SID de una sesión coincide
con el PGID del proceso o grupo de procesos que ha iniciado la conexión al terminal. A dicho proceso o
grupo de procesos se le denomina líder de la sesión.
Por ejemplo, cuando un usuario accede a un SOBUNIX a través de un programa de login se crea una
sesión cuyo líder es el programa de login. También cuando un usuario abre un terminal emulado se crea
una sesión cuyo líder es el intérprete de comandos del terminal.
Luego un determinado proceso pertenece a un grupo de procesos y a una determinada sesión, es
decir, tiene asociado un PGID y un SID. Cuando se crea un proceso éste hereda el PGID y el SID de
su proceso padre. Un proceso puede crear una nueva sesión usando la llamada al sistema s e t s i d. Para
conocer el SID asociado a un proceso se puede usar la llamada al sistema ge t s i d. También se puede
usar el comando ps - j (ver sección 2 . 3 . 6).
Conviene saber que cuando se trabaja con la abstracción de sesión, un proceso solo puede cambiar
de grupo si el grupo origen y el grupo destino pertenecen a la misma sesión.
SOBUNIX: implementación y control de procesos multihilos
81
Por otra parte, el uso de sesiones facilita el envío de señales a todos los grupos de procesos pertene­
cientes a una misma sesión.
2.3.6.
El sistema de archivos procfs
El sistema de archivos de procesos (process file system, procfs) es un pseudosistema de archivos
existente en algunos SOBUNIX que permite acceder a la información que mantiene el núcleo sobre los
procesos. Dicha información se almacena en archivos y se organiza en directorios. El término pseu­
dosistema se aplica sobre procfs en el sentido de que no se implementa en una partición de disco en
memoria secundaria, como un sistema de archivos ordinario, sino en el espacio de direcciones del núcleo
en memoria principal.
La implementación y la estructura del sistema procfs depende de cada SOBUNIX. Usualmente este
sistema se suele montar en el directorio /pro c . Dentro de este directorio existen, entre otros directorios,
un directorio por cada proceso existente en el sistema. Cada directorio asociado a un proceso lleva por
nombre el PID del proceso al que está asociado y contiene diferentes archivos y directorios con infor­
mación sobre el proceso. Para conocer la información contenida en los archivos y directorios del sistema
procfs soportado por un determinado SOBUNIX se recomienda consultar la página correspondiente del
manual de ayuda:
man proc
e
Ejemplo 2. 13
En la implementación que realiza Solaris del sistema procfs dentro del directorio asociado a un proceso
se aloj an, entre otros los siguientes archivos:
•
/ proc / P I D / map . Información sobre el espacio de direcciones virtuales de un proceso. Esta in­
formación puede ser consultada usando el comando pmap .
•
/proc / P I D / c red. Contiene los credenciales del proceso.
•
/proc / P I D / p s i n f o . Contiene la información asociada a un proceso que se muestra con el co­
mando p s .
•
/proc 1 P I D / lps i n f o . Contiene l a información asociada a los procesos ligeros d e u n proceso que
se muestra con el comando p s .
•
/proc / P I D / s t a tu s . Contiene diferente información sobre e l proceso: e l estado, PID, PGID,
SID, etc.
•
/proc / P I D / u sage. Contiene información sobre el uso de los recursos del computador que reali­
za el proceso.
Ampliación de sistemas operativos
82
Asimismo, cada directorio /proc / P I D / contiene, entre otros directorios, un directorio lwp dentro del
cual existe un directorio por cada proceso ligero asociado al proceso existente en el sistema. Cada di­
rectorio asociado a un proceso ligero lleva por nombre el identificador numérico del proceso ligero
(LightWeight ?rocess IDentifier, LWPID) al que está asociado y aloja, entre otros, los siguientes archi­
vos :
•
/proc / P I D / lwp / LWP I D / l wp s t a t u s . Contiene, entre otros datos, el estado del proceso ligero.
•
/proc / P I D / lwp / LWP I D / lwp s i n f o . Contiene la información asociada al proceso ligero que se
muestra con el comando p s .
•
e
Ejemplo 2. 14
Supóngase que en un sistema Solaris se está ejecutando un intérprete de comandos bash que tiene
asociado un proceso con PID=730. Si se escribe la orden
l s - F /proc
en la salida estándar, por defecto la pantalla, aparecerá un listado con todos los directorios contenidos
en el directorio /proc, en el cual está montado el sistema procfs. Existe un directorio por cada proceso
existente. Cada directorio lleva por nombre el PID del proceso al que está asociado.
Si ahora se escribe la orden
l s - l /proc / 7 3 0
en la pantalla aparecerá un listado detallado con todos los archivos y directorios contenidos en el direc­
torio /proc / 7 3 0 , que es el directorio asociado al intérprete de comandos. En dicho listado aparecen,
entre otros, los archivos y directorios comentados en los párrafos anteriores: a s , c red, c t l , etc
Si se escribe a continuación la orden
l s - l /pro c / 7 3 0 / lwp
en la pantalla aparecerá un listado detallado con todos los archivos y directorios contenidos en el direc­
torio /proc / 7 3 0 / lwp, que es el directorio que contiene información sobre los procesos ligeros en que
se descompone el intérprete de comandos. Existe un directorio por cada proceso ligero existente. Cada
directorio lleva por nombre el LWPID del proceso ligero al que está asociado. En el caso del intérprete de
comandos solo tiene un único proceso ligero cuyo LWPID = l . Luego existe un único directorio 1 dentro
de /pro c / 7 3 0 / lwp .
Finalmente si se escribe la orden
l s - l /proc / 7 3 0 / lwp / 1
SOBUNIX : implementación y control de procesos multihilos
83
en la pantalla aparecerá un listado detallado con todos los archivos y directorios contenidos en el direc­
torio /proc / 7 3 0 / lwp / 1 , que es el directorio asociado al proceso ligero LWPID= l del intérprete de
comandos. En dicho listado aparecen, entre otros, los archivos y directorios comentados en los párrafos
anteriores: lwp c t l , lwp i n f o y lwp s tatus .
•
Existen diferentes comandos que permiten extraer la información almacenada en procfs, como por
ejemplo:
•
ps. Este comando muestra un listado con información sobre los procesos existentes en el sistema.
La información que se muestra depende de cada SOBUNIX y de las opciones especificadas en el
comando.
•
pr s t a t . Este comando muestra un listado con información sobre el uso de los recursos que están
realizando los procesos existentes en el sistema. La información que se muestra se actualiza cada
cinco segundos. Otros comandos con una funcionalidad similar a prs t a t son top, mp s t a t y
vms t a t .
e
Ejemplo 2. 15
S i se escribe en un intérprete de comandos bash de Solaris la orden
ps
en la pantalla aparecería una salida semej ante a la siguiente:
P I D TTY
1 3 2 0 pts / 3
1 1 5 9 pts / 3
T IME CMD
0 : 0 0 ps
0 : 0 0 bash
Se trata de un listado que muestra información sobre los procesos asociados al intérprete de comandos:
el propio intérprete y el creado para ejecutar el comando ps. La información que se muestra de cada
proceso es la siguiente: PID, el terminal de control asociado TTY, el tiempo T IME de uso del procesador
y el comando CMD cuya ejecución ha generado el proceso.
Se puede configurar la información que se desea que aparezca por pantalla usando las opciones dispo­
nibles del comando. Para conocer las informaciones que se pueden mostrar y cómo mostrarlas se debe
consultar la página asociada al comando en el manual de ayuda. Por ejemplo, si se ahora se escribe la
orden
ps -Al
la opción -A hace que se muestren todos los procesos existentes en el sistema. Mientras que la opción
- 1 hace que se muestre un listado con más información, es decir, un mayor número de columnas. Para
incluir información sobre los procesos ligeros existentes en cada proceso se debe usar la opción - L . Así
la orden anterior se debería escribir de la siguiente forma:
84
Ampliación de sistemas operativos
ps
-
AlL
Para incluir la información sobre el PGID y el SID de cada proceso se debe usar la opción - j .
•
2.4.
Resumen
Los SOBUNIX modernos usan hilos del núcleo como unidad básica de planificación y ejecución.
Además también pueden soportar procesos ligeros, que son hilos de usuario cuya gestión es realizada
por el núcleo del sistema operativo. Un proceso ligero puede estar asociado a uno o varios hilos de
usuario. Algunos SOBUNIX utilizan un modelo de proceso multihilo con un mayor número de hilos
de usuario que procesos ligeros. Otros utilizan un modelo donde cada proceso ligero está asociado a un
único hilo de usuario.
En los SOBUNIX la creación de un proceso se realiza generalmente invocando a la llamada al sistema
f o rk. Al proceso que invoca a f o rk se le denomina proceso padre y al nuevo proceso que se crea se
le denomina proceso hijo. El proceso hijo recién creado es un copia prácticamente idéntica del proceso
padre y comparte el acceso a todos sus recursos. La única diferencia entre el proceso hijo recién creado
y el proceso padre se encuentra en algunos campos de su estructura proc, es decir, de su entrada de la
tabla de procesos.
En los SOBUNIX un proceso puede invocar a otro programa haciendo uso de la llamada al sistema
exe c . Esta llamada al sistema básicamente sustituye las regiones del espacio de direcciones del proceso
invocador por las regiones del programa invocado. Al finalizar la llamada al sistema se comienza a
ejecutar en el proceso invocador el programa invocado.
En los SOBUNIX si un proceso desea terminar su ejecución debe invocar explícitamente a la llamada
al sistema exi t. El sistema operativo también procede de forma implícita a la terminación de un proceso
después de ejecutar la última instrucción del proceso. Asimismo la terminación de un proceso también
se puede producir si el proceso recibe una señal cuyo tratamiento especifique la finalización del proceso.
Las señales son un mecanismo del núcleo para la notificación de eventos a procesos. Cada evento
notificable tiene asociado una determinada señal. A su vez cada señal tiene asignado un número entero
positivo pequeño que la identifica de manera univoca. Además tiene asociada una constante simbólica
que comienza con S I G y va seguida por una abreviatura o una palabra que resume el evento al que está
asociada. Cada SOBUNIX establece el número de señales que soporta, así como el número entero y la
constante simbólica que le asigna a cada una.
En los SOBUNIX los procesos son organizados en grupos de procesos. Asimismo los SOBUNIX
modernos soportan la abstracción de sesión. Una sesión está formada por uno o varios grupos de procesos
que pueden estar asociados a un determinado terminal de control.
El sistema de archivos de procesos (procfs) es un pseudosistema de archivos existente en algunos
SOBUNIX que permite acceder a la información que mantiene el núcleo sobre los procesos. Dicha
información se almacena en archivos y se organiza en directorios.
SOBUNIX: implementación y control de procesos multihilos
2.5.
85
Lecturas recomendadas
Si se desea obtener una explicación adicional de los contenidos tratados en este capítulo se pueden
consultar, por ejemplo: los capítulos 2, 3, 4 y 9 de [Vahalia, 1 995] , el capítulo 10 de [Tanenbaum, 2009] ,
el capítulo 2 de [McDougall y Mauro, 2006], y los capítulos 5, 6 y 7 de [Márquez, 2004] .
2.6.
Autoevaluación
2.1. Definir y comentar las características de los siguientes elementos: a) Hilos del núcleo. b) Hilos de
usuario. e) Procesos ligeros. (Respuesta en sección 2.2. 1 )
2.2. Explicar razonadamente e l modelo de proceso multihilo utilizado en Solaris.
(Respuesta en sección 2.2. 1 )
2.3. ¿Qué e s l a tabla d e procesos? Enumere l a información que contiene una de sus entradas.
(Respuesta en sección 2.2.2)
2.4. Explicar razonadamente qué información es necesario mantener por cada hilo de usuario de un
proceso. ¿Quién gestiona dicha información? ¿Dónde se almacena? (Respuesta en sección 2.2.2)
2.5. Explicar razonadamente qué información es necesario mantener por cada proceso ligero. ¿Quién
gestiona dicha información? ¿Dónde se almacena? (Respuesta en sección 2.2.2)
2.6. Explicar razonadamente qué información es necesario mantener por cada hilo del núcleo. ¿Quién
gestiona dicha información? ¿Dónde se almacena? (Respuesta en sección 2.2.2)
2.7. Explicar razonadamente la relación existente entre procesos, procesos ligeros e hilos del núcleo.
(Respuesta en sección 2.2.2)
2.8. Explicar razonadamente la función de las siguientes estructuras de datos en Solaris: pro c , klwp,
kthread, ulwp y uberda ta. (Respuesta en sección 2 .2.2)
2.9. Dibujar el diagrama de transición de estados de los hilos del núcleo en Solaris.
(Respuesta en sección 2.2.2)
2.10. Explicar para qué se utiliza la llamada al sistema f o rk. ¿Qué valor devuelve al proceso padre si
se ejecuta con éxito? ¿ Y al proceso hijo? (Respuesta en sección 2. 3 . 1 )
2. 11. Explicar l a relación existente entre el espacio de direcciones virtuales de un proceso padre y su
proceso hijo. (Respuesta en sección 2. 3 . 1 )
2. 12. Enumerar las principales acciones que realiza l a función del núcleo que s e encarga de tratar la
llamada al sistema f o rk (Respuesta en sección 2. 3 . 1 )
2.13. Explicar para qué s e utiliza l a llamada al sistema exe c . (Respuesta en sección 2 . 3 . 1 )
86
Ampliación de sistemas operativos
2.14. ¿Qué tres tipos de argumentos de entrada aceptan las funciones de envo'ltura que invocan a la
llamada al sistema exe c ? (Respuesta en sección 2.3 . 1 )
2.15. Enumerar las principales acciones que realiza l a función del núcleo que s e encarga de tratar la
llamada al sistema exec (Respuesta en sección 2.3 . 1 )
2. 16. Explicar l a utilidad d e l a llamada al sistema vfork (Respuesta e n sección 2. 3 . 1 )
2.17. Explicar razonadamente las consideraciones a realizar sobre el diseño de fork en procesos multi­
hilos. (Respuesta en sección 2 . 3 . 1 )
2.18. Explicar para qué s e utiliza l a llamada al sistema exi t . Comentar su sintaxis.
(Respuesta e n sección 2 . 3 . 2)
2.19. Enumerar las principales acciones que realiza la función del núcleo que se encarga de tratar la
llamada al sistema exi t (Respuesta en sección 2.3 .2)
2.20. ¿Cuál es el PID del proceso inicial o proceso ini t ? ¿ Cuándo se crea este proceso? ¿Cuál es su
principal tarea? (Respuesta en sección 2.3.2)
2.21. Explicar para qué se utiliza la llamada al sistema wa i t . Comentar su sintaxis.
(Respuesta en sección 2 . 3 .2)
2.22. ¿Qué información mantiene el núcleo si un proceso se encuentra en el estado zombi?
(Respuesta en sección 2 . 3 .2)
2.23. ¿Qué son las señales? ¿Cómo se identifican? (Respuesta en sección 2.3.3)
2.24. Enumerar las principales fuentes de envío de señales. (Respuesta en sección 2.3.3)
2.25. Indicar los eventos que producen el envío de las siguientes señales y su acción por defecto asociada:
S IGSEGV, S I GALRM, S IGXC PU, S IGINT, S I GKILL, S I GTTIN, S IGTTOU, S I GCHLD, S IGSTOP,
S I GCONT, S I GTERM, S IGSTP, S I GUSRl y S I GUSR2 . (Respuesta en sección 2.3.3)
2.26. ¿Qué llamadas al sistema permiten enviar una señal a un proceso o grupo de procesos?
(Respuesta en sección 2 . 3 . 3 )
2.27. ¿Cuándo se considera que una señal ha sido recibida o entregada? (Respuesta e n sección 2 . 3 . 3 )
2.28. Enumerar y comentar brevemente las posibles acciones que se pueden realizar ante la recepción
de una señal. (Respuesta en sección 2 . 3 . 3 )
2.29. Enumerar qué aspectos puede configurar un proceso ante la recepción de una señal. ¿Qué llamadas
al sistema se pueden utilizar para configurar dichos aspectos? (Respuesta en sección 2 . 3 . 3 )
2.30. ¿Para qué se utiliza la llamada al sistema s i gna l ? Explicar su sintaxis.
(Respuesta en sección 2.3.3)
SOBUNIX: implementación y control de procesos multihilos
87
2.31. ¿Para qué se utiliza la llamada al sistema ki 1 1 ? Explicar su sintaxis. Comentar el uso del comando
homónimo. (Respuesta en sección 2.3.3)
2.32. ¿Para qué se utiliza la llamada al sistema paus e ? (Respuesta en sección 2 . 3 . 3 )
2.33. ¿Cuándo se dice que una señal está pendiente? (Respuesta e n sección 2.3.3)
2.34. Explicar las tareas que realizan las siguientes rutinas del núcleo: i s s i g ( ) , p s i g ( ) y s ends i g ( ) .
(Respuesta en sección 2 . 3 . 3 )
2.35. Explicar razonadamente las consideraciones a realizar sobre la implementación de las señales en
procesos multihilos. (Respuesta en sección 2 . 3 . 3 )
2.36. ¿Qué tareas permiten realizar las funciones de la librería Pthreads? (Respuesta en sección 2.3 .4)
2.37. ¿Qué información mantiene la librería Pthreads por cada hilo de usuario?
(Respuesta en sección 2.3 .4)
2.38. Enumerar e indicar la utilidad de cinco funciones para el control de los hilos de usuario de la
librería Pthreads. (Respuesta en sección 2.3 .4)
2.39. ¿Qué identificador tiene asociado cada grupo de procesos en SOBUNIX? ¿A qué proceso se le
denomina líder del grupo? (Respuesta en sección 2 . 3 . 5 )
2.40. Explicar la utilidad de las siguientes llamadas al sistema: getpg i d y s e tpgrp .
(Respuesta en sección 2 . 3 . 5 )
2.41. ¿Que elementos conforman una sesión? ¿Qué identificador tiene asociado cada sesión? ¿A qué
proceso o grupo de procesos se le denomina líder de la sesión? (Respuesta en sección 2 . 3 . 5 )
2.42. Explicar la utilidad de las siguientes llamadas al sistema: s e t s i d y ge t s i d.
(Respuesta en sección 2 . 3 . 5 )
2.43. ¿Qué comando se puede utilizar para visualizar el identificador de grupo y el identificador de
sesión de un proceso? (Respuesta en sección 2 . 3 . 5 )
2.44. ¿Para qué se utiliza el sistema de archivos procfs? (Respuesta e n sección 2 . 3 . 6)
2.45. Explicar la estructura de un sistema de archivos procfs. (Respuesta en sección 2 . 3 . 6)
2.46. Enumerar dos comandos que permiten extraer la información almacenada en procfs y comentar
qué información extraen. (Respuesta en sección 2.3 .6)
88
Ampliación de sistemas operativos
ma i n ( i n t argc ,
char
* argv [ ] )
{
i n t a , b= O , c , d ;
if
( argc ! = 2 )
exi t ( 3 ) ;
else
a = a t o i ( argv [ l ] ) ;
wh i l e
( f ork ( ) = = O & & b ! = a )
{
p r i n t f ( " \ nMen s a j e l [ %d ] \ n " ,
getpi d ( ) ) ;
b=b+ l ;
c = wa i t ( &d ) ;
p r i n t f ( " \ nMen s a j e 2 [ %d] = %d \ n " ,
Figura 2.1 1
2.7.
-
g e t p i d ( ) , g e tpp i d ( ) ) ;
Código C del programa j O 9 del Ejercicio 2. 1
Ejercicios
2. 1. Supóngase que al invocar el programa j 0 9 (ver Figura 2. 1 1 ) desde un intérprete de comandos se
crea un proceso con PID= 1 1 20. Supóngase además que la asignación de los PIDs de los procesos
hijos, si se llegaran a crear, se realiza mediante la expresión PIDh ij o = PIDpadre + h, donde h =
1 , 2, 3 , . . . hace referencia al orden de creación del proceso hijo, es decir, h = 1 es el primer hijo
creado, h = 2 es el segundo hij o creado, etc. Suponer además que el intérprete de comandos desde
donde se lanza j 0 9 tiene asignado PID= 1 000.
a) Explicar razonadamente el funcionamiento de este programa si se invoca desde el intérprete
de comandos mediante la orden: j o 9 4
b) Comprobar que la respuesta dada en el apartado anterior es correcta compilando y ejecutando
este programa en un SOBUNIX.
2.2. En la Figura 2. 1 2 se muestra el código C de los programas j 0 7 y ex2 . Supóngase que al invocar
este programa desde la línea de ordenes de un intérprete de comandos se crea un proceso con
PID=789 y que la asignación de los PIDs de los procesos hijos, si se llegaran a crear, se realizaría
incrementando en una unidad el PID del proceso padre.
a) Explicar razonadamente el funcionamiento de j 0 7 si se escriben consecutivamente las si­
guientes dos órdenes : 1 ) j 0 7 2) ki l l - S IGUSRl 7 9 0
b) Comprobar que la respuesta dada en el apartado anterior es correcta compilando y ejecutando
estos programas en un SOBUNIX.
SOBUNIX: implementación y control de procesos multihilos
89
/ * C Ó d i g o del programa j 0 7 * /
# i nc lude < s i gn a l . h>
vo i d func
( i nt x ) ;
ma in ( )
{
int u= 1 5 ;
s i gnal ( S I GUS R l , func ) ;
u=u %2 ;
if
( fork ( ) = = 0 )
{
execv ( " ex2 " , O ) ;
u=u + 7 ;
p r i n t f ( " \ n %f \ n " , u ) ;
e l s e exi t ( l ) ;
vo i d func ( i n t x )
p r i n t f ( " Men s a j e 1 " ) ;
/ * Có d i g o de l programa ex2 * /
ma in ( )
{
f l oat u ;
pau s e ( ) ;
p r i n t f ( " \ nu= %f \ n " , u ) ;
Figura 2.12 - Código C de los programas j 0 7
y
ex2 del Ejercicio 2.2
2.3. En la Figura 2. 1 3 se muestra el código C del programa so 8 . Supóngase que al invocar este progra­
ma desde la línea de ordenes de un intérprete de comandos se crea un proceso con PID= 1 035 y que
la asignación de los PIDs de los procesos hijos, si se llegaran a crear, se realizaría incrementando
en una unidad el PID del proceso padre.
a) Explicar razonadamente el funcionamiento de s O 8 si se escriben consecutivamente las si­
guientes tres órdenes :
1) sOS &
2) k i l l - S I GUSRl 1 0 3 6
3) k i l l - S I GUSR2 1 0 3 6
b) Comprobar que la respuesta dada en el apartado anterior es correcta compilando y ejecutando
este programa en un SOBUNIX.
90
Ampliación de sistemas operativos
# i n c l ude < s i gnal . h>
vo i d f 1 ( i n t s i g ) ;
ma i n ( )
{
int a , b ;
s i gnal ( S I GUSR1 , S I G_DFL ) ;
i f ( fork ( ) = = 0 )
{
s i gnal ( S I GUSR1 , S I G_I GN ) ;
pau s e ( ) ;
exi t ( 5 ) ;
else
a =wa i t ( &b ) ;
pr i n t f ( " \ n
%1
%1 \ n " , a , b ) ;
vo i d f 1 ( i n t s i g )
p r i n t f ( " \ nMens a j e 1 \ n " ) ;
Figura 2.13
-
Código C del programa s O 8 del Ejercicio 2.3
# i nc l ude < s i gnal . h>
ma in ( )
{
int a , b ;
if
( ( a = f o rk ( ) ) = = O )
wh i l e ( 1 ) {
a=aA 1 Q ;
b = ra i s e ( S I GCHLD ) ;
p r i n t f ( " \ nMens a j e 1 [ %d ] :
%1 :
%1 \ a \ n " , g e tp i d ( ) , b , a ) ;
s l e ep ( 4 ) ;
s l e ep ( 1 6 ) ;
ki l l ( a , S I GUSR 1 ) ;
s l e ep ( 3 ) ;
k i l l ( ge tpp i d ( ) , S I GUSR2 ) ;
Figura 2.14 - Código C del programa m O 9 del Ejercicio 2.4
SOBUNIX: implementación y control de procesos multihilos
91
# i nc lude < s i gna l . h>
vo i d f 1 ( i n t s i g ) ;
ma in ( i nt a ,
char * b [ ] )
{
l ong c , d ;
s i gnal ( S I GUS R 1 , f 1 ) ;
s i gnal ( S I GUSR2 ,
S I G_DFL ) ;
d=atoi ( b [ 1 ] ) ;
if
( a = = 2 & & d= = 1 )
c = s i g s e tma s k ( s i gma s k ( S IGUSR1 ) ) ;
s i gb l o c k ( s i gma s k ( S IGUSR2 ) ) ;
pau s e ( ) ;
s i g s e tma s k ( c ) ;
else
pau s e ( ) ;
exi t ( 1 ) ;
v o i d f 1 ( i nt s i g )
p r i n t f ( " \ n \ n Texto 1 \ n " , s t r s i gna l ( s i g ) ) ;
Figura 2.15 - Código C del programa s 0 9 R del Ejercicio 2.5
2.4. En la Figura 2. 1 4 se muestra el código C del programa roO 9. Supóngase que al invocar este progra­
ma desde la línea de ordenes de un intérprete de comandos se crea un proceso con PID=2045 y que
la asignación de los PIDs de los procesos hijos, si se llegaran a crear, se realizaría incrementando
en una unidad el PID del proceso padre. Suponer además que el intérprete de comandos desde
donde se lanza roO 9 tiene asociado PID=2000.
a) Explicar razonadamente el funcionamiento de roO 9 si se invoca desde el intérprete de coman­
dos mediante la orden: roO 9
b) Comprobar que la respuesta dada en el apartado anterior es correcta compilando y ejecutando
este programa en un SOBUNIX.
2.5. En la Figura 2. 1 5 se muestra el código C del programa s 0 9R. Supóngase que al invocar este
programa desde la línea de ordenes de un intérprete de comandos se crea un proceso con PID=245 .
a) Explicar razonadamente el funcionamiento de s 0 9 R si se escriben consecutivamente las si­
guientes tres órdenes :
92
Ampliación de sistemas operativos
1) s09R 1 &
2) ki l l - S IGUSRl 2 4 5
3 ) ki l l - S IGUSR2 2 4 5
b) Comprobar que la respuesta dada en el apartado anterior es correcta compilando y ejecutando
este programa en un SOBUNIX.
2.6. Considérese el programa prog 2 7 del Ejemplo 2. 1 1 cuyo código C se muestra en la Figura 2.9.
Invocarlo en segundo plano desde la línea de ordenes del intérprete de comandos de un SOBUNIX
y a continuación escribir la orden ps j . A partir de la información que se muestra en la pantalla
contestar razonadamente a las siguientes preguntas :
-
a) ¿Cuál es el valor del SID ? ¿Cuál es el proceso líder de la sesión?
b) ¿Cuántos grupos de procesos existen? ¿Cuáles son sus PGID? ¿Cuántos miembros tiene cada
grupo?
Capítulo 3
SOBUNIX: planificación, sincronización y
mecanismos IPC
Objetivos docentes
Los objetivos docentes de este capítulo son los siguientes:
•
Conocer las características generales de la planificación de procesos multihilos en S OBUNIX.
•
Conocer los detalles de la implementación de la planificación de dos ejemplos ilustrativos de SO­
BUNIX: BSD 4.3 y S olaris.
•
Conocer las principales llamadas al sistema disponibles en los SOBUNIX para el control de la
prioridad de un proceso.
•
Conocer los conceptos de núcleo expropiable, núcleo no expropiable y puntos de expropiación
usados en SOBUNIX.
•
Conocer los principales mecanismos de sincronización usados por el núcleo de los S OBUNIX:
cerrojos y semáforos .
•
Saber e n qué consisten las operaciones d e dormir y despertar u n hilo del núcleo.
•
Saber qué es un canal de espera y cómo se le asocia una cola de hilos dormidos .
•
Saber qué son y para qué se utilizan los turnstiles.
•
Conocer el funcionamiento y las llamadas al sistema asociadas a los principales mecanismos de co­
municación entre procesos disponibles en la mayoría de SOBUNIX: mecanismos IPC del System
V (semáforos, colas de mensajes y memoria compartida), señales y tuberías.
93
94
Ampliación de sistemas operativos
3.1.
Introducción
Este capítulo se divide en tres partes. La primera parte está dedicada a describir la planificación de
procesos multihilos en SOBUNIX. En primer lugar se comentan las características generales. A conti­
nuación se describen los detalles de la implementación de la planificación en BSD 4.3 y Solaris, que
son dos ejemplos ilustrativos de SOBUNIX clásicos y modernos, respectivamente. Posteriormente se
realizan diferentes consideraciones sobre la expropiación del núcleo en los SOBUNIX.
La segunda parte de este capítulo está dedicada a describir los principales mecanismos de sincroni­
zación usados por el núcleo de un SOBUNIX: los cerrojos y los semáforos . También se describen las
operaciones de dormir y despertar un hilo del núcleo, y la implementación de las colas de hilos dormidos.
En la última parte de este capítulo se describen los mecanismos de comunicación entre procesos
disponibles en los SOBUNIX. En primer lugar se explican los mecanismos IPC del System V: semáforos,
colas de mensajes y memoria compartida. Estos mecanismos aunque introducidos en el System V han
sido adoptados por todos los SOBUNIX. Por último se explica el uso de las señales y las tuberías, que
son otros mecanismos IPC disponibles en los SOBUNIX.
3.2.
Planificación de procesos multihilos en SOBUNIX
3.2.1 .
Características generales
Los SOBUNIX son sistemas operativos multiprogramados, es decir, soportan la existencia de múlti­
ples programas cargados parcial o totalmente en la memoria principal. Cada programa, de acuerdo con
lo estudiado en el capítulo anterior, tiene asignado un proceso monohilo o un proceso multihilo. Además
si el núcleo soporta la existencia de hilos del núcleo, cada proceso tendrá asociado uno o más hilos del
núcleo.
Puesto que el número de procesos en el estado preparado para ejecución suele ser mucho mayor que
el número de procesadores existentes en un computador, el núcleo debe decidir qué procesos (o hilos del
núcleo) pasarán a ser ejecutados en los procesadores disponibles. A la parte del núcleo de un sistema
operativo encargada de esta tarea se le denomina planificador (scheduler). Nótese que si el núcleo del
SOBUNIX considerado soporta hilos del núcleo entonces el planificador utiliza como unidad o entidad
planificable a los hilos del núcleo. En caso contrario utilizará como unidad planificable a los procesos.
El planificador también se encarga de realizar los cambios de contexto, es decir, guardar el contexto
de la unidad planificable que va a ser desalojada de un procesador y cargar el contexto de la unidad
planificable que ha sido planificada para ser ejecutada en dicho procesador. Además el planificador se
encarga de la gestión de las diferentes estructuras de datos del núcleo necesarias para implementar la pla­
nificación, como por ejemplo las colas de unidades planificables en el estado preparado para ejecución.
En la mayoría de los SOBUNIX, el planificador implementa una planificación global basada en
múltiples colas de prioridad y realimentación. En este tipo de planificación, cada unidad planificable
tiene asignada una determinada prioridad, que es un número entero positivo comprendido entre O y un
cierto valor máximo Pmax · En algunos SOBUNIX el valor O corresponde a la máxima prioridad posible,
mientras que en otros la máxima prioridad corresponde a Pmax. El planificador siempre intenta que se
SOBUNIX : planificación, sincronización y mecanismos IPC
95
ejecute la unidad planificable de mayor prioridad, aunque esto no siempre es posible si el núcleo es no
expropiable (ver sección 3 .2.3).
El valor de la prioridad de una unidad planificable se establece en función de diferentes criterios:
el modo de ejecución (modo usuario o en modo núcleo), el tipo de trabajo (trabaj o interactivo, trabajo
por lotes, trabajo en tiempo real, trabajo del sistema operativo e interrupciones), el tiempo de procesador
consumido, el tiempo de espera en las colas, etc. El valor de la prioridad puede variar o no con el tiempo
de vida de la unidad planificable, es decir, la prioridad puede ser estática o dinámica. Por ejemplo, la
prioridad de las unidades planificables asociadas a las interrupciones suele ser alta y estática. Mientras
que la prioridad de las unidades planificables asociadas a trabajos por lotes suele ser baj a y dinámica.
En función del valor de su prioridad cada unidad planificable en el estado preparado forma parte de
una determinada cola de unidades planificables en el estado preparado o cola de prioridad. Las unidades
planificables que poseen una prioridad dinámica pueden pasar durante su tiempo de vida por diferentes
colas. El planificador establece una determinada planificación local para cada cola, como por ejemplo:
planificación PIFO, planificación de tiempo compartido, planificación basada en prioridades, etc.
Algunos SOBUNIX, como SVR4 o Solaris, para dotar de mayor flexibilidad al planificador definen
clases de planificación cada una de los cuales tiene asociada un rango de valores de prioridad y un
mecanismo de cálculo de la prioridad. Cada unidad planificable pertenece a una determinada clase de
planificación. Normalmente se dispone de una clase de planificación por cada tipo de trabaj o soportado
en el sistema: clase de trabajos en tiempo real, clase de trabajos de tiempo compartido o interactivos, etc.
Las clases de planificación son manipuladas por el planificador usando dos posibles tipos de funciones :
•
Funciones independientes de la clase. El planificador utiliza éstas funciones para la realización
de servicios que son comunes a todas las clases, como por ejemplo: el cambio de contexto y la
manipulación de las colas de planificación.
•
Funciones dependientes de la clase. El planificador utiliza éstas funciones para la realización de
servicios que dependen de la clase, como por ejemplo el cálculo de la prioridad. Cada clase sumi­
nistra su propia implementación de estas funciones .
Los SOBUNIX disponen de algunas llamadas al sistema para modificar, con ciertas restricciones, el
valor de la prioridad de un proceso o grupo de procesos, o para cambiar su clase de planificación. Por
ejemplo las llamadas al sistema n i c e y pr i o cnt l se encuentran disponibles en algunos SOBUNIX para
controlar la prioridad de un proceso.
3.2.2.
Dos ejemplos ilustrativos de la planificación en SOBUNIX
Aunque la planificación en los SOBUNIX presenta, en la mayoría de los casos, las características
generales comentadas en la sección anterior, cada SOBUNIX implementa estas características de una
determinada forma. En las siguientes secciones se describen a modo de ejemplo la planificación en dos
SOBUNIX diferentes : BSD 4 . 3 1 ( 1 986) y Solaris 10 (2005).
1 L a planificación e n SVR3 e s muy similar a la planificación e n BSD 4 . 3 , únicamente existen pequeñas diferencias e n el
nombre de algunas funciones y variables.
96
Ampliación de sistemas operativos
Planificación en BSD 4.3
BSD 4.3 es un sistema operativo de núcleo no expropiable (ver sección 3 .2.3) que utiliza como
unidad de planificación a los procesos, ya que el núcleo no soporta hilos del núcleo. Cada proceso tiene
asignada una prioridad de ejecución que es un número entero positivo comprendido dentro del rango de
valores [0, 1 27 ] , siendo O la prioridad más alta posible y 1 27 la prioridad más baja. La prioridad de un
proceso ejecutándose en modo usuario solo puede encontrarse dentro del rango [50, 1 27 ] . Los valores
comprendidos dentro del rango [0, 49] están reservados para la ejecución del núcleo.
El valor de la prioridad de un proceso se almacena en el campo p_pr i de su estructura pro c . Recuér­
dese (ver sección 2.2.2) que una estructura proc implementaba la entrada de un proceso en la tabla de
procesos del núcleo. También en esa misma estructura se mantiene el campo p_u s rpri donde se guarda
el valor de la prioridad que se le debe asignar al proceso cuando termine de ejecutarse en modo núcleo y
retome a modo usuario, por ejemplo al completarse una llamada al sistema. Mientras un proceso se está
ejecutando en modo usuario el valor de la prioridad almacenado en p_pri coincide con el almacenado
en p_u s rpr i .
2
E l núcleo invoca a través de u n callout una vez por segundo a l a función s chedcpu ( ) para recalcu­
lar el valor de la prioridad en modo usuario de cada proceso, el cual se almacena en p_u s rpr i . Además,
la prioridad en modo usuario del proceso en ejecución es recalculada por el manejador de la interrupción
del reloj cada cuatro tics de reloj . En ambos casos la prioridad en modo usuario se calcula usando la
siguiente fórmula [Vahalia, 1 995] :
.
p_usrpn
=
PUSER +
p cpu
.
4
+ 2·p_mce
(3 . 1 )
En la expresión anterior:
•
PUSER es una constante que vale 50 y que hace referencia a la prioridad en modo usuario base, es
decir, la prioridad más alta que puede tener un proceso ejecutándose en modo usuario.
•
p_cpu es un campo de la estructura proc que almacena una medida del uso de la CPU por parte
del proceso. El valor máximo de este campo está limitado a 1 27. Cuando se crea un proceso su
campo p_cpu se inicializa a O. Cada tic de reloj el manej ador de la interrupción de reloj incrementa
en una unidad el valor del campo p_cpu del proceso actualmente en ejecución. Un proceso que
acaba de usar la CPU tendrá un valor alto de p_cpu, luego el valor de p_u s rpri aumentará con
lo que su prioridad será más pequeña.
Por otra parte la rutina s c hedcpu ( ) , entre otras tareas, multiplica el valor del campo p_cpu
de cada proceso por un factor de decadencia (decay factor) que se calcula mediante la siguiente
expresión [Vahalia, 1 995] :
decay
=
2 · load_average
2·load_average + 1
(3.2)
2Los callouts son un mecanismo interno del núcleo para planificar la invocación de funciones de forma automática transcu­
rrido un cierto número de tics de reloj .
SOBUNIX: planificación, sincronización y mecanismos IPC
97
En la expresión anterior l o ad_average es el número medio de procesos en el estado preparado
en el último segundo. Como l oad_average es un número entero positivo entonces decay es un
número menor que l . Luego la rutina s chedcpu ( ) disminuye el valor de p_cpu de cada proceso.
Nótese que cuanto más tiempo pasa un proceso en espera de usar el procesador, el valor de su
p_cpu se hace mas pequeño debido al factor de decadencia. En consecuencia su valor p_u s rpri
se va reduciendo con lo que la prioridad del proceso en modo usuario aumenta.
•
p_n i c e . Es un campo de la estructura proc que almacena un valor entero positivo comprendido
dentro del rango [0, 39] denominado valor amable (nice value). Por defecto, el valor amable vale
20. Nótese que cuanto más pequeño sea el valor amable mayor será la prioridad en modo usuario
del proceso. El valor amable de un proceso puede ser configurado mediante el comando n i c e el
cual hace uso de la llamada al sistema homónima. Los usuarios pueden usar este comando para
aumentar el valor amable de un proceso y en consecuencia reducir su prioridad. De esta forma
estarían dejando pasar antes al procesador a otros procesos. Esto puede ser deseable por ejemplo
para los procesos que se ejecuten en segundo plano asociados a trabajos por lotes. El comando
ni ce también permite decrementar el valor amable para aumentar la prioridad de un proceso, sin
embargo esta acción solo la puede realizar el superusuario.
En modo núcleo la prioridad de un proceso no se recalcula en función del tiempo sino que se asigna
de forma directa. Un proceso cuando invoca a una llamada al sistema y pasa a ejecutarse en modo núcleo
continua ejecutándose en principio con la misma prioridad que tenía en modo usuario hasta que entra en
el estado dormido (bloqueado) en espera de que se produzca algún evento. Cuando el núcleo despierta
a un proceso en el estado dormido porque se ha producido el evento por el que se había bloqueado, el
núcleo aumenta temporalmente su prioridad asignándole un determinado valor dentro del rango [0, 49]
en función del evento por el que había entrado en el estado dormido.
En general la prioridad asignada en modo núcleo al despertar un proceso es mayor en función de
la importancia que suponga para el resto del sistema la atención rápida de dicho evento. Por ejemplo,
si un proceso esperaba por la recepción de una señal le asigna una prioridad de 40, si esperaba por la
terminación de un proceso hijo le asigna una prioridad de 30, si esperaba por la terminación de una
operación de E/S en el disco le asigna una prioridad de 20, si esperaba por el desbloqueo de un nodo-i le
asigna una prioridad de 1 O, etc.
En BSD 4.3 existen 32 colas de procesos en el estado preparado para ejecución (ver Figura 3 . 1 ) .
Cada cola s e implementa como una lista doblemente enlazada d e estructuras pro c . Cada cola i (i =
O, 1 , 2, . . . , 3 1 ) está asociada al rango de prioridades [4· i, 4·i + 3 ] formado por cuatro valores contiguos
de prioridad. Así la cola O está asociada al rango de prioridades [0, 3], la cola 1 al rango [4, 7], etc.
Solamente pueden formar parte de una determinada cola aquellos procesos en el estado preparado para
ejecución cuya prioridad esté dentro del rango de prioridades asociada a dicha cola.
Siempre se planifica para ejecución el proceso situado más cerca de la cabecera de la cola i asociada
al rango de prioridades más altas. Luego un proceso ubicado en una cola i se ejecutaría antes que uno
situado en la cola i + l .
Para determinar cuál es la cola i asociada al rango de prioridades más altas que no está vacía el núcleo
utiliza la variable global whi chqs . Esta variable es una máscara de 32 bits. Cada bit está asociado a una
98
Ampliación de sistemas operativos
cola. El bit más significativo de la máscara (el situado más a la izquierda) se toma como bit O y se asocia
a la cola O. Mientras que el bit menos significativo (el situado más a la derecha) o bit 3 1 está asociado
a la cola 3 1 . En general el bit i de la máscara se asocia a la cola i. Un bit i se configura a O si la cola i
a la que está asociado está vacía, en caso contrario se configura a l . El planificador examina la máscara
de bits de la variable whi chqs comenzando por el bit O en busca de un 1 , es decir, en busca de la cola
asociada al rango de prioridades más altas que no esté vacía.
Si en la cola i asociada al rango de mayor prioridad existen varios procesos, entonces se aplica sobre
dicha cola un algoritmo de turno rotatorio con un cuanto fijo de 1 00 ms. En el caso de un proceso
ejecutándose en modo núcleo, como el núcleo es no expropiable, su cuanto es infinito. El núcleo cuando
se termina el cuanto invoca mediante un callout a la rutina r oundrobin ( ) para planificar al siguiente
proceso de la cola i. Nótese que si en la cola i asociada al rango de mayor prioridad existe un único
proceso entonces éste se ejecutará hasta que se complete, independientemente de que expire su cuanto.
Si se está ejecutando un proceso A procedente de la cola i y entra un proceso B en una cola j con
j < i, es decir, deja de estar vacía una cola asociada a un rango de prioridades más alto que el proceso
actualmente en ejecución, entonces :
•
Si el proceso A se está ejecutando en modo usuario se le expropia el uso del procesador aunque no
haya terminado su cuanto y se le cede al proceso B .
•
Si el proceso A s e está ejecutando en modo núcleo, como el núcleo es no expropiable n o s e l e puede
expropiar al proceso A el uso del procesador. El planificador activa un indicador denominado
runrun para notificar que existe un proceso en una cola j asociada a un rango de prioridades
más alto que la prioridad del proceso A. Cuando el proceso vaya a retomar a modo usuario, el
planificador comprobará si runrun está activado y en caso afirmativo realizará un cambio de
proceso.
La rutina s chedcpu ( ) invocada cada segundo a través de un callout por el núcleo, aparte de las
tareas comentadas en los párrafos anteriores, también se encarga de colocar a lo procesos en las colas
adecuadas de acuerdo con su nuevo valor de prioridad.
e
Ejemplo 3.1
Supóngase que el estado de las colas de procesos preparados de un sistema BSD 4.3 es el que se muestra
en la Figura 3 . 1 . Se observa que no existe ningún proceso en la cola n° O ni en la cola no i. Por el contrario
hay dos procesos en la cola n° 1 y cuatro procesos en la cola no 3 1 .
Para determinar cuál será el próximo proceso que va a ser planificado el núcleo examina la variable
whi chqs de izquierda a derecha en busca de un 1 , es decir, busca la cola asociada al rango de prioridades
más altas que no esté vacía. Así, en primer lugar examina el bit O, este vale O ya que la cola n° O está
vacía. A continuación examina el bit l . Como la cola 1 contiene dos procesos el bit 1 tiene el valor l . Por
lo tanto se selecciona para ser planificado el proceso situado más cerca de la cabecera de la cola n° l .
•
La planificación usada en B S D 4.3 favorece a los procesos limitados por E/S frente a los procesos
limitados por la CPU. En general resulta adecuada para sistemas de tiempo compartido con una carga
SOBUNIX: planificación, sincronización y mecanismos IPC
99
Sentido de análisis
31
1
Prioridad
más alta
wh i chqs
Cola no O
Prioridad [0, 3 ]
Cola n o 1
Prioridad [ 4, 7]
Cola n° i
Prioridad [4i, 4i + 3]
Prioridad
más baja
Cola no 3 1
Prioridad [ 1 24, 1 27]
Figura 3.1 - Posible estado de las colas de procesos preparados
y
de la estructura whi chqs de un
sistema BSD 4.3
formada por trabajos interactivos y trabajos por lotes. Presenta sin embargo los siguientes inconvenientes
[Vahalia, 1 995] :
•
Calcular la prioridad en modo usuario de todos los procesos una vez por segundo produce una gran
sobrecarga si el número de procesos es elevado.
•
Puede presentar el problema de la inversión de prioridad debido a la no expropiabilidad del núcleo,
es decir, que un hilo de mayor prioridad tenga que esperar a usar el procesador porque lo está
usando una hilo de menor prioridad.
•
No garantiza un tiempo de respuesta determinado por lo que no sirve para aplicaciones de tiempo
real.
Planificación en Solaris
Solaris es un sistema operativo de núcleo expropiable (ver sección 3 .2.3) que utiliza como unidad
de planificación a los hilos del núcleo. Cada hilo del núcleo tiene asignado una prioridad global y una
clase de planificación. Esta información se almacena en la estructura kthread que el núcleo mantiene
por cada hilo del núcleo. En esta estructura existen, entre otros (ver sección 2.2.2), los siguientes campos
con información que se utiliza para la planificación del hilo:
100
Ampliación de sistemas operativos
Prioridad más alta
1 69
1
1
, -
�
Interrupciones (*)
1 60
1 59
1
1
1
1
1
1
-
Clase
RT
1 00
99
1
1
Clase SYS
�
60
59
Clase FX
Prioridad más baj a
1
1
1
1
1
-
Clases F S S , IA y TS
o
(*) Las interrupciones ocupan el rango [ 1 00, 1 09] si la clase RT no está cargada
Figura 3.2 - Prioridades de ejecución en Solaris
•
t__pr i . Contiene la prioridad global de ejecución del hilo que es un número entero positivo com­
prendido dentro del rango de valores [0, 1 69] , siendo 1 69 la prioridad más alta posible y O la
prioridad más baja. Las diez prioridades más altas [ 1 60, 1 69] están reservadas para la ejecución
de los hilos del núcleo asociadas al tratamiento de las interrupciones. Las prioridades restantes
comprendidas en el rango [0, 1 59] se reparten entre las clases de planificación definidas en Solaris
(ver Figura 3 .2).
•
t_epr i . Contiene la prioridad heredada del hilo que se utiliza temporalmente como prioridad
global cuando se aplica la técnica del traspaso o herencia de prioridades para evitar el problema
de la inversión de prioridades.
•
t_c i d. Contiene el identificador de la clase de planificación a la que pertenece el hilo. El identi­
ficador puede tomar los siguientes valores:
- RT (Real Time, tiempo real). Tiene asignada el rango de prioridades [ 1 00, 1 59] . Esta clase
está definida para la planificación de los hilos del núcleo asociados a trabajos de tiempo real.
- SYS (SYStem, sistema). Tiene asignada el rango de prioridades [60, 99] . Esta clase está
definida para la planificación de los hilos del núcleo asociados a tareas del núcleo.
SOBUNIX : planificación, sincronización y mecanismos IPC
101
- FX (FiXed, fija). Tiene asignada el rango de prioridades [0, 60] . Esta clase está definida para
la planificación de los hilos del núcleo asociados a trabajos cuya ejecución se desea que tenga
asignada una prioridad global fij a que no varíe durante el tiempo de vida del trabajo. Nótese
que un hilo perteneciente a esta clase puede ejecutarse con el valor de prioridad 60 de la clase
SYS, aunque durante un tiempo corto (cuanto pequeño).
- F S S (Fair Share, reparto justo). Tiene asignada el rango de prioridades [0, 59] . Esta clase está
definida para la planificación de los hilos del núcleo asociados a trabajos cuya ejecución se
desea que tenga asignada el mismo tiempo de uso del procesador. En esta clase los ciclos de
procesador son divididos en unas unidades denominadas cuotas (shares) que son distribuidas
de manera equitativa entre todos los hilos pertenecientes a la clase.
- TS (Time Share, tiempo compartido). Tiene asignada el rango de prioridades [0, 59] . Esta
clase está definida para la planificación de los hilos del núcleo asociados a trabajos de tiempo
compartido, como por ejemplo los intérpretes de comandos.
- IA (lnterActive, interactiva). Tiene asignada el rango de prioridades [0, 59] . Esta clase está
definida para la planificación de los hilos del núcleo asociados a trabajos interactivos de
interfaces de usuario gráficas (ventanas, menús, etc).
Cuando se arranca el sistema, el núcleo carga las clases SYS y T S . El resto de clases son cargadas
dinámicamente según se van necesitando o cuando se usan determinados comandos. Si la clase RT
no se carga entonces las prioridades quedan restringidas al rango [0, 1 09], siendo las prioridades
[ 1 00, 1 09] asociadas al tratamiento de las interrupciones.
•
t_c ldata. Puntero a una estructura xxproc donde xx puede ser t s , i a , f s s , fx o r t , cuya
definición puede encontrarse en el archivo xx . h. Esta estructura contiene la información necesa­
ria para poder calcular la prioridad del hilo del núcleo de acuerdo con las especificaciones de la
planificación propias de cada clase. Un hilo del núcleo perteneciente a la clase SYS no requiere de
esta estructura ya que se puede ejecutar todo el tiempo que necesite (cuanto infinito), hasta que se
complete o sea expropiado.
•
t_c l func s . Puntero a una estructura c l a s s func s que contiene un vector de funciones depen­
dientes de la clase de planificación para la asignación del cuanto, el cálculo de la prioridad, el
tratamiento del tic de reloj , etc.
El núcleo mantiene una tabla global de clases de planificación implementada como un array de
estructuras s c l a s s_t . Cada estructura s c l a s s contiene, entre otras, las siguientes informaciones sobre
una determinada clase: el nombre de la clase ( c l_narne ) , un puntero a la función de inicialización de
la clase ( c l_ini t ) y un puntero ( c l_func s ) a una estructura c l a s s func s_t que contiene un vector
de funciones dependientes de la clase. Además el núcleo mantiene una lista doblemente enlazada por
cada clase de planificación con las estructuras xxproc asociadas a los hilos del núcleo pertenecientes a
una determinada clase. En la Figura 3 . 3 se muestra a modo de resumen la relación entre las estructuras
descritas.
102
Ampliación de sistemas operativos
Tabla global de
clases de planificación
el name =RT
selass
e l init
rt
init ( )
e l f une s
e l name = SYS
selass
el
init
el
fune s
sys_i n i t ( )
e l a s s fune s
e l name = T S
selass
e l init
t s init ( )
e l fune s
[ kth] =kthread
Figura 3.3 - Estructuras de datos asociadas a las clases de planificación en Solaris
Un hilo del núcleo en el estado preparado (estado TS_RUN) es colocado en función de su prioridad
global en una determinada cola de un determinado conjunto de colas de prioridad o colas de hilos en el
estado preparado. Existe un conj unto de colas de prioridad por cada procesado¡-3 .
Además en cada conjunto existe una cola por cada valor de prioridad global disponible en función de
las clases cargadas. Por ejemplo, si estuvieran cargadas todas las clases de planificación en un conjunto
de colas asociado a un determinado procesador existirían 1 10 colas de prioridad: 1 0 colas para el rango
de valores de prioridad [ 1 60, 1 69] y 1 00 colas para el rango de prioridad [0, 99] .
Los hilos del núcleo en el estado preparado pertenecientes a la clase de planificación RT son colo­
cados en un conjunto de colas de prioridad especial denominado conjunto de colas de expropiación del
3En los computadores actuales un chip de procesador consta de M núcleos (cores) de procesanúento, además cada núcleo
tiene la capacidad de ejecutar N hilos del núcleo simultáneamente. Luego el número total de procesadores existente por chip es
M·N.
SOBUNIX: planificación, sincronización y mecanismos IPC
103
núcleo. Este conjunto consta de 60 colas de prioridad, una por cada valor de prioridad dentro del rango
[ 1 00, 1 59] asociado a la clase RT . Los hilos pertenecientes a este conjunto de colas pueden ser ejecutados,
por defecto, en cualquier procesador. Este trato preferente que reciben los hilos del núcleo pertenecientes
4
a la clase RT es para conseguir que su latencia de despacho sea lo menor posible. Recuérdese que los
trabajos de tiempo real deben ejecutarse dentro de unos plazos de tiempo preestablecidos.
El núcleo se encarga de establecer a qué conjunto de colas de prioridad pertenecerá cada hilo del
núcleo en el estado preparado, y en consecuencia de fijar el procesador en que se ejecutará cada hilo. Se­
ñalar que un usuario puede vincular la ejecución de un determinado trabajo a un determinado procesador
o grupo de procesadores.
En un determinado procesador siempre se planifica para ejecución el hilo del núcleo situado al prin­
cipio de la cola asociada a la prioridad global más alta que no esté vacía. Si en dicha cola existen varios
hilos del núcleo se aplica un algoritmo de planificación de turno rotatorio. El cuanto de ejecución asig­
nado a un hilo depende de la clase de planificación a la que pertenezca el hilo y en ocasiones también de
su prioridad global.
Los hilos del núcleo asociados a interrupciones o a la clase SYS disponen de un cuanto infinito. Los
hilos asociados a la clase F S S tienen un cuanto fijo de 1 1 0 ms. Para el resto de clases el cuanto varía
en función de la prioridad global del hilo. Normalmente cuanto menor es la prioridad del hilo mayor
es su cuanto de ejecución. Esto puede parecer contradictorio, sin embargo con esta política se pretende
compensar a los hilos de baja prioridad porque son los que más esperan para usar un procesador.
Si en la cola de mayor prioridad solo existe un hilo del núcleo éste dispondrá de un cuanto infinito,
es decir, se ejecutará hasta que finalice su ejecución, entre en el estado dormido o se le expropie el uso
del procesador porque llegué algún hilo a una cola asociada a un valor de prioridad mayor.
El núcleo mantiene por cada clase planificación (excepto la clase SYS) una tabla de despacho (dis­
patch table) en la que se almacena, entre otras informaciones, los posibles valores del cuanto. Cada
entrada de esta tabla se construye mediante una estructura xxdspent donde xx puede ser t s , i a , fx,
f s s o rt cuya definición puede encontrarse en el archivo xx . h . Unos campos presentes en la estructura
xxdspent_t de todas las clases son:
•
xx_gl obpr i . Prioridad global.
•
xx_quantum. Valor asignado al cuanto para la prioridad global xx_g l obpr i .
La información almacenada en esta tabla puede leerse haciendo uso del comando di spadmin.
e
Ejemplo 3.2
Si en un intérprete de comandos de Solaris se escribe la orden
di spadmin -g
-e
RT
en la pantalla aparecería la siguiente salida5 :
4La latencia de despacho es el tiempo transcurrido desde que un hilo entra en el estado preparado hasta que comienza a ser
ejecutado en un procesador.
5 Se han omitido varias líneas por cuestiones de espacio.
104
Ampliación de sistemas operativos
# Real T ime Di spatcher C on f i gura t i on
RES = 1 0 0 0
# TIME QUANTUM
# ( r t_quantum )
1000
#
PRIORITY
LEVEL
o
1000
800
#
#
9
10
800
600
#
#
19
20
600
400
#
#
29
30
400
200
#
#
39
40
200
100
#
#
49
50
100
#
59
S i se examina l a salida se observa que en l a segunda línea se muestra el valor asignado a l a constante
RES , cuyo inversa establece la unidad de tiempo del cuanto. Por defecto RES es igual a 1 000, luego la
unidad de tiempo del cuanto es 1 / 1 000 = 0,00 1 segundos, es decir, milisegundos (ms).
Es posible cambiar el valor de RES usando el comando di spadm i n con la opción -r. Si RES se fija a
1 00, entonces el cuanto se expresaría en tics de reloj . En Solaris, existen 1 00 tics por segundo, luego un
tic ocurre cada 10 ms.
En las siguientes líneas de la salida aparece el valor del cuanto r t_quantum en función del nivel de
prioridad ( PRIORITY LEVEL ) , el cual se relaciona directamente con la prioridad global. Para la clase RT
la prioridad global se obtiene sumando 1 00 al nivel de prioridad.
Luego el valor del cuanto toma los siguientes valores : 1 000 ms si la prioridad global pertenece al rango
[ 1 00, 1 09] , 800 ms si la prioridad global pertenece al rango [ 1 1 0, 1 1 9], 600 ms si la prioridad global
pertenece al rango [ 1 20, 1 29], 400 ms si la prioridad global pertenece al rango [ 1 30, 1 39], 200 ms si la
prioridad global pertenece al rango [ 1 40, 1 49] y 1 00 ms si la prioridad global pertenece al rango [ 1 50,
1 59] .
Se observa por lo tanto que el valor del cuanto disminuye según aumenta el rango de prioridad global
considerado.
•
SOBUNIX: planificación, sincronización y mecanismos IPC
105
Los hilos del núcleo de las clases de planificación F S S , FX, TS e IA, aparte de una prioridad global,
también tienen asociada una prioridad en modo usuario. La prioridad global determina la cola de priori­
dad en que se alojará un hilo en el estado preparado y el cuanto de ejecución que se le asignará. Por su
parte la prioridad en modo usuario es el valor que se asignará a la prioridad global cuando el hilo regrese
a modo usuario, ya que cuando un hilo de estas clases se ejecuta en modo núcleo su prioridad global
puede tomar, en algunos casos, valores de prioridad global pertenecientes a la clase de planificación SYS.
En modo usuario la prioridad global coincide con la prioridad en modo usuario.
Cada clase de planificación establece el mecanismo de cálculo de la prioridad en modo usuario.
Normalmente suele ser la suma de varias componentes, una de las cuales es configurable por el usuario.
A la componente de la prioridad en modo usuario configurable por el usuario se le denomina prioridad
de usuario.
Para configurar el valor de la prioridad de usuario de un hilo del núcleo se utiliza el comando
pri ocnt l . Este comando también permite cambiar la clase de planificación. Además permite confi­
gurar otros parámetros relativos a la planificación de un hilo (ver la página del comando en roan ) . Solo
el superusuario puede usar este comando para incrementar la prioridad de usuario de un hilo, el resto de
usuarios solo pueden decrementarla.
Cada clase de planificación tiene asociado un rango de valores permitidos para la prioridad de usua­
rio. Por ejemplo, en las clases F S S y FX la prioridad de usuario puede tomar valores comprendidos en
el rango [0, 60] . Mientras que en las clases TS y IA el rango de valores permitidos para la prioridad de
usuario es [-60, 60] . El comando p r i o c n t l - 1 permite visualizar estos rangos.
La prioridad en modo usuario y la prioridad de usuario de un hilo del núcleo se almacena en los
campos xx_umdp r i y xx_upr i , respectivamente, de su estructura xxproc, donde xx puede ser t s , i a ,
f s s o fx.
e
Ejemplo 3.3
En la clase de planificación TS la prioridad en modo usuario de un hilo del núcleo perteneciente a esta
clase se almacena en el campo t s_umdpri de su estructura t spro c . Su valor se calcula, ante la aparición
de ciertos eventos, de la siguiente forma:
ts_umdpri
=
{�
p i
59
si pri < O
si O :::; pri :::; 59
si pri > 59
(3 .3)
donde
pri
=
ts_cpupri + ts_upri
(3 .4)
De la expresión (3 .3) se deduce que la prioridad en modo usuario t s_umdpri solo puede tomar valores
comprendidos dentro del rango [0, 59] .
Por otra parte, en la expresión (3 .4) t s_upri es la prioridad de usuario y t s_cpup r i es la componente
de la prioridad en modo usuario controlada por el núcleo. Estas dos componentes se almacenan también
en la estructura t sproc_t .
106
Ampliación de sistemas operativos
Cuando se producen ciertos eventos el valor de t s_cpupri se actualiza consultando la tabla de despacho
de la clase T S . Cada entrada de esta tabla se implementa mediante una estructura t s dspend_t que
contiene los siguientes campos :
•
t s_g l obpr i . Prioridad global.
•
t s_quantum. Valor asignado al cuanto para la prioridad global t s_g l obpr i .
•
t s_tqexp . Valor que se asignará a t s_cpupri cuando el hilo consuma el cuanto asignado.
•
t s_s lpr e t . Valor que se asignará a t s_cpupri cuando el hilo regrese a modo usuario después
de ser despertado. Tiene como efecto el aumento de la prioridad del hilo, para que pueda acceder
antes a un procesador y compensar así el tiempo perdido mientras dormía.
•
t s_maxwa i t. Umbral de tiempo expresado en segundos que hay que esperar antes de aplicar
t s lwa i t .
•
t s_lwa i t . Valor que s e asignará a t s_cpupri s i e l hilo h a estado esperando para consumir su
cuanto un tiempo de espera superior a t s_maxwa i t .
E l tiempo de espera s e mantiene en el campo t s_di spwa i t de l a estructura t sproc_t asociada
a cada hilo. Este campo se inicializa a cero cuando un hilo es colocado en una cola de prioridad
después de haber consumido su cuanto o despertado porque se produjo el evento por el que estaba
esperando.
Si el hilo fue expropiado por un hilo de mayor prioridad t s_di spwa i t no se reinicia a cero. El
valor de t s_di spwa i t es incrementado una vez por segundo para cada hilo que se encuentra en
una cola de prioridad o en una cola de hilos dormidos (ver sección 3 .4).
S i el valor de t s_di spwa i t es mayor que t s_maxwa i t entonces se asigna a t s_cpupri el valor
t s_lwai t, lo que tiene como efecto el aumento de la prioridad del hilo.
De acuerdo con los campos anteriores, se deduce que el valor de t s_cpupri asociado a un hilo del
núcleo se actualiza cada vez que se produce alguno de los siguientes eventos : el hilo ha consumido su
cuanto, el hilo ha despertado y regresa a modo usuario, o el hilo lleva un tiempo de espera acumulado
superior a t s_maxwa i t .
E l valor actual de t s_cpupri especifica l a fila de l a tabla de despacho de l a clase R T que hay que
consultar. Por otra parte, el evento producido especifica la columna de la tabla de despacho donde se
encuentra el nuevo valor que hay que asignar a t s_cpupr i . Conocido este valor se recalcula de nuevo
la prioridad en modo usuario t s_umdp r i .
Por ejemplo, supóngase que un hilo del núcleo perteneciente a la clase TS tiene t s_cpup r i = 1 1 y
t s_upr i = 1 0. De acuerdo con (3 .4) p r i = 1 1 + 1 0 = 2 1 , luego de acuerdo con (3 .3) t s_umdp r i = 2 1 .
S i s e usa el comando di spadm i n g - e T S se puede visualizar el contenido de l a tabla despacho de
la clase T S . Las primeras doce entradas contienen los siguientes valores:
-
SOBUNIX: planificación, sincronización y mecanismos IPC
# t s_quanturn
200
200
200
200
200
200
200
200
200
200
160
160
t s_tqexp
o
o
o
o
o
o
o
o
o
o
o
1
t s_s lpret
50
50
50
50
50
50
50
50
50
50
51
51
t s_rnaxwa i t t s lwa i t
50
o
50
o
50
o
50
o
50
o
50
o
50
o
50
o
50
o
50
o
51
o
51
o
107
PRIORITY LEVEL
o
#
1
#
2
#
3
#
4
#
5
#
6
#
7
#
8
#
9
#
10
#
11
#
Puesto que t s_cpup r i = 1 1 l a fila de l a tabla de despacho que hay que consultar, cuando s e produzca
alguno de los eventos que generan un cambio de prioridad, es la fila asociada al nivel de prioridad
( PRIORITY LEVEL ) 1 1 . Se pueden producir los siguientes eventos:
•
Si el hilo consume su cuanto asignado entonces el valor de t s_cpupri se actualiza con el valor de
t s_tqexp de la fila 1 1 . Luego t s_cpupri = l. Como t s_upri = 1 0 entonces el nuevo valor de
la prioridad en modo usuario de acuerdo con (3.3) y (3 .4) será t s_urndp r i = 1 0 + 1 = 1 1 . Luego
la prioridad en modo usuario del hilo se reduce.
•
Si el hilo es despertado, cuando regresa a modo usuario el valor de t s_cpupr i se actualiza con
el valor de t s_s lpret de la fila 1 1 . Luego t s_cpup r i = 5 1 . Como t s_up r i = 10 entonces el
nuevo valor de la prioridad en modo usuario de acuerdo con (3 .3) y (3 .4) será t s_urndpri = 59.
Luego la prioridad en modo usuario del hilo aumenta.
•
Si el valor del tiempo de espera del hilo t s_di spwa i t es mayor que t s_rnaxwa i t entonces el
valor de t s_cpup r i se actualiza con el valor de t s_lwa i t de la fila 1 1 . Luego t s _cpupr i =
5 1 . Como t s_upr i = 1 0 entonces el nuevo valor de l a prioridad en modo usuario de acuerdo con
(3 .3) y (3.4) será t s _urndpri = 59. Luego la prioridad en modo usuario del hilo aumenta.
El nuevo valor de t s_urndpr i especifica el nuevo valor de la prioridad global, ya que en modo usuario
la prioridad global coincide con el valor de la prioridad en modo usuario. Además también especifica la
fila de la tabla de despacho que hay que consultar para conocer el nuevo valor del cuanto t s_quanturn.
Por ejemplo, si t s_urndp r i = 1 1 entonces t s_gl obpr i = 1 1 . Además hay que consultar la fila asociada
al nivel de prioridad ( PRI ORITY LEVEL ) 1 1 para conocer el nuevo valor del cuanto, que es t s_quanturn
= 1 60 ms (ya que RES = 1 000).
•
Cada clase de planificación especifica cuándo y cómo se modifican las prioridades de los hilos del
núcleo que pertenecen a dicha clase. De forma general, las prioridades de un hilo (global y en modo
usuario) pueden cambiar ante la aparición de determinados eventos, como por ejemplo:
108
Ampliación de sistemas operativos
•
El hilo ha consumido su cuanto de ejecución.
•
El hilo ha sido despertado, es decir, ha regresado al estado preparado para ejecución, porque ya se
ha producido el evento por el que entró en el estado dormido (bloqueado).
•
El hilo ha sido expropiado del procesador para ejecutar un hilo de mayor prioridad.
•
Un usuario utiliza el comando p r i ocnt l para cambiar la prioridad de usuario o/y la clase de
planificación del hilo.
Las prioridades de los hilos también pueden cambiar debido a la ejecución de funciones dependientes
de cada clase de planificación que son invocadas periódicamente para la realización de alguna de las
siguientes operaciones :
•
Procesamiento del tic de reloj. Esta operación afecta únicamente a los hilos del núcleo que están
ejecutándose en los procesadores, es decir, se encuentran en el estado ejecutándose ( T S_ONPROC ) .
Consiste en decrementar en un tic el contador xx_t ime l e f t de la estructura xxpro c , donde xx
puede ser t s , ia, f s s , fx o r t , el cual se inicializa con el valor del cuanto asignado al hilo.
Esta operación también comprueba si dicho contador ha alcanzado el valor O, es decir, el hilo
ha consumido su cuanto. En caso afirmativo, se modifica la prioridad del hilo de acuerdo con la
tabla de despacho (si procede en función de la clase) y se le fuerza a abandonar el procesador.
Esta operación es realizada por la función xx_t i c k ( ) la cual es invocada por el manejador de la
interrupción de reloj que se ejecuta 1 00 veces por segundo.
•
Actualización. Esta operación afecta a los hilos del núcleo en el estado preparado para ejecución
( TS_RUN) o en el estado dormido (TS_SLEEP ) pertenecientes a las clases T S , IA o F S S . Esta
operación es realizada por la función xx_upda t e ( ) una vez por segundo y es invocada mediante
un callout.
En el caso de las clases TS e IA la operación de actualización consiste en incrementar en un
segundo el contador del campo xx_d i s pwa i t de la estructura xxproc_t (donde xx puede ser
t s o i a ) y comprobar si el valor del tiempo de espera del hilo xx_di spwa i t es mayor que
xx_maxwa i t. En caso afirmativo se aumenta el valor de la prioridad usando la tabla de despacho.
B ásicamente con esta operación se pretende evitar el abandono de hilos.
En el caso de la clase F S S la operación de actualización consiste en actualizar el uso de cuotas y
en modificar la prioridad en función de dicho uso.
De acuerdo con la descripción realizada, se puede concluir que la planificación usada en Solaris es lo
suficientemente flexible para poder tratar adecuadamente en computadores con uno o varios procesadores
diferentes tipos de cargas de trabajos: interactivos, por lotes y de tiempo real. Por último conviene señalar
que a pesar del tratamiento privilegiado que reciben los trabajos de tiempo real, Solaris no es un sistema
operativo de tiempo real propiamente dicho sino un sistema operativo de propósito general.
SOBUNIX: planificación, sincronización y mecanismos IPC
3.2.3.
109
Expropiación del procesador
Como ha quedado puesto de manifiesto en las secciones anteriores en la planificación utilizada en los
SOBUNIX siempre tienen preferencia para ser planificadas las unidades planificables (procesos o hilos
del núcleo) situadas en la cola de unidades planificables de mayor prioridad que no esté vacía.
Si una unidad planificable U l se está ejecutando en un procesador P y llega una unidad planificable
U2 a una cola asociada al procesador P de mayor prioridad que la de U l , entonces si U l se está ejecutando
en modo usuario se le expropia el uso del procesador sin esperar a que termine su cuanto, y se planifica
para ejecución a U2. En el caso de que Ul se esté ejecutando en modo núcleo, la expropiación del
procesador depende de si el núcleo es no expropiable o expropiable.
Un núcleo se dice que es no expropiable si a una unidad planificable ejecutándose en modo núcleo
no se le puede expropiar el uso del procesador. Sólo se le puede expropiar en los siguientes casos : para
tratar las interrupciones, cuando regresa a modo usuario o cuando entra en el estado dormido a la espera
de que ocurra algún evento. Ejemplos de SOBUNIX de núcleo no expropiable son SVR3 y BSD 4 . 3 .
Este tipo d e núcleos son más propensos a sufrir e l problema d e la inversión d e prioridad, s i n embargo
reducen el número de mecanismos de sincronización usados en el núcleo (ver sección 3 . 3).
Por el contrario, un núcleo se dice que expropiable si a una unidad planificable ejecutándose en modo
núcleo se le puede expropiar el uso del procesador. En este caso, conviene tener presente que con objeto
de garantizar la integridad de las estructuras del núcleo existen algunas regiones de código del núcleo en
las que no está permitida la expropiación. A dichas regiones se les denomina puntos de no expropiación.
Un ejemplo de SOBUNIX de núcleo expropiable es Solaris . La implementación de un núcleo expropiable
requiere que las estructuras del núcleo estén protegidas por mecanismos de sincronización.
Algunos SOBUNIX, como por ejemplo SVR4, aplican una medida intermedia que consiste en per­
mitir la expropiación del núcleo sólo en determinados puntos del código del núcleo denominados puntos
de expropiación. En estos puntos se garantiza que las estructuras de datos del núcleo se encuentran en un
estado consistente. En estos sistemas una unidad planificable ejecutándose en modo núcleo solo puede
ser expropiada cuando alcanza un punto de expropiación.
La expropiación del procesador requiere la realización de un cambio de contexto y la manipulación
de las colas de prioridad asociadas al procesador P. La unidad planificable que es expropiada sin haber
concluido su cuanto, normalmente para compensarla, es colocada a la cabeza de la cola de prioridad a la
que pertenece.
Para notificar la existencia de una unidad planificable en una cola de mayor prioridad que la unidad
planificable actualmente en ejecución, es decir, para saber si hay que expropiar el procesador, el núcleo
activa uno o varios indicadores que son comprobados cuando se producen determinados eventos.
e
Ejemplo 3.4
El núcleo de BSD 4.3 para notificar que existe un proceso en una cola asociada a un rango de prioridades
más alto que la prioridad del proceso actualmente en ejecución activa un indicador denominado runrun.
Como el núcleo de BSD 4.3 es no expropiable la comprobación del estado de runrun se realiza cuando
el proceso va a retornar a modo usuario. Si runrun está activado se realiza un cambio de proceso.
•
1 10
e
Ampliación de sistemas operativos
Ejemplo 3.5
El núcleo de Solaris para notificar que existe un hilo del núcleo en una cola asociada a un rango de prio­
ridades más alto que la prioridad del hilo actualmente en ejecución, activa los indicadores cpu_runrun
o cpu_krunrun de la estructura cpu asociada al procesador en que se está ejecutando el hilo.
Recuérdese que en Solaris cada procesador tiene asociada un conjunto de colas de prioridad independien­
tes, luego existe una estructura cpu por cada procesador. Estos indicadores son comprobados cuando se
producen cambios en la prioridad de los hilos y se manipulan las colas de prioridad.
Para un determinado procesador P, el indicador cpu_krunrun se activa cuando un hilo es colocado en
una cola de P cuya prioridad es mayor o igual que 1 00 y además dicha prioridad es mayor que la del hilo
actualmente ejecutándose en P.
Por su parte, el indicador cpu_runrun se activa cuando un hilo es colocado en una cola de P cuya
prioridad es menor que 1 00 y además es mayor que la del hilo actualmente ejecutándose en P.
La expropiación asociada a cpu_krunrun se realiza más rápidamente que la asociada a cpu_runrun,
esto es así para reducir la latencia de despacho de los hilos asociados a aplicaciones de tiempo real y de
las interrupciones que son las actividades más prioritarias.
En S olaris la expropiación se deshabilita temporalmente cuando un hilo ejecutándose en modo núcleo
está dentro de un punto de no expropiación.
•
3.3.
Mecanismos de sincronización del núcleo en SOBUNIX
El código del núcleo de los SOBUNIX es reentrante. Esta característica posibilita el que varios hilos
del núcleo 6 ejecutándose en modo núcleo puedan estar ejecutando concurrentemente la misma región de
código del núcleo.
En un sistema monoprocesador solo un hilo se encontrará en el estado ejecutándose en modo núcleo.
En un sistema multiprocesador pueden existir varios hilos ejecutándose en modo núcleo, uno en cada
procesador existente.
En el código del núcleo existen secciones críticas asociadas a diferentes recursos críticos, como por
ejemplo las estructuras de datos del núcleo. Para garantizar la exclusión mutua en la ejecución de una
sección crítica del núcleo asociada a un cierto recurso crítico, el núcleo utiliza diferentes mecanismos de
sincronización, como por ejemplo los cerrojos y los semáforos. Estos mecanismos serán descritos en las
próximas secciones.
Los diseñadores del núcleo de un sistema operativo son los encargados de elegir los tipos de meca­
nismos de sincronización que utilizarán en el núcleo y dónde los aplicarán.
6 En esta sección se va a considerar, salvo que se indique lo contrario, que las unidades planificables son los hilos del núcleo.
SOBUNIX : planificación, sincronización y mecanismos IPC
3.3. 1.
111
Cerrojos
U n cerrojo (lock) e s una primitiva de sincronización que consiste e n u n indicador entero que puede
encontrarse en dos estados: abierto o libre (valor O) y cerrado o adquirido (valor 1 ) . Sobre un cerroj o se
pueden realizar dos operaciones básicas 7 :
•
•
Cerrar o adquirir cerrojo. Esta operación lee el valor del cerrojo, si vale O (abierto) lo pone a 1
(cerrado). Por el contrario si el cerrojo vale 1 (cerrado) entonces el hilo que invoca esta operación
debe esperar a que el cerrojo se ponga a O. Esta espera puede implementarse (depende del tipo de
cerrojo) como una espera activa o durmiendo en una cola de hilos dormidos asociada al cerrojo.
La comprobación y configuración del valor cerrojo se implementa con una instrucción máquina
especial que se ejecuta de forma atómica, como por ejemplo la instrucción comprobar y configurar
(test and set).
Abrir o liberar cerrojo. Esta operación configura el cerrojo al valor O (abierto) . Además si el
cerrojo no implementa espera activa entonces despierta, si existe alguno, a un hilo de la cola de
hilos dormidos del cerrojo.
Cada recurso crítico del núcleo tiene asociado su propio cerrojo. Para garantizar la exclusión mutua
en el uso de un recurso crítico R del núcleo, un hilo del núcleo antes de entrar en una sección crítica
asociada a R realiza una operación cerrar cerrojo para adquirir R. Cuando el hilo termina de ejecutar la
sección crítica realiza una operación abrir cerrojo para liberar a R y que otro hilo pueda usar el recurso.
En función de cómo se implementa la espera de un hilo del núcleo HN 1 dentro de una operación
cerrar cerrojo se distinguen tres tipos de cerrojos:
•
Spinlock 8 • La espera del hilo es activa, es decir, el hilo comprueba el valor del cerrojo dentro
de un bucle que se ejecuta mientras el cerrojo permanezca cerrado. La espera activa supone un
inconveniente si se dilata mucho en el tiempo ya que la ejecución del hilo HN 1 en un procesador
impide que otros hilos lo usen.
La principal ventaj a de los spinlocks es la rapidez con que HN l adquiere el cerrojo. Cuando el
hilo HN2 que mantiene cerrado el cerrojo lo abre, el hilo HN 1 que espera activamente lo adquiere
rápidamente puesto que HN 1 ya está ejecutándose y no hay que realizar un cambio de contexto.
Obviamente se está suponiendo que en el computador existente al menos dos procesadores, en
uno se ejecuta HN2 y en el otro HN l . Nótese que en un computador con un único procesador si
el núcleo es no expropiable y HN 1 realiza una operación cerrar cerrojo sobre un cerrojo que se
encuentra cerrado entonces la espera activa será infinita.
•
Cerrojo con bloqueo. El hilo HN 1 se bloquea y es colocado en una cola de hilos dormidos asociada
al cerrojo. Cuando el cerroj o sea abierto, se despertará al primer hilo de la cola o al hilo de mayor
prioridad, el cual debe realizar otra operación cerrar cerrojo para adquirir el cerrojo. La principal
7El nombre que reciben estas operaciones varía en la literatura y en los diferentes SOBUNIX.
8 Spinlock es un término inglés que podría traducirse como cerrojo con vuelta. Esta traducción al español no está muy
extendida en la literatura por ello se ha preferido mantener el término en su idioma original .
1 12
Ampliación de sistemas operativos
ventaja de los cerrojos con bloqueo es que al no realizar espera activa no acaparan un procesador
mientras esperan, a diferencia de los spinlocks. Su principal inconveniente es que la adquisición
de un cerrojo es más lenta que en el caso de los spinlocks ya que requiere al menos la realización
de dos cambios de contexto.
•
e
Cerrojo adaptativo. El hilo HN l puede realizar una espera activa o bloquearse. El tipo de espera
dependerá del estado del hilo HN2 que actualmente mantiene el cerrojo cerrado. Si HN2 se está
ejecutando en un procesador P l entonces tardará poco en abrir el cerrojo, luego HN l realiza una
espera activa en otro procesador P2. Por el contrario si HN2 se encuentra en el estado bloqueado
puede tardar en abrir el cerrojo, luego HN l espera bloqueado. Estos cerrojos pretenden evitar los
inconvenientes de los spinlocks y de los cerrojos con bloqueo. Su principal desventaj a es que su
implementación es más compleja ya que hay que implementar mecanismos para detectar que hilo
retiene un cerrojo y en que estado se encuentra.
Ejemplo 3.6
En la Figura 3.4 se muestra, en pseudocódigo basado en C, un ejemplo de uso de un cerrojo L de tipo
spinlock. Este cerrojo se usa para garantizar la exclusión mutua en el uso del campo d de la estructura de
datos del núcleo da to sN. Asimismo en la Figura 3 . 5 se muestra una posible definición de las operaciones
cerrar cerrojo y abrir cerrojo del spinlock. En la operación c e r rar_c erroj o se utiliza la instrucción
atómica c omprobar_y_c on f i gurar que comprueba el valor del cerrojo. Si el cerrojo vale O (abierto)
lo pone a ! (cerrado) y devuelve TRUE con lo que sale del bucle whi l e y se termina la espera activa. Por
el contrario, si el cerrojo vale 1 (cerrado) entonces devuelve FALS E y se vuelve a ejecutar el bucle, es
decir, continúa la espera activa.
•
s t ruc t dato s_nuc l e o {
s p i n l o c k_t L ;
int d ;
da t o s N ;
vo i d func i on ( )
c e rrar_c erro j o ( &da t o s N . L ) ;
da t o s N . d= l ;
/ * S e c c i ón c r í t i c a * /
abr i r_cerro j o ( &da t o s N . L ) ;
Figura 3.4 - Ejemplo de uso de un cerrojo de tipo spinlock para garantizar la exclusión mutua
SOBUNIX : planificación, sincronización y mecanismos IPC
113
vo i d c errar_ c e r ro j o ( s p i n l o c k_ t * C e rro j o )
wh i l e ( c omprobar_y_ c on f i gurar ( c e r r o j o ) ! =
vo i d abr i r_c e r r o j o ( s p i n l o c k_t
0) ;
* C e rro j o )
* C erroj o = O ;
Figura 3.5 - Posible definición de las operaciones
de tipo spinlock
c e r r a r_c e r r o j o y abr i r_c err o j o
de un cerrojo
En general al diseñar el código del núcleo de un sistema operativo se intenta que las regiones críticas
no sean muy numerosas y que éstas sean cortas. En consecuencia se suelen utilizar spinlocks para pro­
teger la mayoría de los recursos críticos del núcleo, ya que la espera activa será pequeña. Para aquellos
recursos críticos cuyas secciones críticas asociadas sean más largas o puedan requerir la suspensión del
hilo que se encuentra dentro de ellas entonces se utilizan cerrojos con bloqueo. Si no se sabe si el hilo
puede suspenderse entonces mej or usar cerrojos adaptativos.
De acuerdo con el funcionamiento de los cerrojos descrito en los párrafos anteriores, cuando un hilo
cierra un cerroj o asociado a un recurso crítico R, ningún otro hilo puede acceder a R. A los cerrojos con
este comportamiento en algunos sistemas se les denomina cerrojos exclusivos o cerrojos mutex.
Existe otro tipo de cerroj o denominado cerrojo lector1 escritor o cerrojo R/W cuyo funcionamiento
depende del tipo de acceso que se desee realizar sobre el recurso. Si el acceso es de escritura entonces
solo un hilo puede acceder al recurso. Por el contrario, si el acceso es de lectura entonces pueden acceder
múltiples hilos. Básicamente un cerrojo R/W resuelve uno de los problemas clásicos de sincronización
de hilos concurrentes : el problema de los lectores y los escritores [Díaz et al. , 20 1 1 ] .
Los cerrojos R/W a diferencia de los cerrojos mutex requieren en su implementación de dos colas de
hilos dormidos: una cola para los hilos lectores y otra para cola los hilos escritores. Los lectores duermen
mientras haya un escritor usando el recurso. Por su parte los escritores duermen si hay algún hilo, ya sea
lector o escritor.
3.3.2.
Semáforos
Un semáforo binario, también denominado mutex, es una variable entera, que puede tomar los valores
O o 1 y sobre la que es posible realizar las siguientes operaciones 9 :
•
ini t_s em ( S , va l o r ) . Inicializa el semáforo S a un determinado valor, es decir, S =va l o r, don­
de va l o r es igual a O o a l .
9EJ nombre dado a estas operaciones varía en la literatura y en Jos diferentes SOBUNIX. Aquí se utiliza el nombre propuesto
en [Díaz et al . , 20 1 1 ] . Las operaciones wa i t_s em ( S ) y s i gnal_s em ( S ) equivalen, respectivamente, a las operaciones
P(S) y V(S) definidas en [Dijkstra, 1 965 ] .
Ampliación de sistemas operativos
114
•
wa i t_s em ( S ) . Comprueba el valor del semáforo s . Si S = O , entonces el proceso pasa al estado
dormido y es colocado en una cola de hilos dormidos asociada al semáforo. Si S = l , entonces pone
el semáforo a O y el hilo puede continuar su ejecución.
•
s i gna l_s em ( s ) . Comprueba si la cola de hilos dormidos asociada al semáforo S está vacía. En
caso afirmativo, pone el semáforo a 1 , y continúa su ejecución. En caso negativo, es decir, hay hilos
bloqueados en el semáforo, entonces el sistema operativo elimina de la cola asociada al semáforo a
uno de los hilos dormidos, y le despierta lo que hace que pase al estado preparado para ejecución.
Existe, además, otro tipo de semáforo denominado semáforo general o semáforo con contador que es
una variable entera que puede tomar más valores aparte de O o l . Para un semáforo general la operación
ini t_s em ( s , val or ) consiste en inicializar el valor del semáforo S a un determinado valor entero
positivo N, es decir, S =N.
Por su parte la operación wa i t_s em ( s ) cuando se implementa para un semáforo general disminuye
en una unidad el valor del semáforo. Es decir, S = S - 1 . Si el valor resultante es un número negativo
entonces el hilo que ha invocado esta operación entra en el estado dormido y es añadido a la cola de
hilos dormidos asociada al semáforo. En el caso de la operación s i gnal_s em ( s ) se incrementa en una
unidad el valor del semáforo, es decir, S = S + l . Si el valor resultante es menor o igual a O entonces se
elimina de la cola asociada al semáforo uno de los hilos dormidos, y se le despierta, lo que hace que pase
al estado preparado para ejecución.
La realización de las operaciones wa i t_s em y s i gna l_s em, independientemente del tipo de se­
máforo, requiere garantizar la exclusión mutua durante la comprobación y configuración del valor del
semáforo. Dicha exclusión mutua se suele implementar con una instrucción máquina especial que se
ejecuta de forma atómica.
La principal ventaja de los semáforos es que proporcionan un mecanismo de sincronización a alto
nivel que se puede aplicar para resolver diferentes problemas de sincronización. Así, los semáforos bina­
rios se utilizan para garantizar la exclusión mutua o para sincronizar la ejecución de hilos que esperan por
un evento. Por su parte, los semáforos generales se pueden usar para las mismas funciones que los semá­
foros binarios. Además permiten contar el número de instancias disponibles de un determinado recurso
crítico, para ello simplemente hay que inicializar el semáforo con el número de instancias existentes.
El principal inconveniente de los semáforos [Vahalia, 1 995] es que son abstracciones de alto nivel
que se implementan con mecanismos de sincronización de baj o nivel para poder garantizar la atomicidad
y la exclusión mutua. La implementación de las operaciones wa i t_s em y s i gnal_s em requiere una
operación atómica de bajo nivel que garantice el acceso con exclusión mutua a la variable semáforo.
Por otra parte, el bloqueo y desbloqueo de procesos requiere la realización de cambios de contexto y la
manipulación de las colas de procesos preparados y de las colas de procesos dormidos, lo que ralentiza
las operaciones sobre los semáforos.
Los núcleos de los primeros SOBUNIX utilizaban como mecanismo de sincronización principal­
mente semáforos. Posteriormente, debido a la relativa lentitud de sus operaciones, han sido sustituidos
por cerrojos. En los núcleos de los S OBUNIX actuales los semáforos binarios se utilizan principalmente
para garantizar la exclusión mutua sobre aquellos recursos críticos del núcleo que pueden ser usados
SOBUNIX: planificación, sincronización y mecanismos IPC
115
sin fuertes restricciones de tiempo. También se utilizan semáforos generales para contar el número de
instancias disponibles de un determinado recurso crítico del núcleo.
e
Ejemplo 3.7
En la Figura 3 . 6 se muestra en pseudocódigo basado en C un ejemplo de uso de un semáforo binario
mu t ex l , para garantizar la exclusión mutua en el uso de una sección crítica asociada a un determinado
recurso crítico del núcleo.
Asimismo, en la Figura 3 .7 se muestra un ejemplo de uso de un semáforo general c on t ador para contar
las instancias disponibles de un determinado recurso crítico del núcleo del que existen M instancias .
•
f*
I n i c i a l i z a c i ón de l
s emá f o ro * f
s emá f o ro_binar i o mu t ex l ;
i n i t_s em ( &mu t exl ,
1) ;
f * U s o para garant i z ar l a exc l u s i ón mu tua * 1
wa i t_s em ( &mu t ex l ) ;
e j ecuc i ón s e c c i ón c r í t i c a ;
s i gnal_s em ( &mu t e x l ) ;
Ejemplo de uso de un semáforo binario para garantizar la exclusión mutua en el uso de una
sección crítica asociada a un cierto recurso del núcleo
Figura 3.6
f*
-
In i c i a l i z a c i ón del
s emá f oro * f
s emá f o ro_general c o n t a do r ;
i n i t_s em ( & contador ,
M) ;
f * U s o para contar núme r o de i n s t anc i a s d i sponi b l e s
*f
wa i t_s em ( &contador ) ;
u s o i n s t anc i a recur s o ;
s i gna l_s em ( & c on t ador ) ;
Figura 3.7 - Ejemplo de uso de un semáforo general para contar el número de instancias disponibles de
un recurso del núcleo
1 16
3.4.
Ampliación de sistemas operativos
Dormir 1 despertar y colas de hilos dormidos en SOBUNIX
En los SOBUNIX cuando un hilo ejecutándose en modo núcleo tiene que esperar un tiempo que
puede sea largo por un evento o recurso se invoca a una rutina del núcleo para dormir (bloquear) el hilo.
Esta rutina coloca al hilo en una cola de hilos dormidos del núcleo, cambia su estado a dormido e invoca
al planificador para que seleccione para ser ejecutado a otro hilo, lo cual requerirá, entre otras acciones,
la realización de un cambio de contexto.
Cuando se produzca el evento o se libere el recurso, el núcleo invocará una rutina para despertar
(desbloquear) al hilo esperando por dicho evento o recurso. Esta rutina debe encontrar al hilo en la cola
de hilos dormidos adecuada, cambiar el estado del hilo a preparado para ejecución y colocarlo en una
cola de hilos preparados para ejecución en espera de ser planificado para ejecución en un procesador.
Cada recurso o evento tiene asignado un canal de espera (wait channel), también denominado canal
de dormir (sleep channel), que es un número de 32 bits que almacena la dirección del recurso. Nótese
que todo evento también estará asociado a un recurso. Por ejemplo, el evento de que se complete una
operación de E/S estará asociado a un determinado buffer del núcleo donde se encontrará el dato que
desea leer o escribir. La rutina del núcleo que bloquea el hilo almacena el canal de espera asociado al
recurso o evento en un campo de la estructura de datos del hilo.
Por otra parte, cada canal de espera tiene asociada una cola de hilos dormidos. La asociación se
realiza mediante una función hash ya que el número de colas de hilos dormidos que mantiene el núcleo
es inferior al número de canales. Por lo tanto varios canales de espera pueden tener asociada la misma
cola.
e
Ejemplo 3.8
Considérese dos estructuras de datos del núcleo Rl y R2 cuyo acceso está protegido con los cerrojos C l
y C2, respectivamente. Supóngase que un hilo del núcleo HN l cierra C l y entra en el estado dormido en
espera de que se complete una operación de lectura de un bloque del disco duro que se almacenará en
R l . Mientras duerme HN l , otro hilo HN2 también necesita usar R l y realiza una operación cerrar sobre
C l . Como C l está cerrado por HN l , entonces HN2 entra en el estado dormido en espera de que HN l
abra C l .
Por otra parte, supóngase que un hilo del núcleo HN3 cierra C2. Mientras HN3 opera sobre la estructura
R2 otro hilo HN4, que requiere usar también R2, realiza la operación cerrar C2 y entra el estado dormido
en espera de que HN3 abra C2.
La dirección de cada recurso Rl y R2 constituye dos canales de espera independientes Wl y W2. En este
escenario, HN l y HN2 duermen en el mismo canal de espera W l . Mientras que HN4 duerme en el canal
de espera W2.
En la Figura 3 . 8 se muestra un posible estado de las colas de hilos dormidos del núcleo. Se ha supuesto
que la función hash ha asignado la misma cola de hilos dormidos a los canales W l y W2, aunque podría
haberles asignado colas diferentes, dependerá del valor de W l , de W2 y de la función hash utilizada .
•
SOBUNIX : planificación, sincronización y mecanismos IPC
Cerrojo
_____..
1 17
C1
Recurso
Rl
Canal
de espera
Wl
HN4
C2
R2
Conjunto de colas de hilos dormidos
Figura 3.8 - Asignación de colas de hilos dormidos del Ejemplo 3 . 8
L a existencia d e hilos esperando por distintos canales dentro d e una misma cola introduce retrasos
a la hora de despertar a los hilos esperando en un determinado canal, ya que hay que examinar uno
a uno todos los hilos de la cola. Para eliminar este retraso, podría mantenerse una cola por canal. El
inconveniente de esta solución es que consume bastante memoria principal ya que se necesita un número
de colas elevado.
Una solución más eficiente desde el punto de vista del consumo de memoria es la utilizada en Solaris.
Esta solución tiene en cuenta el hecho de que muchos de los bloqueos de los hilos en modo núcleo
se producen en objetos de sincronización (cerrojos, semáforos, . . . ) que protegen los recursos críticos.
Además en un determinado instante de tiempo solo se están utilizando una pequeña parte de los muchos
objetos de sincronización existentes en el código del núcleo.
Teniendo en cuenta las consideraciones anteriores, cada objeto de sincronización del núcleo de So­
laris tiene un campo de dos bytes que contiene un puntero a un turnstile que es una estructura de datos
que contiene, entre otras informaciones, la cabecera de una cola de hilos dormidos. Los hilos en la cola
de un turnstile se organizan por prioridad. Además existe la posibilidad de despertar a todos los hilos de
la cola o solamente al más prioritario.
El núcleo mantiene un conj unto de turnstiles de tamaño dinámico, siempre mayor que el número de
hilos del núcleo activos. Cuando en un objeto de sincronización se bloquea un primer hilo el núcleo asig­
na al objeto de sincronización un turnstile para implementar una cola de hilos dormidos. En el momento
que la cola se queda vacía el tumstile queda libre y puede ser asignado a otro objeto de sincronización.
Por lo tanto, en Solaris conviven dos tipos de colas de hilos dormidos : las implementadas con turns­
tiles para bloqueos en objetos de sincronización y las colas de hilos dormidos en canales de espera para
1 18
Ampliación de sistemas operativos
eventos o recursos no relacionados con objetos de sincronización, como por ejemplo la finalización de
una operación de E/S. Obviamente el número de colas de este segundo tipo es mucho más pequeño que
en otros S OBUNIX gracias al uso de turnstiles.
e
Ejemplo 3.9
En la Figura 3.9 se muestra el estado del conjunto de turnstiles del núcleo de un sistema Solaris para el
escenario descrito en el ejemplo anterior. Se observa que los cerrojos Cl y C2, al tener hilos bloquea­
dos en ellos, tienen asignado cada uno un turnstile (TU) para implementar las colas de hilos dormidos
correspondientes.
Asignado
a Cl
Recurso
Rl
Canal
de espera
Wl
Libre
Asignado
a C2
--------·
Libre
R2
HN2
1 1
8=8
TO
TU
HN4
1 1
TO
W2
Conjunto de tumstiles
Figura 3.9 - Ejemplo de uso de tumstiles
•
3.5.
Mecanismos de comunicación entre procesos en SOBUNIX
Los SOBUNIX ponen a disposición de los programadores de aplicaciones diferentes mecanismos
para garantizar la exclusión mutua en el uso de recursos críticos, sincronizar su ejecución, esperar por
la aparición de algún evento o intercambiar información. A este conjunto de mecanismos se les cono­
ce de forma general como mecanismos de comunicación entre procesos, o más abreviadamente como
mecanismos IPC(InterProcess Communications).
SOBUNIX: planificación, sincronización y mecanismos IPC
1 19
Es el programador de aplicaciones el que decide qué mecanismos IPC utilizar y dónde utilizarlos
dentro del código de sus aplicaciones. El uso de estos mecanismos requiere la invocación de las lla­
madas al sistema oportunas. El núcleo se encarga de atender dichas llamadas al sistema y mantener las
estructuras de datos necesarios para soportar dichos mecanismos IPC.
En las siguientes secciones se describen los mecanismos IPC introducidos por primera vez en 1983
en el System V Release 1 de AT&T y posteriormente adoptados por el resto de SOBUNIX: los semáforos,
las colas de mensajes y la memoria compartida. A estos tres mecanismos se les conoce de forma general
como mecanismos IPC del System V. También se describen otros mecanismos IPC como las señales y
las tuberías, usados principalmente en los intérpretes de comandos.
3.5.1.
Mecanismos IPC del System V
Los tres mecanismos IPC del System V: semáforos, colas de mensajes y memoria compartida, aun­
que son mecanismos distintos son soportados por el núcleo de forma muy similar. El núcleo mantiene una
tabla por cada tipo de mecanismo IPC. Una entrada en una de estas tablas se implementa mediante una
estructura de datos que contiene información de administración y control sobre un determinado recurso
IPC, es decir, sobre una instancia de un determinado mecanismo IPC. Entre la información contenida en
una entrada se encuentra la siguiente:
•
Creador del recurso IPC. El UID y el GID del proceso que solicita la creación el recurso.
•
Propietario del recurso IPC. El UID y el GID del proceso que actualmente es el propietario del
recurso. Inicialmente, el creador es el propietario del recurso, aunque el mismo o el superusuario
pueden transferir la propiedad del recurso a otro proceso.
•
Permisos del recurso IPC. Mascara de bits, similar a la máscara de modo de un archivo, que permite
establecer los permisos de acceso (lectura y/o escritura) al recurso para el propietario del recurso,
el grupo propietario y el resto de usuarios.
•
Llave o clave del recurso IPC . Número entero facilitado al núcleo por el proceso que solicita la
creación o el acceso al recurso IPC. Solo los procesos que conozcan dicha llave podrán acceder
al recurso. Luego se puede considerar como una especie de contraseña de acceso. La llamada al
sistema f t ok permite crear una llave de acceso.
•
Información propia de cada tipo de recurso IPC. Como por ejemplo punteros que permiten locali­
zar a los diferentes componentes de un determinado recurso IPC.
El número máximo de entradas que puede tener la tabla asociada a un determinado tipo de mecanismo
IPC, o lo que es lo mismo el número de recursos IPC de un determinado tipo, es un parámetro que puede
ser configurado por el superusuario.
Por otra parte, el núcleo asigna a cada recurso IPC creado un determinado identificador numérico
entero que lo identifica de manera unívoca. El núcleo usa este identificador para localizar la entrada
asociada al recurso en la tabla correspondiente. La asignación del identificador se realiza en el momento
Ampliación de sistemas operativos
120
de la creación o asignación del recurso. El núcleo devuelve este identificador al proceso para que lo
utilice como argumento de entrada en las posteriores llamadas al sistema que vaya a realizar para operar
sobre el recurso, y así agilizar su localización.
Semáforos
La implementación que hace el núcleo de los semáforos como mecanismo IPC es distinta a la im­
plementación de los semáforos como mecanismo de sincronización del núcleo estudiada en la sección
3 . 3 .2, y no deben ser confundidas. Un semáforo implementado como mecanismo IPC es una ampliación
del concepto de semáforo general que consiste en un conjunto de N semáforos (N = 1 , 2, 3, . . . ) sobre el
cual es posible realizar diferentes operaciones, ya sea sobre todos o algunos de sus elementos.
Para gestionar los conjuntos de semáforos existentes el núcleo mantiene una tabla. Cada entrada de
esta tabla contiene, entre otros, los siguientes datos sobre un determinado conjunto de semáforos : creador,
propietario, llave, permisos de acceso, puntero al array de semáforos que forma parte del conjunto y
número N de semáforos que forman parte del conjunto.
El núcleo asocia a cada conj unto de semáforos un identificador numérico entero positivo s emid que
lo identifica de manera univoca y que le permite localizar rápidamente su entrada asociada en la tabla
que mantiene para soportar los semáforos.
Por cada semáforo j (j = O, . . . , N - 1 ) perteneciente al conjunto de semáforos s emid el núcleo
mantiene una estructura con los siguientes datos: el valor actual del semáforo, que es un número entero
positivo o cero, el número de procesos esperando a que el semáforo valga cero, el número de procesos
esperando a que el semáforo se incremente y el PID del proceso que hizo la última operación sobre el
semáforo. También mantiene una cola de procesos dormidos en el semáforo.
El núcleo soporta las siguientes llamadas al sistema asociadas con los semáforos :
•
s emi d= s emge t ( l l ave , N , i nd ) . Esta llamada a l sistema permite crear u n conjunto d e semá­
foros u obtener el uso de un conjunto ya creado. Requiere como argumentos de entrada la llave
numérica ( l l ave) que se quiere asociar al conjunto de semáforos o que ya tiene asociada (si ya
está creado), el número N de semáforos que tendrá el conjunto y una serie de indicadores ( i nd)
que permiten especificar, entre otras cosas, los permisos de acceso al conjunto de semáforos. Un
indicador utilizado frecuentemente es I PC_CREAT que fuerza a crear un conjunto nuevo si no
existe uno ya creado. Si la llamada al sistema se ejecuta con éxito entonces guarda en s emid el
identificador del conjunto de semáforos. En caso contrario almacena en s emid el valor -l.
•
r = s emop ( s emi d , oper , M ) . Esta llamada al sistema permite realizar operaciones sobre los semá­
foros de un determinado conjunto de semáforos. Requiere como argumentos de entrada el identifi­
cador s emid del conjunto de semáforos, un puntero oper a un array de estructuras de tipo s embu f
y el número de elementos M de dicho array.
Una estructura s embu f contiene la siguiente información:
- El identificador j (j = O, . . . , N - 1 ) del semáforo del conjunto s emid sobre el que se quiere
realizar la operación.
SOBUNIX: planificación, sincronización y mecanismos IPC
121
El tipo de operación s em_op que se quiere realizar sobre el semáforo j del conjunto s emid.
Si s em_op es un entero positivo mayor que cero entonces se añade s em_op al valor del
semáforo y se despiertan a los procesos que estaban dormidos en espera de que el valor del
semáforo se incrementase.
Si s em_op es un entero negativo entonces se comprueba si el valor del semáforo es mayor
o igual que el valor absoluto de s em_op. En caso afirmativo se resta s em_op del valor del
semáforo. En caso negativo el proceso entra en el estado dormido en espera de que se cumpla
la condición.
Si s em_op es igual a cero se comprueba si el valor del semáforo es igual O. En caso afirmativo
no se realiza ninguna modificación sobre el valor del semáforo. En caso contrario el proceso
entra en el estado dormido en espera de que se cumpla la condición.
Indicadores. El indicador I PC_NOWAIT establece que en caso de que no se pueda realizar la
operación correspondiente no se bloquee el proceso y se devuelva un mensaje de error. Por
defecto todas las operaciones son bloqueantes. Por su parte el indicador S EM_UNDO indica al
núcleo que la operación debe ser deshecha cuando el proceso termine. Esta opción permite
evitar que un semáforo quede permanente bloqueado por un proceso que finalice antes de
poder liberar el recurso. El núcleo mantiene por cada semáforo una lista con las operaciones
que tienen que ser deshechas.
Cada operación sobre un semáforo j definida en una estructura s embu f es realizada de forma
atómica por el núcleo. De esta forma, hasta que una operación no se completa no se puede realizar
otra.
Si la llamada al sistema s emop se ejecuta con éxito entonces en r se almacena el valor O . En caso
de error se almacena - l .
•
r = s emc t l ( s emi d , j , o rden , arg ) . Esta llamada permite leer y configurar los datos de control
que el núcleo mantiene en la entrada asociada a un determinado conjunto de semáforos en la tabla
de semáforos. También permite leer y configurar los valores de todos o alguno de los semáforos de
un determinado conjunto. Esta llamada requiere como parámetros de entrada el identificador del
conjunto de semáforos s emi d, el identificador j de un semáforo del conjunto, un número entero
o constante simbólica orden que especifica la operación que se quiere realizar sobre los datos de
administración y control del semáforo, y los argumentos arg asociados a dicha operación. Algunos
de los posibles valores de orden son:
I PC_RMID. Especifica que el recurso IPC, en este caso el conjunto de semáforos s emid debe
ser eliminado. Además despierta a todos los procesos dormidos esperando en los semáforos
del conjunto.
SETALL . Configura el valor de todos los semáforos del conjunto s emid al valor especificado
en arg.
GETALL. Lee el valor de todos los semáforos del conjunto s emi d y los almacena en arg.
122
Ampliación de sistemas operativos
SETVAL. Configura el valor del semáforo j del conjunto s emid al valor especificado en arg.
GETVAL. Lee el valor del semáforo j del conjunto s emi d y lo almacena en r.
Si la llamada al sistema se ejecuta con éxito entonces en r se almacena O o un valor que depende
de o rden. En caso contrario en r se almacena - l .
# i n c lude < s td i o . h>
# i n c lude < sys / typ e s . h>
# i n c l ude < sys / ipc . h>
# i n c lude < sys / s em . h>
#de f ine CLAVE 3 4 2 1 L
1 * L l ave * 1
#de f i n e PERMI SOS 0 6 6 6
1 * L e c tura y e s c r i tura para t o d o s l o s usuar i o s
*1
s t ruc t s embu f decremen t a r [ 1 ] = { 0 , - 1 , 0 } ;
s t ruc t s embu f increment a r [ 1 ] = { 0 , 1 , 0 } ;
i n t s em i d ;
i n t r e s u l t ado ;
vo i d i n i t_s em ( i nt val )
1 * C r e a r u obtener un c o n j u n t o de s emá f o r o s de un s emá f o r o
I
( N= 1 )
*1
s em i d= s emge t ( CLAVE , 1 , I PC_CREAT PERM I S O S ) ;
if
( s em i d= = - 1 )
1 * C omprobar s i ha hab ido a l gún e r r o r * 1
p r i n t f ( " \ nErro r " ) ;
ex i t ( - 1 ) ;
1*
I n i c i a l i z a r e l s emá f o r o a 1
*1
r e s u l tado= s emc t l ( s emi d , O , S E TVAL , va l ) ;
vo i d wa i t_s em ( )
r e s u l tado = s emop ( s emi d , & d e c rementar [ 0 ] , 1 ) ;
vo i d s i gna l_s em ( )
r e s u l tado = s emop ( s em i d , & i n c r ementar [ 0 ] , 1 ) ;
Figura 3.10 - Código C del archivo de cabecera c omun . h del Ejemplo 3 . 1 0
SOBUNIX: planificación, sincronización y mecanismos IPC
# i nc lude
123
" c omun . h "
i n t ma i n ( }
int N= 2 ;
/ * Nume ro de p r o c e s o s hi j o s a c r e ar * /
i n i t_s em ( l } ;
wh i l e ( N> O }
{
N=N- 1 ;
i f ( fork ( } = = 0 }
{
p r i n t f ( " P I D= %d An t e s de l a r e g i ó n c r i t i c a \ n " , g e t p i d ( } } ;
wa i t_s em ( } ;
p r i n t f ( " P I D= %d Dentro de
la regi ón c r i t i c a \ n " , getp i d ( } } ;
s l e ep ( S } ;
p r i n t f ( " P I D= %d D e s p i e r t o y s a l go de l a reg i ón c r i t i c a \ n " , g e t p i d ( } } ;
s i gnal_s em ( } ;
exi t ( 0 } ;
re turn O ;
Figura 3 . 1 1 - Código C del programa prog3 1 del Ejemplo 3 . 1 0
e
Ejemplo 3.10
En la Figura 3 . 1 0 se muestra el código C de un archivo de cabecera c omun . h que hace uso de las lla­
madas al sistema s emg e t , s emop y s emc t l sobre un conjunto s emid que consta de un único semáforo
(N= 1 ) que se utiliza para implementar un semáforo binario (ver sección 3 . 3 .2) y sus operaciones básicas
ini t_s em, wa i t_s em y s i gna l_s em.
En la Figura 3 . 1 1 se muestra el código C del programa prog3 1 que utiliza el semáforo binario definido
en c omun . h para garantizar la exclusión mutua en el uso de una cierta región critica. S upóngase que se
invoca a prog3 1 desde la línea de órdenes de un intérprete de comandos y que éste crea al proceso A
para ejecutar este programa. El proceso A crea dos procesos hijos: B y C, y termina su ejecución. Se va
suponer que B tiene un PID=995 y que C tiene un PID=996.
Cuando se planifica para ejecución al proceso hij o B en primer lugar imprime en pantalla el mensaje
P I D= 9 9 5 Ant e s de la región c r i t i c a
E n segundo lugar invoca a la función wa i t_s em ( ) que decrementa en una unidad e l valor del semáforo.
Este semáforo estaba inicializado a 1 , tras la operación toma el valor O.
En tercer lugar imprime en pantalla el mensaje
124
Ampliación de sistemas operativos
P I D= 9 9 5 Dentro de l a regi ón c r i t i c a
e invoca a la llamada al sistema s l e ep ( 5 ) que suspende la ejecución del proceso B durante 5 segundos.
Mientras B está suspendido se ejecuta el proceso hijo C, que imprime en pantalla
P I D= 9 9 6 Ant e s de la reg i ón c r i t i c a
e invoca a la función wa i t_s em ( ) . Como el semáforo tiene el valor O el proceso C entra en el estado
dormido y es colocado en cola de procesos dormidos asociada al semáforo. Una vez transcurridos los
5 segundos se despierta al proceso B . Cuando se planifica para ejecución en primer lugar imprime en
pantalla
PID= 9 9 5 D e sp i e r t o
y
salgo de la r e g i ón c r i t i c a
E n segundo lugar invoca a l a función s i gnal_sem ( ) que despierta a l proceso C. Finalmente e l proceso
B invoca a la llamada al sistema exi t para terminar su ejecución.
Cuando C es planificado para ejecución imprime en pantalla el mensaje
P I D= 9 9 6 Dentro de l a regi ón c r i t i c a
e invoca a la llamada al sistema s l e ep ( 5 ) que suspende la ejecución del proceso C durante 5 segundos.
A continuación imprime en pantalla
PID= 9 9 6 D e sp i e r t o
y
s a l go de la r e g i ón c r i t i c a
Por último ejecuta l a operación s em_s i gna l ( ) que incrementa e n una unidad e l valor del semáforo,
ahora toma el valor 1 , e invoca a la llamada al sistema exi t para terminar su ejecución.
•
Colas de mensajes
Las colas de mensajes son buzones que posibilitan la realización de una comunicación indirecta
entre procesos mediante el paso de mensajes. Un proceso que adquiera el uso de una cola de mensajes
puede enviar (insertar) o recibir (extraer) mensajes de la cola. Por defecto, los mensajes son insertados y
extraídos por orden de llegada, es decir, usando un algoritmo PIFO. Aunque también es posible extraer
un mensaje determinado de una cola haciendo uso de un identificador entero positivo denominado tipo
del mensaje definido por el programador. Cada mensaje enviado o recibido por un proceso se implementa
como una estructura de datos que contiene el tipo de mensaje y el cuerpo del mensaje.
El tamaño máximo en bytes y el número máximo de mensajes de una cola de mensajes son paráme­
tros configurables por el superusuario.
Por defecto si un proceso envía un mensaje a una cola que está llena entra en el estado dormido en
espera de que el mensaje pueda ser enviado. Asimismo si un proceso desea recibir un mensaje de una
cola que está vacía entra en el estado dormido hasta que llegue el mensaje.
SOBUNIX: planificación, sincronización y mecanismos IPC
125
El núcleo implementa una cola de mensajes mediante una lista enlazada de mensajes que se almacena
en el espacio de direcciones del núcleo. Para gestionar las colas de mensajes existentes el núcleo mantiene
una tabla de colas de mensajes. Cada entrada de esta tabla contiene, entre otros, los siguientes datos sobre
una determinada cola: creador, propietario, llave, permisos de acceso, puntero al primer mensaje de la
cola, puntero al último mensaj e de la cola, número de bytes almacenados en la cola, tamaño máximo en
bytes que puede tener la cola y número de mensajes actualmente en la cola.
Además el núcleo tiene que mantener las colas de procesos dormidos en operaciones de envío o
recepción sobre una determinada cola de mensajes.
El núcleo asocia a cada cola de mensajes un identificador numérico entero positivo rnsgqi d que la
identifica de manera univoca y que le permite localizar rápidamente su entrada asociada en la tabla de
colas de mensajes.
Por cada mensaje en una cola el núcleo mantiene una estructura de datos con la siguiente informa­
ción: un puntero al siguiente mensaj e de la cola, el tipo del mensaje, el tamaño del cuerpo del mensaje y
la dirección de comienzo del cuerpo del mensaje.
El núcleo soporta las siguientes llamadas al sistema asociadas con las colas de mensajes:
•
rnsgqi d=rns gget ( l l ave , ind ) . Esta llamada al sistema permite crear una cola de mensajes nue­
va u obtener acceso a una cola de mensajes ya creada. Requiere como argumentos de entrada la
l l ave que se va asignar a la nueva cola o la llave de la cola ya creada, y una serie de indicadores
ind que permiten especificar, entre otras cosas, los permisos de acceso a la cola. Si la llamada se
ejecuta con éxito devuelve en rnsgqi d el identificador de la cola. En caso contrario devuelve - 1 .
•
r=rnsgsnd ( rns gqi d , rnen , t arn , ind ) . Esta llamada al sistema permite enviar un mensaje a una
determinada cola. Requiere como argumentos de entrada el identificador de la cola de mensajes
rnsgqi d, un puntero rnen al buffer que contiene el mensaje que se desea enviar, el tamaño t arn en
bytes del mensaje, y un indicador ind que permite especificar el comportamiento de la llamada.
Cuando un proceso invoca a la llamada rnsgsnd el núcleo comprueba si existe espacio en la cola
para poder enviar el mensaje. Si la cola está llena el núcleo bloquea al proceso hasta que exista
espacio en la cola y el mensaje pueda ser enviado. Para evitar el bloqueo del proceso se debe
especificar en ind el indicador I PC_NOWAIT. Si la llamada se ejecuta con éxito devuelve O en
caso contrario devuelve - l .
•
r=rnsgrcv ( rns gqi d , rnen , rnax , t ipornen , ind ) . Esta llamada al sistema permite recibir un men­
saje de una determinada cola. Requiere como argumentos de entrada el identificador de la cola
de mensajes rnsgqid, un puntero rnen al buffer donde se almacenará el mensaje que se desea re­
cibir, el número máximo rnax de bytes que serán almacenados del mensaje, el tipo del mensaje
t ipornen y un indicador ind que permite especificar el comportamiento de la llamada. Por defec­
to si la cola está vacía o no existe un mensaje del tipo especificado el núcleo bloquea al proceso
que invoca esta llamada. Para evitar el bloqueo del proceso se debe especificar en i nd el indicador
I PC_NOWAIT. Si la llamada se ejecuta con éxito devuelve el número de bytes escritos en el buffer,
en caso contrario devuelve - 1 .
Ampliación de sistemas operativos
126
El parámetro t ipomen de esta llamada permite seleccionar el mensaje que será extraído de la
cola de mensajes. Si t ipomen es mayor que cero se extrae el mensaje que lleva más tiempo en
la cola cuyo tipo sea igual a t ip omen. Si t ipomen es igual a cero se extrae el mensaje que lleva
más tiempo en la cola, es decir, el primer mensaje. Por último si t ipomen es menor que cero se
buscan aquellos mensajes cuyo tipo sea menor o igual al valor absoluto de t ipomen, de todos los
mensajes que cumplen esta condición se elige para ser extraído al mensaje que lleva más tiempo
en la cola cuyo tipo sea el más pequeño de todos.
•
r=msgc t l ( msgqi d , o rden , arg ) . Esta llamada permite leer y configurar los datos de control
que el núcleo mantiene en la entrada asociada a una determinada cola de mensajes en la tabla de
colas de mensajes. Requiere como argumentos de entrada el identificador de la cola de mensajes
msgqi d, un número entero o constante simbólica orden que especifica la operación que se quiere
realizar sobre los datos de administración y control de la cola, y los argumentos arg asociados a
dicha operación. Los posibles valores de o rden son:
I PC_RMID. Especifica que el recurso IPC debe ser eliminado. Además despierta a todos
los procesos dormidos esperando por una operación de envío o recepción en dicha cola de
mensajes.
I PC_STAT. Lee el contenido de la estructura de datos asociada al recurso IPC y lo almacena
en estructura apuntada en arg.
I PC_SET. Configura la estructura de datos asociada al recurso IPC con los valores almace­
nados en la estructura apuntada en arg.
Si la llamada al sistema se ejecuta con éxito entonces devuelve O. En caso contrario devuelve - l .
e
Ejemplo 3 . 1 1
En la Figura 3 . 1 2 se muestra el código del archivo de cabecera de f_c o l a . h donde se usa la llamada al
sistema msgget para crear una cola de mensajes con permisos de lectura y escritura para todos los usua­
rios. Se observa que la llave del recurso IPC es creada mediante la llamada al sistema f tok, que recibe
como argumentos la ruta de un archivo " a s d . txt " que debe estar previamente creado y un carácter K
'
'.
Por otra parte, en las Figuras 3 . 1 3 y 3 . 1 4 se muestra el código de los programas prog 3 2 y prog3 3 . El
programa prog3 2 crea u obtiene la cola de mensajes id invocando a la función obtener_c o l a ( ) y a
continuación envía un mensaje x de tipo 1 invocando a la llamada msgsnd.
Por su parte el programa prog3 3 invoca a obt ener_c o l a ( ) para acceder a la cola id y a continuación
invoca a la llamada msgrcv para solicitar la recepción del primer mensaje de tipo 1 que exista en la cola.
Si dicho mensaje existe se eliminará de la cola y se copiará en la estructura Y. Si no existe dicho mensaje
el proceso receptor se bloqueará hasta que llegue a la cola un mensaje del tipo especificado.
Cuando llegue el mensaj e se despertará al proceso receptor y cuando sea planificado para continuar su
ejecución mostrará en la pantalla el texto:
E s t e e s e l mens a j e 1
SOBUNIX: planificación, sincronización y mecanismos IPC
# i nc l ude < sys / ipc . h>
# i nc l ude < sys /msg . h>
int i d ;
key_t l l ave ;
obt ener_c o l a ( )
{
1 * Creac i ón l l ave * 1
l l ave= f t o k ( " a s d . tx t " , ' K ' ) ;
1 * Ob t enc i ón de una c o l a de mens a j e s
I
*1
i d=ms gge t ( l l ave , I PC_CREAT 0 6 6 6 ) ;
i f ( i d= = - 1 ) {
p r i n t f ( " Error al
obtener la c o l a de mens a j e s \ n " ) ;
ex i t ( 2 ) ;
Figura 3.12 - Código C del archivo de cabecera def_c o l a . h del Ejemplo 3 . 1 1
# i nc lude
" de f_c o l a . h "
ma in ( )
{
int r ;
1*
E s t ruc tura d e l mens a j e qu e s e va env i a r
*1
s t ruc t {
l ong t ipo ;
char cuerpo [ 5 0 ] ;
X;
1*
Tamaño en byt e s d e l cuerpo del men s a j e X * 1
i n t L = s i z e o f ( X ) - s i z e o f ( X . t ipo ) ;
1*
In i c i a l i z ac i ón de l men s a j e X * 1
X . t ip o = 1 ;
s t rcpy ( X . cuerp o , " E s t e
es
e l men s a j e 1 " ) ;
obtener_c o l a ( ) ;
1 * Enviar men s a j e a l a c o l a * 1
r=msgsnd ( i d , &X , L , O ) ;
i f ( r= = - 1 )
p r i n t f ( " Er r o r a l enviar e l men s a j e X " ) ;
Figura 3.13 - Código C del archivo del programa prog3 2 del Ejemplo 3 . 1 1
127
128
Ampliación de sistemas operativos
# i n c l ude
" de f_c o l a . h "
ma i n { )
{
int r ;
1 * E s t ru c tura del mens a j e que s e va r e c i b i r * 1
s t ruc t
{
l ong t ipo ;
char cuerpo [ 5 0 ] ;
Y;
1 * Tamaño en byt e s de l cuerp o del mens a j e Y * 1
i n t L = s i z e o f { Y ) - s i z e o f { Y . t i po ) ;
/ * I n i c i a l i z a c i ón de l men s a j e Y * /
s t rcpy { Y . cuerp o , " \ 0 " ) ;
obt ener_c o l a { ) ;
1 * Re c i b i r el pr imer men s a j e de t ipo 1 de l a c o l a * 1
r=msgrcv { i d , &Y , L , 1 , 0 ) ;
i f { r= = - 1 )
p r i n t f { " Error a l r e c i b i r mens a j e \ n " ) ;
el se
p r i n t f { " \ n %s \ n " , Y . cuerp o ) ;
Figura 3.14 - Código C del archivo del programa prog3 3 del Ejemplo 3 . 1 1
Señalar que la cola de mensajes i d sigue existiendo cuando finaliza la ejecución del proceso emisor y del
proceso receptor. Esto puede comprobarse invocando al comando ipc s . Para eliminarla se puede usar el
comando ipcrm. También se podría modificar los programas incluyendo al final la llamada al sistema
msgc t l ( i d , I PC_RMI D , O ) .
•
Memoria compartida
En los SOBUNIX un proceso no puede acceder al espacio de direcciones virtuales de otro proceso.
Cuando se crea un proceso hij o con la llamada al sistema f o rk, el hijo hereda una copia del espacio
de direcciones virtuales del padre. Los cambios que haga el hij o sobre su espacio de direcciones no
serán visualizados por el padre, y viceversa. Esta característica es un mecanismo de protección muy
eficiente. Sin embargo, en determinadas aplicaciones interesa que diferentes procesos tengan acceso a
una misma región de memoria compartida, de tal forma que los cambios que haga un proceso sobre los
datos almacenados en dicha región de memoria sean visibles al resto de procesos. Esta funcionalidad es
SOBUNIX: planificación, sincronización y mecanismos IPC
129
la que proporciona el mecanismo IPC del System V conocido como memoria compartida.
En definitiva una memoria compartida es una región de memoria que puede ser leída o escrita por
varios procesos. Para operar sobre una región de memoria compartida un proceso primero tiene que crear
la memoria u obtener acceso a la misma, si ya estaba creada, y a continuación adjuntarla a su espacio
de direcciones virtuales. Por otra parte, si un proceso ya no va acceder más a una región de memoria
compartida debe eliminarla de su espacio de direcciones virtuales.
Para gestionar las regiones de memoria compartida existentes el núcleo mantiene una tabla. Cada
entrada de esta tabla contiene, entre otros, los siguientes datos sobre una determinada región: creador,
propietario, llave, permisos de acceso, tamaño en bytes de la región, puntero a la estructura que permite
localizar la tabla de páginas asociada a la región y número de procesos que tienen adjuntada la región.
El núcleo asocia a cada región de memoria compartida un identificador numérico entero positivo
shmid que la identifica de manera univoca y que le permite localizar rápidamente su entrada asociada
en la tabla de memoria compartida.
El núcleo soporta las siguientes llamadas al sistema asociadas con las regiones de memoria compar­
tida:
•
shmid= shmge t ( l l ave , t amaño , ind ) . Esta llamada al sistema permite crear una nueva región
de memoria compartida u obtener acceso a una región de memoria compartida ya creada. Requiere
como argumentos de entrada la l l ave que se va asignar a la nueva región o la llave de la región ya
creada, el tamaño en bytes de la región y una serie de indicadores ind que permiten especificar,
entre otras cosas, los permisos de acceso a la región. Si la llamada se ejecuta con éxito devuelve el
identificador shm i d de la región de memoria compartida. En caso contrario devuelve - l .
•
r= shmat ( shmi d , d i r , ind ) . Esta llamada al sistema permite adjuntar una región de memoria
compartida en el espacio de direcciones virtuales del proceso invocante. Requiere como argumen­
tos de entrada: el identificador shmid de la región de memoria compartida, la dirección virtual
del espacio del proceso d i r a partir de la cual se desearía que la región de memoria compartida
fuese adjuntada, y una serie de indicadores i nd que permiten establecer el modo de acceso del
proceso a la región de memoria. Por ejemplo, el indicador SHM_RDONLY establece que la región de
memoria será accedida para solo lectura por el proceso. Si la llamada se ejecuta con éxito devuelve
un puntero a la dirección virtual de inicio Dirvo de la región de memoria compartida. En caso de
error devuelve el valor - l .
Cuando se utiliza esta llamada al sistema lo más cómodo para el programador es que el núcleo sea
el encargado de elegir la dirección Dirvo del espacio de direcciones virtuales del proceso a partir
de la cual se adjuntará la región de memoria compartida. Para ello el argumento d i r se debe fijar
a O. Por otra parte, si se fija d i r a un valor distinto de O, el núcleo intentará adjuntar la región
de memoria compartida a partir de la dirección d i r deseada pero debe tenerse en cuenta que no
siempre es posible.
Conviene señalar que para una determinada región de memoria compartida por varios procesos el
valor de Dirvo suele ser distinto en cada proceso.
Ampliación de sistemas operativos
130
e
•
r = shmdt ( D i rvo ) . Esta llamada al sistema desajunta una región de memoria compartida del espa­
cio de direcciones virtuales de un proceso. Requiere como único parámetro de entrada la dirección
virtual de inicio D i rvo de la región de memoria compartida. Si la llamada se ejecuta correctamente
devuelve O. En caso contrario devuelve - l .
•
r = s hmc t l ( shmi d , o rden , arg ) . Esta llamada permite leer y configurar los datos de control que
el núcleo mantiene sobre una región de memoria compartida. Su sintaxis es muy similar a la de las
llamadas s emc t l y ms gqc t l .
Ejemplo 3.12
Supóngase que se invoca al programa prog3 4 (ver Figura 3 . 1 5) desde la línea de órdenes de un intérprete
de comandos, y que éste crea al proceso A para ejecutar este programa.
El proceso A en primer lugar invoca a la función ini t_s em para inicializar con el valor O el semáforo
creado en c omun . h (ver Figura 3 . 1 0) . En segundo lugar invoca a la llamada al sistema shmg e t para
crear una región de memoria compartida y comprueba que la llamada se ha ejecutado correctamente. En
tercer lugar invoca a la llamada al sistema shma t para adjuntarla en su espacio de direcciones a partir de
la dirección contenida en el puntero contador. Además comprueba que la llamada se ha ejecutado sin
errores. En cuarto lugar almacena en la región compartida el valor O. En quinto lugar invoca a la llamada
al sistema f o r k para crear un proceso hijo B, el cual comparte el acceso a la región con su proceso padre.
En sexto lugar el proceso A invoca a la función wa i t_s em ( ) para esperar a que termine de ejecutarse
su hijo.
Cuando se ejecuta el proceso B , éste incrementa en una unidad el valor almacenado en la región compar­
tida, muestra en pantalla el texto
HIJO c ontado r = l
realiza una operación s i gnal_s em ( ) para desbloquear a s u proceso padre y termina s u ejecución.
Cuando el proceso A es despertado y planificado para ejecución muestra en pantalla el mensaje
PADRE c ontado r = l
invoca a l a llamada a l sistema shmdt para desajuntar la región compartida de s u espacio d e direcciones,
invoca a la llamada al sistema shmc t l para borrar el recurso IPC y finaliza. Nótese que si el proceso A
se planifica después que el proceso B entonces no se bloquea en el semáforo.
En la Figura 3 . 1 6 se muestra el código del programa prog3 5 similar a prog3 4 donde no existe una
región de memoria compartida. En dicho caso las modificaciones que hace el proceso B en su espacio de
direcciones no son visibles por el proceso A, con lo que la traza de ejecución de este programa es :
HIJO contado r = l
PADRE c ontador= O
•
SOBUNIX: planificación, sincronización y mecanismos IPC
# i nc lude
" c omun . h "
ma in ( ) {
int i d ;
i n t * C on t ador=NULL ;
i n i t_s em ( O ) ;
1 * Crear una r e g i ó n de memo r i a c ompar t i da * 1
I
i d= shmge t ( I PC_PRIVATE , s i z e o f ( i nt ) , I PC_CREAT 0 6 0 0 ) ;
if
( id== - 1 )
p r i n t f ( " Error a l c r ear l a r e g i ón de memo r i a c ompar t i da \ n " ) ;
ex i t ( 2 ) ;
1 * Adj untar
la reg i ón al
c ontador= ( i nt
if
e spac i o de d i r e c c i on e s v i r tua l e s del p ro c e s o * 1
* ) shma t ( i d , O , O ) ;
( c on t ado r = =NULL )
{
p r i n t f ( " Error a l l i gar la reg i ón de memo r i a \ n " ) ;
ex i t ( 2 ) ;
* C On t ador= O ;
i f ( f o rk ( ) = = O )
{
* C on t ador= * c on t a do r + l ;
p r i n t f ( " H IJO c ontado= %d\ n " , * C Ontado r ) ;
s i gnal_s em ( ) ;
exi t ( 0 ) ;
wa i t _ s em ( ) ;
p r i n t f ( " PADRE c on t ado= %d \ n " , * C On t ado r ) ;
1 * D e s a j un tar
la r e g i ó n de memo r i a c ompar t ida d e l e spac i o * 1
shmdt ( c ontador ) ;
1 * Borrar l a r e g i ó n de memo r i a c ompar t i da * 1
s hmc t l ( i d , I PC_RMI D , O ) ;
Figura 3.15 - Código C del archivo del programa prog3 4 del Ejemplo 3 . 1 2
131
132
Ampliación de sistemas operativos
# i nc lude
" c omun . h "
ma i n { ) {
i n t c ontador= O ;
i f { fork { ) = = 0 )
{
c ontador=c ontador+ l ;
p r i n t f { " H IJO c o n t ado= %d \ n " , contador ) ;
s i gnal_s em { ) ;
exi t { 0 ) ;
wa i t_s em { ) ;
p r i n t f { " PADRE c o n t ado= %d \ n " , c ontado r ) ;
Figura 3.16 - Código C del archivo del programa prog3 5 del Ejemplo 3 . 1 2
Ventajas e inconvenientes de los mecanismos IPC del System V
Los mecanismos IPC del System V poseen una gran versatilidad ya que pueden usarse para diferentes
funciones :
•
Los semáforos se pueden usar para garantizar la exclusión mutua en el uso de un recurso crítico o
para sincronización de procesos. Su principal inconveniente es que si no se colocan adecuadamente
en el código de la aplicación o se realiza una operación incorrecta pueden producir condiciones de
carrera e interbloqueos. En aplicaciones con un código largo y con decenas de semáforos, incurrir
en estas equivocaciones es relativamente fácil.
•
Las colas de mensajes se pueden usar para las mismas funciones que los semáforos y además para
el intercambio de pequeñas cantidades de datos. Su principal inconveniente es que la transferencia
de un mensaje requiere de dos copias en memoria lo que ralentiza la operación. En primer lugar
el mensaje enviado por un proceso emisor a una cola de mensajes es copiado desde el espacio de
direcciones del proceso en un buffer del núcleo. Posteriormente cuando el mensaje es extraído de
la cola se copia desde el buffer del núcleo al espacio de direcciones del proceso receptor.
Otro inconveniente de las colas de mensajes es que no es posible enviar un mensaje a varios
receptores, ya que cuando un receptor recibe un mensaje éste es extraído de la cola con lo que ya
no se encuentra disponible para otros receptores.
Otra forma más eficiente y versátil de implementar el paso de mensajes es mediante el uso de
STREAMS [Vahalia, 1 995] los cuales fueron desarrollados para soportar las comunicaciones en
redes de computadores, aunque pueden ser utilizados también para paso de mensajes entre proce­
sos ejecutándose en una misma máquina.
SOBUNIX: planificación, sincronización y mecanismos IPC
•
133
Las regiones de memoria compartida se pueden usar para el intercambio rápido de pequeñas o
grandes cantidades de datos. Su principal desventaja es que para evitar condiciones de carrera es
necesario utilizar algún mecanismo de sincronización, como por ejemplo semáforos o el paso de
mensajes.
Cada tipo x con x= { s em, msg, shrn} de mecanismos IPC dispone de una llamada al sistema xget
para crear o acceder a un recurso IPC del tipo x y de una llamada al sistema xc t l para leer o configurar
los datos de administración y control que el núcleo mantiene sobre un determinado recurso IPC del tipo
x. Estos datos también pueden ser visualizados en un intérprete de comandos usando el comando ipc s .
Una vez creado u n determinado recurso IPC del tipo x éste perdura incluso aunque todos los procesos
que lo estuvieran utilizando ya hubieran terminado. Esta característica en determinados escenarios puede
ser realmente útil. Sin embargo también puede suponer un desperdicio de memoria. Debe tenerse en
cuenta que el núcleo no implementa mecanismos para controlar si un determinado recurso IPC ya no va
a ser utilizado nunca más. Es responsabilidad del programador eliminar dicho recurso.
Un proceso perteneciente al usuario propietario, al usuario creador o al superusuario para eliminar
un recurso IPC del tipo x debe invocar a la llamada al sistema xc t l con el argumento I PC_RMID.
También se puede utilizar el comando ipcrm desde la línea de órdenes de un intérprete de comandos.
La eliminación del recurso IPC supone liberar el espacio ocupado por las estructuras de datos asociadas
al recurso y despertar a los procesos dormidos en el recurso.
Otro de los problemas que presentan los mecanismos IPC del System V es en relación con la segu­
ridad. Normalmente los recursos IPC son utilizados por aplicaciones que permiten el acceso a procesos
de diferentes usuarios, con lo que los permisos de acceso del recurso no suelen ser muy restrictivos.
En consecuencia un proceso no autorizado podría acceder al recurso si consigue adivinar la llave o el
identificador asociado al recurso.
3.5.2.
Otros mecanismos IPC
Señales
Las señales son un mecanismo muy útil de notificación de eventos (ver sección 2 . 3 . 3 ) que también
pueden usarse como mecanismo IPC para la sincronización de procesos. Por ejemplo, un proceso A
puede invocar a una llamada al sistema pau s e para suspender su ejecución mientras otro proceso B
realiza una determinada tarea. Cuando B haya finalizado la tarea invocará una llamada al sistema ki 1 1
para enviar una determinada señal al proceso A para que despierte y pueda continuar su ejecución.
El principal inconveniente de usar las señales como mecanismo IPC es el retardo que existe desde
que el emisor genera una señal hasta que es recibida por el receptor. Para enviar una señal el proceso
emisor debe ser planificado para ejecución e invocar la llamada al sistema adecuada, por ejemplo ki l l .
Posteriormente el núcleo debe interrumpir al proceso receptor, s i éste estaba ejecutándose, y manipular
su pila de usuario para poder ejecutar el manipulador de la señal cuando el proceso retorne a modo
usuario.
134
Ampliación de sistemas operativos
Thberías
Una tubería es un canal de comunicación unidireccional por el que se puede transmitir flujos de
datos no estructurados con un tamaño máximo fijo. Un proceso emisor puede enviar (escribir) datos por
un extremo de la tubería y un proceso receptor puede recibir (leer) los datos por el otro extremo. Los
datos son recibidos por orden de envío, es decir, siguiendo una organización de tipo FIFO. Una vez que
los datos son leídos de la tubería por un proceso receptor dej an de estar disponibles para ser leídos por
otros procesos receptores.
Si un proceso emisor intenta escribir en una tubería que está llena se bloquea hasta que exista espacio
en la tubería. Asimismo un proceso receptor que intente leer en una tubería que esté vacía se bloqueará
hasta que existan datos en la tubería.
Usadas como mecanismo IPC las tuberías resultan bastante eficientes aunque presentan los siguientes
inconvenientes [Vahalia, 1 995] :
•
No permiten el envío de información a varios receptores, ya que cuando se lee los datos de la
tubería estos son borrados de la misma.
•
Un proceso que escribe en la tubería no puede especificar que receptor debe leer los datos.
•
Si un proceso emisor transmite por la tubería varios mensajes de diferente longitud, como los
datos en la tubería son un flujo de bytes no estructurado, el proceso receptor no puede saber donde
termina un mensaje y donde empieza otro.
En los SOBUNIX las tuberías son gestionadas como los archivos (ver sección 5.2. 1 ), aunque no
requieren la realización de operaciones de E/S a disco, ya que los datos de la tubería no se mantienen en
memoria secundaria sino en la memoria principal. Cuando se crea una tubería el núcleo le asigna un par
de descriptores de archivos Do y D 1 • El descriptor Do se utiliza como argumento de la llamada al sistema
read para leer en la tubería. Mientras que D1 se utiliza como argumento de wr i te para escribir en la
tubería. Existen dos posibles tipos de tuberías:
•
Tuberías sin nombre. Se crean haciendo uso de la llamada al sistema r=pipe ( f i l d e s ) . Esta
llamada necesita como argumento de entrada la dirección de un array entero f i l d e s de dos ele­
mentos para almacenar los descriptores de archivos Do y D 1 • Si la llamada al sistema se ejecuta
con éxito devuelve O en caso contrario devuelve - 1 .
Los intérpretes de comandos utilizan estas tuberías para hacer que la salida de un programa sea la
entrada de otro programa (ver sección 1 .5 . 1 ) . Es el propio intérprete el que se encarga de manipular
los descriptores de archivos de la tubería devueltos por la llamada al sistema pipe para hacer que
un programa sea el emisor y otro el receptor.
Las tuberías sin nombre se caracterizan porque solo pueden ser utilizadas por procesos relacio­
nados genealógicamente. Además no son persistentes, es decir, son eliminadas al finalizar los
procesos que las utilizan.
La implementación de las tuberías sin nombre depende de cada SOBUNIX. Algunos SOBUNIX
las implementan usando las mismas estructuras de datos que utilizan para la gestión de archivos.
SOBUNIX: planificación, sincronización y mecanismos IPC
135
Otros SOBUNIX las implementan usando conectores (sockets) (ver sección 5 .6) o STREAMS
[Vahalia, 1 995 ] .
•
Tuberías con nombre, también denominadas archivos PIFOs o simplemente PIFOs. Se crean me­
diante la llamadas al sistema rnknod (ver sección 5 . 5 .2) o rnk f i f o , o desde un intérprete de co­
mandos usando los comandos homónimos.
Las tuberías con nombre se caracterizan porque se les puede asignar una ruta dentro del sistema
de archivos. Cualquier proceso aunque no sea hij o del proceso creador de la tubería puede acceder
a la tubería si conoce la ruta de la tubería y dispone de los permisos adecuados. Asimismo, los
tuberías con nombre son persistentes, es decir, continúan existiendo aunque todos los procesos
que lo estaban utilizando ya hayan terminado. Para eliminarlas se debe usar la llamada al sistema
unl ink o el comando homónimo.
3.6.
Resumen
El planificador es la parte del núcleo de un sistema operativo encargado de decidir qué procesos (o
hilos del núcleo) pasarán a ser ejecutados en los procesadores disponibles. Nótese que si el núcleo del
SOBUNIX considerado soporta hilos del núcleo entonces el planificador utiliza como unidad o entidad
planificable a los hilos del núcleo. En caso contrario utilizará como unidad planificable a los procesos.
En la mayoría de los SOBUNIX, el planificador implementa una planificación global basada en
múltiples colas de prioridad y realimentación. En este tipo de planificación, cada unidad planificable
tiene asignada una determinada prioridad que es un número entero positivo comprendido entre O y un
cierto valor máximo. En algunos SOBUNIX la prioridad más alta se asocia con el valor O de prioridad,
mientras que en otros se toma j ustamente el criterio contrario. El planificador siempre intenta que se
ejecute la unidad planificable de mayor prioridad, aunque esto no siempre es posible si el núcleo es no
expropiable .
El código del núcleo de los SOBUNIX es reentrante esta característica posibilita el que varias uni­
dades planificables (procesos o hilos del núcleo) ejecutándose en modo núcleo puedan estar ejecutando
concurrentemente la misma región de código del núcleo. Obviamente en el código del núcleo existen
secciones críticas asociadas a diferentes recursos críticos, como por ejemplo las estructuras de datos del
núcleo. Para garantizar la exclusión mutua en la ejecución de una sección crítica del núcleo asociada a un
cierto recurso crítico, el núcleo utiliza diferentes mecanismos de sincronización, entre los más utilizados
se encuentran los cerrojos y los semáforos.
Por otra parte, los SOBUNIX ponen a disposición de los programadores de aplicaciones diferentes
mecanismos para garantizar la exclusión mutua en el uso de recursos críticos, sincronizar su ejecución,
esperar por la aparición de algún evento o intercambiar información. A este conjunto de mecanismos
se les conoce de forma general como mecanismos de comunicación entre procesos, o más abreviada­
mente como mecanismos IPC. Es el programador de aplicaciones el que decide qué mecanismos IPC
utilizar y dónde utilizarlos dentro del código de sus aplicaciones. El uso de estos mecanismos requiere
la invocación de las llamadas al sistema oportunas. El núcleo se encarga de atender dichas llamadas al
136
Ampliación de sistemas operativos
sistema y mantener las estructuras de datos necesarios para soportar estos mecanismos IPC . Entre los
mecanismos IPC soportados en la mayoría de SOBUNIX se encuentran los mecanismos IPC del System
V (semáforos, colas de mensajes y memoria compartida), las señales y las tuberías.
3. 7.
Lecturas recomendadas
Si se desea obtener una explicación adicional de los contenidos tratados en este capítulo se pueden
consultar, por ejemplo: los capítulos 5, 6 y 7 de [Vahalia, 1 995] , los capítulos 9 y 1 0 de [Márquez, 2004],
los capítulos 3 , 4 y 1 7 de [McDougall y Mauro, 2006] y el capítulo 1 0 de [Tanenbaum, 2009] .
3.8.
Autoevaluación
3.1. Explicar razonadamente las características generales de la planificación de procesos multihilos en
SOBUNIX. (Respuesta en sección 3 .2. 1 )
3.2. ¿Qué especificaciones tiene asociada cada clase de planificación? ¿Qué dos tipos de funciones
utiliza el planificador para manipular las clases de planificación? (Respuesta en sección 3 .2. 1 )
3.3. ¿Qué llamadas al sistema s e encuentran disponibles en algunos SOBUNIX para controlar la prio­
ridad de un proceso? (Respuesta en sección 3 .2. 1 )
3.4. Explicar razonadamente l a planificación usada en B S D 4 . 3 . (Respuesta en sección 3 .2.2)
3.5. Explicar razonadamente la planificación usada en Solaris. (Respuesta en sección 3 . 2.2)
3.6. Dibujar un diagrama con la distribución de las prioridades de ejecución usadas en Solaris en fun­
ción del tipo de clases de planificación y las interrupciones. (Respuesta en sección 3 .2.2)
3.7. ¿Qué información se mantiene en una tabla de despacho de Solaris? (Respuesta en sección 3 .2.2)
3.8. ¿Qué información permite visualizar el comando di spadm i n en Solaris? ¿ Y pr i o cn t l ?
(Respuesta en sección 3 . 2.2)
3.9. ¿Qué es la prioridad en modo usuario en Solaris? ¿De qué componentes consta?
(Respuesta en sección 3 .2.2)
3.10. ¿Cómo se puede configurar la prioridad de usuario en Solaris ? (Respuesta en sección 3 .2.2)
3. 1 1 . ¿En Solaris qué eventos producen que se modifique la prioridad (global y en modo usuario)?
(Respuesta en sección 3 . 2.2)
3. 12. ¿Qué operaciones realizadas periódicamente por las funciones dependientes de las clases de pla­
nificación pueden cambiar las prioridades de los hilos en S olaris? (Respuesta en sección 3 .2.2)
SOBUNIX: planificación, sincronización y mecanismos IPC
137
3.13. Defina los siguientes conceptos : núcleo no expropiable, núcleo expropiable y puntos de expropia­
ción. (Respuesta en sección 3 .2.3)
3. 14. ¿Por qué es necesaria la existencia de mecanismos de sincronización en el núcleo de un SOBU­
NIX? ¿Cuáles son los mecanismos de sincronización más utilizados? (Respuesta en sección 3 . 3 )
3. 15. Explicar qué es un cerrojo y qué operaciones básicas soporta. (Respuesta e n sección 3 . 3 . 1 )
3. 16. Explicar qué es un spinlock, u n cerrojo con bloqueo, un cerrojo adaptativo, un cerrojo mutex y un
cerrojo R/W. (Respuesta en sección 3 . 3 . 1 )
3. 17. Explicar cuándo se realizan las operaciones de dormir y despertar un hilo y en qué consisten.
(Respuesta en sección 3 .4)
3.18. ¿Qué es un canal de espera? ¿Cómo se le asocia una cola de hilos dormidos ? ¿Qué problemas
presenta dicha asociación? (Respuesta en sección 3 .4)
3.19. ¿Qué es un turnstile? ¿Cómo gestiona el núcleo de Solaris los turnstiles? (Respuesta en sección 3 .4)
3.20. Enumerar los principales mecanismos IPC disponibles en los SOBUNIX. (Respuesta en sección 3 . 5 )
3.21. ¿Qué estructuras mantiene el núcleo para soportar los mecanismos IPC del System V? ¿Qué infor­
mación contiene dichas estructuras por cada recurso IPC? (Respuesta en sección 3 . 5 . 1 )
3.22. ¿Para qué utiliza el núcleo el identificador numérico de un recurso IPC? ¿Cuándo se l o asigna?
(Respuesta en sección 3 . 5 . 1 )
3.23. Explicar la implementación de los semáforos como mecanismos IPC del System V.
(Respuesta en sección 3 . 5 . 1 )
3.24. Explicar la utilidad y l a sintaxis de las siguientes llamadas al sistema: s emg e t , s emop y s emc t l .
(Respuesta en sección 3 . 5 . 1 )
3.25. Explicar la gestión e implementación de las colas de mensajes. (Respuesta en sección 3 . 5 . 1 )
3.26. Explicar la utilidad y l a sintaxis de las siguientes llamadas al sistema: msgge t , msgsnd, msgrcv
y msgc t l . (Respuesta en sección 3 . 5 . 1 )
3.27. Explicar qué e s y cómo s e gestiona una región d e memoria compartida. (Respuesta e n sección 3 .5 . 1 )
3.28. Explicar l a utilidad y l a sintaxis de las siguientes llamadas al sistema: shmg e t , s hma t , shmdt y
shmc t l . (Respuesta en sección 3 . 5 . 1 )
3.29. Explicar razonadamente las ventajas y los inconvenientes de los mecanismos IPC del System V.
(Respuesta en sección 3 . 5 . 1 )
138
Ampliación de sistemas operativos
3.30. ¿Cuál es el principal inconveniente de usar las señales como mecanismo IPC?
(Respuesta en sección 3 . 5 .2)
3.31. Explicar qué es y cómo funciona una tubería. (Respuesta en sección 3 . 5 .2)
3.32. Explicar los principales inconvenientes que presenta el uso de las tuberías como mecanismo IPC.
(Respuesta en sección 3 . 5 .2)
3.33. Explicar cómo gestiona el núcleo las tuberías. (Respuesta en sección 3 . 5 .2)
3.34. Explicar cómo se crean y las principales características de las tuberías sin nombre y de los archivos
PIFOs. (Respuesta en sección 3 . 5 .2)
3.9.
Ejercicios
3.1. En un sistema BSD 4.3 las 32 colas de procesos preparados se gestionan con una algoritmo de turno
rotatorio con un cuanto de 1 00 ms ¿Qué valor toma el cuanto en el caso de las colas asociadas al
rango de prioridades [0, 49] ? ¿Por qué? ¿De forma efectiva qué algoritmo se estaría aplicando
realmente en dichas colas?
3.2. En un sistema BSD 4.3 se han creado en el instante t = O ms tres procesos A, B y C de forma
prácticamente simultánea. Los procesos han sido colocados en la misma cola de procesos en el
estado preparado para ejecución en el siguiente orden: primero A, luego B y después C. Los tres
procesos tienen una prioridad inicial en modo usuario igual a 90 y un factor de amabilidad igual
20. Determinar cómo evoluciona el valor de la prioridad en modo usuario para cada proceso en el
intervalo de tiempo [0, 1 000] ms. Suponer que el tic de reloj se produce cada 1 0 ms, un cuanto
de 1 00 ms, que la prioridad en modo usuario base es igual a 50, y que el factor de decadencia
es constante e igual a 0,5 . Además se debe suponer que el tiempo de ejecución del manipulador
de la interrupción de reloj , la rutina roundrob i n ( ) , la rutina s chedcpu ( ) y el tiempo de un
cambio de contexto es despreciable. Suponer también que los tres procesos durante su ejecución
no invocan a ninguna llamada al sistema y que no existe en el sistema ningún otro proceso de
mayor prioridad en el estado preparado para ejecución.
3.3. En la Tabla 3 . 1 se muestra la tabla de despacho de la clase TS del planificador de un sistema
SVR4, en el cual se basa el planificador de Solaris. Supuesto un proceso con t s_cpupr i = 1 y
t s_upr i = 1 4 determinar el valor que se le asigna a t s_cpup r i y a t s_umdpri en los siguientes
casos: a) Expira el cuanto asignado al proceso. b) El proceso ha estado esperando para poder con­
sumir su cuanto más de 5 segundos. e) El proceso retorna a modo usuario tras haberse bloqueado
en espera de un evento durante la realización de una llamada al sistema.
3.4. En la Figura 3 . 1 7 se muestra el código C del programa j l O . Supóngase que en el directorio de
trabaj o actual residen los archivos wert . txt y j 1 0 , y que el archivo wert . txt puede ser leído
por cualquier usuario.
SOBUNIX: planificación, sincronización y mecanismos IPC
139
a) Explicar razonadamente el funcionamiento de j 1 o si se invoca desde el intérprete de coman­
dos mediante la orden: j 1 o
b) Comprobar que la respuesta dada en el apartado anterior es correcta compilando y ejecutando
este programa en un SOBUNIX.
3.5. En la Figura 3 . 1 8 se muestra el código C del programa s 1 0 .
a) Explicar razonadamente el funcionamiento de s 1 0 si se invoca desde el intérprete de coman­
dos mediante la orden: s l O s i s t emas_opera t i vo s_2
b) Comprobar que la respuesta dada en el apartado anterior es correcta compilando y ejecutando
este programa en un SOBUNIX.
3.6. En la Figura 3 . 1 9 se muestra el código C de los programas j O S a y j 0 8b.
a) Explicar razonadamente el funcionamiento de estos programas si un usuario, que dispone de
los permisos adecuados, escribe primero en un intérprete de comandos la orden j O Ba & y al
cabo de 1 0 segundos la orden j o Bb.
b) Comprobar que la respuesta dada en el apartado anterior es correcta compilando y ejecutando
estos programas en un SOBUNIX.
ts_quantum
1 00
1 00
. .
80
...
20
...
10
.
ts_tqexp
o
o
...
7
...
30
...
49
ts_slpret
10
11
...
25
...
50
...
59
ts_maxwait
5
5
...
5
...
5
...
5
ts_lwait
10
11
...
25
...
50
...
59
PRIORITY LEVEL
Tabla 3.1 - Tabla de despacho de la clase TS del Ejercicio 3.3
o
1
...
15
...
40
.
. .
59
Ampliación de sistemas operativos
140
# i nc lude < s t dl ib . h>
# i nc lude < s td i o . h>
# i n c l ude < sys / ipc . h>
# i nc lude < sys / s em . h>
ma i n ( )
{
int x , u ;
key_t y ;
s t ruc t s embu f z [ 2 ] ;
z [ O ] . s em_ f l g= O ;
z [ 1 ] . s em_f l g= O ;
y= f t ok ( " we r t . tx t " , ' x ' ) ;
if
( y = = ( key_t ) - 1 )
p r in t f ( " mens a j e wert " ) ;
exi t ( 3 ) ;
I
x= s emge t ( y , 2 , I PC_CREAT 0 6 0 0 ) ;
u= s emc t l ( x , O , S ETALL , O ) ;
i f ( f o rk ( ) = = 0 )
{
z [ O ] . s em_num= O ; z [ O ] . s em_op = 1 ;
u = s emop ( x , z , 1 ) ;
z [ O ] . s em_num= 1 ; z [ O ] . s em_op= - 1 ;
u = s emop ( x , z , 1 ) ;
p r i n t f ( " \ nmens a j e a s d \ n " , u ) ;
el se
i f ( f o rk ( ) = = O )
{
s l e ep ( 2 ) ;
z [ O ] . s em_num= O ; z [ O ] . s em_op= - 1 ;
u = s emop ( x , z , 1 ) ;
p r i n t f ( " \ nmen s a j e f gh \ n " , u ) ;
z [ O ] . s em_num= 1 ; z [ O ] . s em_op= 1 ;
u = s emop ( x , z , 1 ) ;
Figura 3.17 - Código C del programa j 1 0 del Ejercicio 3 .4
SOBUNIX : planificación, sincronización y mecanismos IPC
# i nc lude < s td l i b . h>
# i nc lude < s t di o . h>
ma i n { i n t b ,
char * C [ ] )
{
int p f d [ 2 ] ;
int a ;
char bu f ;
if
{b == 2)
{
if
{ pipe { p f d )
== - 1 )
perror { " E l " ) ;
exi t { - 1 ) ;
a = f o rk { ) ;
if
{a == 0 )
close ( p fd [ l ] ) ;
wh i l e
{ read { p f d [ O ] , &bu f , l )
>
0)
{
wr i t e { l , &bu f , l ) ;
wr i t e { l ,
" \n " ,
1) ;
close { p fd [ O ] ) ;
els e
c l o s e { p fd [ O ] ) ;
wr i t e { p f d [ l ] ,
e
[ 1 ] , 10 ) ;
c l o s e { p fd [ l ] ) ;
p r i n t f { " \ nMen s a j e \ n " ) ;
exi t { - 2 ) ;
Figura 3.18 - Código C del programa s l O del Ejercicio 3 . 5
141
Ampliación de sistemas operativos
142
1 * C ó d i g o del programa j O S a
*1
# i nc lude < sys / s t a t . h>
# i n c l ude < f c n t l . h>
ma i n ( )
{
int r , h ;
char * b ;
b= ( char * )
ma l l o c ( 9 * s i z e o f ( char ) ) ;
f o r ( h = O ; h< 9 ; h+ + )
{
* ( b+ h ) = ' \ o ' ;
1
mknod ( " a s d " , S_I F I FO 0 6 6 6 , O ) ;
r = op en ( " a s d " , 0 6 6 6 ) ;
read ( r , b , 7 ) ;
p r i n t f ( " \ n %s \ n " , b ) ;
close ( r ) ;
unl ink ( " a s d " ) ;
1 * C ó d i g o de l programa j 0 8 b * 1
# i nc lude < sys / s t a t . h>
# i nc lude < f c n t l . h>
ma i n ( )
{
int r ;
char b [ ) = " Texto 1 " ;
r = op en ( " a s d " , 0 6 6 6 ) ;
wr i t e ( r , b , 8 ) ;
close ( r ) ;
Figura 3.19 - Código C de los programas j O S a
y
j 0 8b del Ejercicio 3 . 6
Capítulo 4
SOBUNIX: administración de memoria
Objetivos docentes
Los objetivos docentes de este capítulo son los siguientes:
•
Conocer cómo se realiza en los SOBUNIX la gestión del espacio de direcciones virtuales de un
proceso.
•
Saber cómo se realiza en los SOBUNIX el mapeo de archivos en la memoria virtual de un proceso.
•
Saber qué es y cómo se gestiona la memoria anónima en los SOBUNIX.
•
Conocer cómo se implementa la memoria compartida en los SOBUNIX.
•
Conocer las características más relevantes de la traducción de direcciones físicas a virtuales en los
SOBUNIX.
•
Saber cómo se realiza en los SOBUNIX la gestión de la memoria física.
•
Conocer cómo se gestiona el área de intercambio en los SOBUNIX.
•
Conocer las características más importantes de la gestión de la memoria perteneciente al núcleo en
los SOBUNIX.
•
Conocer las principales llamadas al sistema y los comandos disponibles en los SOBUNIX para el
control de la memoria virtual.
1 43
Ampliación de sistemas operativos
144
4. 1.
Introducción
El subsistema de administración de memoria es el componente del núcleo de un sistema operativo
encargado de administrar, en colaboración con el hardware, la memoria principal entre los restantes
subsistemas del núcleo y entre todos los procesos de usuario que se ejecutan en el computador. Para
realizar esta tarea se pueden usar diferentes técnicas de administración de memoria. En los SOBUNIX se
utiliza la técnica de paginación por demanda la cual posibilita la implementación de la memoria virtual.
El uso de la memoria virtual evita tener cargado en la memoria principal todo el espacio de direc­
ciones virtuales de un proceso. Solo se cargan las partes del espacio de direcciones virtuales del proceso
que se van referenciando durante su ejecución. Ello posibilita tener cargados parcialmente en memoria
principal un número mayor de procesos en el estado preparado, es decir, aumentar el grado de multipro­
gramación. Además el uso de la memoria virtual también permite ejecutar procesos cuyos espacios de
direcciones virtuales sean mayores que el tamaño de la memoria principal.
En la técnica de demanda de página la memoria física se divide en bloques de tamaño fijo Sp de­
nominados marcos de página. Además el espacio de direcciones virtuales de un proceso se divide en
bloques del mismo tamaño Sp denominados páginas. En un determinado instante de tiempo un marco de
página j puede estar libre u ocupado por una página i de un cierto proceso. Una página solo es cargada en
memoria cuando se produce un fallo de página, es decir, se referencia a una dirección virtual contenida
en una página i que no está cargada en ningún marco j de memoria principal. La página se construirá a
partir del archivo ejecutable ubicado en memoria secundaria o se cargará desde el área de intercambio
si tuvo que ser intercambiada fuera de memoria principal. Si cuando se produce un fallo de página no
existe espacio libre en memoria principal, se debe seleccionar alguna página k para ser reemplazada por
la página j. Si la página k fue modificada, antes de ser reemplazada deberá ser copiada en la memoria
secundaria.
La implementación de la memoria virtual mediante demanda de página requiere de ciertos requisitos
en el hardware del computador. En primer lugar el procesador debe soportar el reinicio de instrucciones
después de que la página cuya referencia produjo un fallo de página sea cargada en memoria principal.
Por otra parte se requiere de un componente hardware denominado unidad de gestión de memoria (Me­
mory Management Unit, MMU), que se encarga de realizar la traducción de una dirección virtual e una
dirección física. También el hardware suele suministrar mecanismos de protección de las páginas. Si se
intenta realizar un acceso no autorizado el hardware produce una excepción que debe ser atendida por el
núcleo.
La implementación de la memoria virtual mediante demanda de página requiere que el subsistema
de gestión de memoria realice, entre otras, las siguientes tareas :
•
Gestionar el espacio de direcciones virtuales de los procesos.
•
Crear y mantener los mapas de traducción de memoria virtual a memoria física, es decir, las tablas
de páginas.
•
Tratamiento de los fallos de página.
•
Reemplazamiento de páginas.
SOBUNIX: administración de memoria
145
•
Copia de las páginas modificadas a memoria secundaria.
•
Asignación de páginas de memoria principal a los subsistemas del núcleo y a los procesos.
•
Control del número de procesos cargados en memoria principal, es decir, del grado de multipro­
gramación.
Este capitulo está dedicado a describir la administración de memoria en los S OBUNIX. En primer
lugar se estudia la gestión del espacio de direcciones virtuales de un proceso. En segundo lugar se analiza
la traducción de direcciones virtuales a direcciones físicas. En tercer lugar se describe la gestión de la
memoria física. En cuarto lugar se estudia la gestión del área de intercambio. Finalmente se describe la
gestión de la memoria perteneciente al núcleo.
4.2.
Gestión del espacio de direcciones virtuales de un proceso en
SOBUNIX
4.2.1.
Organización del espacio de direcciones virtuales de un proceso
En el espacio de direcciones virtuales de un proceso se pueden distinguir diferentes regiones o seg­
mentos 1 , cada una de las cuales delimita un área contigua de memoria virtual :
•
Región de código, también denominada región de texto. En la mayoría de arquitecturas comien­
za en la primera dirección virtual del espacio de direcciones virtuales del proceso. Contiene las
instrucciones máquina del código del programa para cuya ejecución se ha creado el proceso. El
contenido y el tamaño de la región de código no varían durante la ejecución del proceso.
•
Región de datos. Se sitúa a continuación de la región de código. Contiene las constantes y variables
usadas en el programa. Esta región se divide en dos partes:
- Región de datos inicializados. Contiene aquellos datos que tienen asignado un valor inicial
de forma explicita.
- Región de datos no inicializados2 • Contiene aquellos datos que no han sido inicializados de
forma explicita. Estos datos por defecto se inicializan a cero.
•
Montículo (heap). El tamaño de la región de datos puede ser aumentado dinámicamente durante la
ejecución del proceso. Para ello se puede utilizar la función de librería ma l l o c que internamente
hace uso de las llamadas al sistema brk o sbrk. Al espacio extra añadido a la región de datos
con respecto a su tamaño inicial se le denomina montículo (heap). El sentido de crecimiento del
1 Aunque en la literatura reciben el mismo nombre, los segmentos o regi ones del espacio de direcciones virtuales de un
proceso no deben confundirse con los segmentos utilizados en la técnica de segmentación de memoria cada uno de los cuales
tiene un espacio de direcciones independiente.
2 A esta región también se le denomina en la literatura como región BSS (Block Started by Symbol, bloque inicializado con
símbolos).
146
Ampliación de sistemas operativos
montículo es establecido por cada SOBUNIX dependiendo del hardware. Para liberar un espacio
asignado en el montículo se utiliza la llamada al sistema f r e e .
•
Región de pila (stack) . E n esta región s e implementa la pila de usuario del proceso, o las pilas de
los hilos del proceso. Inicialmente contiene todas las variables del entorno del intérprete de co­
mandos desde el que fue invocado el programa. Además contiene la cadena de caracteres asociada
a la orden con que fue invocado el programa, es decir, el nombre del programa y sus argumentos
de entrada. Cada vez que se invoca a una función durante la ejecución del programa se añade un
marco lógico a la pila con toda la información necesaria para poder continuar con la ejecución del
programa cuando se termine de ejecutar dicha función. Cuando la región de pila crece por encima
del espacio inicialmente asignado se produce una excepción hardware que tiene que ser tratada por
el sistema operativo. El manipulador de esta excepción entre otras acciones aumenta el tamaño de
la pila en un rango de direcciones equivalente a una página. La localización de la pila y su sentido
de crecimiento son establecidos por cada SOBUNIX en función del hardware.
•
Región de librerías. Esta región contiene las diferentes librerías de funciones utilizadas por el pro­
grama. Estas librerías suelen ser compartidas por varios programas y son implementadas mediante
el mapeo en memoria de los archivos (ver sección 4.2.2) asociados a las librerías. En una librería
se distinguen dos partes : código y datos.
Otros posibles tipos de regiones que se pueden distinguir en el espacio de direcciones virtuales de un
proceso son las regiones de memoria compartida usadas como recurso IPC y los archivos mapeados en
memoria (ver sección 4.2.2). Precisamente las librerías son un ejemplo de este último tipo de regiones.
La distribución de las regiones y el tamaño máximo del espacio de direcciones virtuales de un proceso
son fijados por cada SOBUNIX en función del hardware.
e
Ejemplo 4.1
En la Figura 4. 1 se muestra la organización del espacio de direcciones virtuales que realiza Solaris
en diferentes arquitecturas. En la arquitectura SPARC V7 de 32 bits (ver Figura 4. 1 a) el espacio de
direcciones virtuales puede tener un tamaño máximo de 4 GiB : 3,5 GiB están disponibles para el espacio
de direcciones de un proceso y 5 1 2 MiB están reservados para el núcleo.
En la arquitectura Intel x86 de 3 2 bits (ver Figura 4. 1 b), de los 4 GiB disponibles de memoria virtual,
3,75 GiB pueden ser utilizados para el espacio de direcciones de un proceso y 256 MiB están reservados
para el núcleo.
En la arquitectura SPARC V9 de 3 2 bits (ver Figura 4. 1 c) existen espacios de direcciones independientes
para el núcleo y para los procesos. En esta arquitectura el tamaño máximo del espacio de direcciones
de un proceso es de 3 ,99 GiB ya que 4,078 MiB de las direcciones más altas están reservados para el
arranque.
•
SOBUNIX: administración de memoria
OxFFFFFFFF ,....----,
OxFFFFFFFF
Espacio del
núcleo (256 MiB)
Espacio del
núcleo (5 1 2 MiB)
OxEO O O O O O O
147
- � - - - - - - - - - - - -
-
.
OxFFFFF FFF
1
OxFFBEC O O O
1------1
1
Pila
1------l
1
Librerías
OxDFFFE O O O
OxFF 3 DC O O O
Pila
1
•
1
1
1
1
1
1
1
OxDF 7 F 9 0 0 0 1------l
t
Librerías
1
1
1
Montículo
Librerías
1
1
J
1-------;
Datos
1
1
t
Código
Montículo
1
1
1
Montículo
Ox 8 0 4 8 0 0 0
Pila
Datos
Código
OxO O O l O O O O
1
1
1
1
OxO O O O O O O O L - - - - - - - - - - - - - - - 1
(a)
1
1
1
1
1
1
1
1
1
1
1
•
Datos
'
1
1
Código
OxO O O l O O O O
1
Ox O O O O O O O O L - - - - - - - - - - - - - - - 1
(b)
OxO O O O O O O O
1
1
1
1
1
L - - - - - - - - - - - - - - -'
(e)
Espacio de direcciones virtuales de un proceso en Solaris con una arquitectura [McDougall
Mauro, 2006] : (a) SPARC V7 de 32 bits (sun4d), (b) Intel x86 de 32 bits y (e) SPARC V9 de 32 bits
(sun4u)
Figura 4.1
-
y
El tipo de acceso permitido al contenido apuntando por una determinada dirección virtual depende
de cada tipo de región. Al contenido de la región de código o de la parte de código de una librería solo se
puede acceder para realizar operaciones de lectura y ejecución, mientras que al resto de regiones se puede
acceder para realizar operaciones de lectura y escritura. Para obtener información sobre los permisos de
acceso, tamaño y dirección de inicio de las regiones en que se organiza el espacio de direcciones virtuales
de un proceso se puede utilizar el comando pmap.
Por otra parte, en la técnica de demanda de página el espacio de direcciones virtuales de un proceso
se divide en páginas del mismo tamaño Sp. Luego dependiendo del tamaño de una región y del tamaño
de página, una región podrá estar contenida en una o varias páginas. Además una página puede que tenga
contenido perteneciente a una o varias regiones.
Una página i de una región del espacio de direcciones virtuales de un proceso no pasa a existir
físicamente hasta que es referenciada por primera vez y se produce un fallo de página. Entonces al tratar
148
Ampliación de sistemas operativos
el fallo se le asignará un marco j de la memoria principal el cual debe ser inicializado adecuadamente
en función de la región a la que pertenezca la página i. Si la página i pertenece a la región de código o a
la parte inicializada de la región de datos entonces el marco j se inicializa a partir del archivo ejecutable
almacenado en la memoria secundaria asociado al proceso. Asimismo si la página i pertenece a la parte
no inicializada de la región datos, al montículo o la región de pila entonces el marco j se inicializa con
ceros. En el caso de que la página i pertenezca a una región de librería entonces el marco j se inicializa
a partir del archivo de la librería en memoria secundaria.
En el caso de las páginas de las regiones de código de un programa o de una librería como no pueden
ser modificadas solamente es necesario mantener una copia de dichas páginas en la memoria principal,
las cuales pueden ser compartidas por todos los procesos que hagan uso de dicho código.
En el caso de las páginas de las regiones de datos inicializados de un programa o de una librería se
aplica la técnica de copiar al escribir, que consiste en aplazar la copia en un marco k de una página i
cargada en un marco j hasta el momento en que un proceso vaya a realizar una operación de escritura
sobre dicha página. Es entonces cuando se crea una copia privada de la página i en el marco k sobre la
cual se realizan las modificaciones. Nótese que mientras que no son modificadas estás páginas pueden ser
compartidas por todos los procesos que hacen uso de ellas. De esta forma se consiguen ahorrar marcos
de página de memoria principal ya que se evita tener cargadas en memoria varias copias de las mismas
páginas.
4.2.2.
Mapeado de archivos en memoria
Como se estudiará en la sección 5 . 2 . 1 una operación de lectura o escritura a un determinado bloque
de datos de un archivo ubicada en memoria secundaria requiere por parte de un proceso A la invocación
de tres llamadas al sistema como máximo: la llamada al sistema open para abrir el archivo (si no estaba
abierto), la llamada al sistema l s e ek para posicionar el puntero de lectura/escritura asociado al archivo
en la posición adecuada (si no estaba ya correctamente posicionado) y la llamada al sistema read o
wr i t e para leer o escribir, respectivamente, el bloque de datos. En el caso de una operación de lectura,
en primer lugar hay que realizar una operación de E/ S a disco para leer el bloque en el disco y copiarlo
en un buffer de la caché de buffers del núcleo en memoria principal. Posteriormente el bloque es copiado
desde el buffer en el espacio de direcciones virtuales del proceso A .
Supuesto que e l bloque d e datos tiene e l tamaño d e una página d e memoria, en la memoria principal
existirían dos copias de la misma página, una asociada al buffer del núcleo y otra asociada al espacio del
proceso A. Si otro proceso B desea leer la misma página del archivo, tras realizar las llamadas al sistema
oportunas, la página será copiada en el espacio de direcciones del proceso B. Luego en la memoria
principal existirán tres copias de la misma página, una en la caché de buffers, otra en el espacio de
direcciones de A y otra en el espacio de direcciones de B .
Obviamente esta forma tradicional de acceder a un archivo genera u n desperdicio de memoria princi­
pal y resulta lenta ya que involucra la realización de varias llamadas al sistema. Una forma más eficiente
y rápida de acceder a un archivo consiste en mapearlo en memoria principal.
S OBUNIX : administración de memoria
149
3
Un archivo mapeado en memoria (memory-mapped file) es una región del espacio de direcciones
virtuales de un proceso en la que se establece una correspondencia byte a byte con parte o con la totalidad
de un archivo. Para establecer esta correspondencia el núcleo debe configurar las estructuras de datos que
mantiene para gestionar el espacio de direcciones de memoria virtual de un proceso (ver sección 4.2.3).
Una vez mapeado en memoria el acceso a un determinado byte del archivo puede ser realizado como
a cualquier otro contenido del espacio de direcciones virtuales, es decir, indicando la dirección vittual
oportuna. Se evita así tener que realizar llamadas al sistema.
Aparte del ahorro de memoria principal y de la rapidez de los accesos, otra de las ventajas de lo
archivos mapeados en memoria es que se pueden usar como mecanismo IPC ya que los cambios que
realice un proceso en el archivo mapeado son visibles por todos los procesos que mapeen dicho archivo
en sus espacios de direcciones.
El uso de archivos mapeados también presenta algunos inconvenientes. En primer lugar el tamaño
de los archivos que se pueden mapear por completo queda limitado por el tamaño del espacio de di­
recciones virtuales del proceso, el cual suele menor de 4 GiB en arquitecturas de 32 bits. Para archivos
que superan dicho tamaño, el archivo debe ser dividido en trozos cuyo mapeado debe irse alternando en
memoria principal. También el tamaño del espacio de direcciones virtuales limita el número de archivos
que pueden estar mapeados total o parcialmente simultáneamente en memoria.
Otro inconveniente está relacionado al uso del mapeo de archivos como mecanismos IPC ya que al
igual que sucedía con las regiones de memoria compartida es necesario utilizar algún mecanismo IPC
adicional (semáforos o cola de mensajes) para sincronizar el acceso de los diferentes procesos al archivo
mapeado.
El mapeo de archivos puede ser utilizado tanto por el núcleo como por los procesos. Algunos SO­
BUNIX como SVR4 y Solaris generalizan el mapeo de archivos para implementar todo el espacio de
direcciones virtuales, el cual se considera como una colección de objetos mapeados en memoria, siendo
los archivos uno de los posibles objetos.
En los SOBUNIX un proceso para mapear un archivo en memoria primero debe invocar a la llamada
al sistema open para abrir el archivo y así obtener su descriptor fd. A continuación debe invocar a la
llamada al sistema mmap, la cual presenta la siguiente sintaxis :
pdi rv=mmap ( di rvO , l on , pro t ,
ind , fd , ini c i o ) ;
Esta llamada tiene los siguientes argumentos de entrada:
•
dirvO es una recomendación para el núcleo sobre la dirección virtual de comienzo de la región
del espacio de direcciones del proceso donde se va a mapear el archivo. Lo más recomendable es
configurarlo a O para que sea el núcleo el que elij a la dirección que considere más oportuna.
•
l on es la longitud de la región en bytes. Si l on no es un múltiplo del tamaño de una página Sp
entonces se redondea el múltiplo mayor más próximo.
3 0tras traducciones para este término son
archivo proyectado en memoria y archivo de memoria mapeada.
150
Ampliación de sistemas operativos
•
prot permite establecer los permisos de acceso a la región. Se implementa como una combina­
ción de las siguientes constantes : PROT_READ (leer), PROT_WRITE (escribir) y PROT_EXECUTE
(ejecutar).
•
i nd es un conjunto de indicadores que permiten especificar las características del mapeado. Entre
los indicadores más frecuentemente utilizados se encuentran los siguientes:
- MAP_SHARED. Establece que el mapeado del archivo sea de tipo compartido, con lo que las
modificaciones que realice el proceso sobre el archivo pueden ser visualizadas por los proce­
sos que mapeen este archivo en sus espacios de direcciones. Además las modificaciones se
realizarán directamente sobre las páginas del archivo cargadas en memoria y cuando las pá­
ginas sean reemplazadas de la memoria se deberán actualizar los bloques de dato del archivo
en el disco.
- MAP_PRIVA TE. Establece que el mapeado del archivo sea de tipo privado, con lo que las
modificaciones que realice el proceso sobre el archivo no pueden ser visualizadas por los
procesos que mapeen este archivo en sus espacios de direcciones. Cuando un proceso intenta
escribir por primera vez sobre una determinada página del archivo mapeada como privada
recibe una copia privada de la página sobre la que se realizan las modificaciones. Es decir
se aplica la técnica de copiar al escribir. Dichas modificaciones, cuando la página sea re­
emplazada de memoria, no serán trasladadas a los bloques de datos del archivo en el disco.
Nótese que mientras que una página no sea escrita puede ser compartida para lectura por
varios procesos.
•
f d es el descriptor del archivo.
•
i ni c i o indica el byte del archivo a partir del cual se comenzará a mapear el archivo.
Esta llamada si se ejecuta con éxito devuelve en pdi rv la dirección virtual de comienzo de la región
y crea una correspondencia byte a byte entre el rango de bytes
[ in i c i o , ini c i o + l on - 1 ]
del archivo con descriptor f d y la región del proceso situada en el rango de direcciones virtuales
[ pdirv , pdirv+ l on - 1 ]
En caso de error devuelve - l .
Para eliminar el mapeo de u n archivo en el espacio de direcciones virtuales de un proceso se debe
invocar a la llamada al sistema r=munmap ( pd i rv , l on ) . Si se ejecuta con éxito devuelve O. En caso
de error devuelve - l .
e
Ejemplo 4.2
Considérense el archivo ejecutable prog4 1 cuyo código fuente en C se muestra en la Figura 4.2. Supón­
gase que prog4 1 es invocado desde la línea de órdenes de un intérprete de comandos y que el intérprete
S OBUNIX: administración de memoria
151
# i nc lude < f c n t l . h>
# i nc lude < s td i o . h>
# i nc lude <uni s t d . h>
# i nc lude < sys / mman . h>
ma i n ( )
{
int f d , L ;
c addr_t d ;
char bu f f er [ 2 0 ] ;
L = s i z e o f ( bu f f e r ) ;
f d = open ( " t ex t o l . tx t " , 0 6 6 6 ) ;
1 * C r e a r e l roap e o d e l arch ivo e n u n a reg i ón * 1
I
d=mmap ( NULL , L , PROT_WR I T E PROT_READ , MAP_S HARED , f d , ( o f f_t ) O ) ;
i f ( d= =MAP_FAI LED )
p r i n t f ( " \ nErro r \ n " ) ;
else {
close ( fd) ;
bu f f er [ O ] = * d ;
* d= ' S ' ;
print f (
/ * L e e r en la r e g i ón * /
/ * E s c r i b i r en la r e g i ón * /
•
\ nAn t e s= %e De spue s= %c \ n •
munmap ( d , L ) ;
,
bu f f er [ O ] , * d ) ;
1 * E l iminar el map e o de l archivo en l a r e g i ó n * 1
Figura 4.2 - Código C del programa prog4 1
crea un proceso A para ejecutar este programa. El proceso en primer lugar invoca a la función s i z e o f
para determina el tamaño e n bytes que ocupa l a variable bu f f e r . Puesto que esta variable e s una cadena
de 20 caracteres y supuesto que cada carácter requiere un 1 byte, entonces en la variable L se almacena
el valor 20. En segundo lugar se invoca a la llamada al sistema open para abrir el archivo text o l . txt
con permisos de lectura y escritura para todos los usuarios. Se va a suponer que este archivo contiene
únicamente la siguiente línea de texto:
E s t o e s un e j emp l o de u s o de mmap
En tercer lugar se invoca a la llamada al sistema mmap para solicitar la creación de una región de me­
moria virtual de tamaño L bytes con acceso de lectura (PROT_READ) y escritura (PROT_WRI TE) que sea
compartida (MAP_SHARED) en la que se van a mapear L bytes del archivo con descriptor fd comenzando
desde el inicio ( ( o f f_ t ) o ) del archivo. La dirección de comienzo de esta región será elegida por el
sistema operativo (NULL). Si la llamada al sistema se ejecuta con éxito entonces en d se almacenará la
dirección de inicio de la región virtual creada, la cual ocupa el rango de direcciones [ d , d+L - 1 ] . En esta
152
Ampliación de sistemas operativos
región se ha mapeado byte a byte los L primeros bytes del archivo con descriptor fd.
A continuación se comprueba si se ha producido algún error (MAP_FAILED ) durante la ejecución de la
llamada. En dicho caso se imprime en la pantalla el mensaje Error y el proceso termina su ejecución.
Si la llamada se ha ejecutado con éxito entonces se invoca a la llamada al sistema c l a s e para cerrar
el archivo. Posteriormente se lee el primer byte de la región en la que está mapeado el archivo, que
corresponde al carácter E y se almacena en la variable bu f f e r [ o l . Luego se escribe el carácter s en el
primer byte de la región en la que está mapeado el archivo.
Finalmente se invoca a la función p r i n t f que muestra en la pantalla el mensaje
An t e s = E De spué s = S
e invoca a l a llamada al sistema rnunmap para eliminar el mapeo del archivo del espacio de direcciones
del proceso.
Señalar que puesto el mapeado del archivo en la región se solicitó con la opción MAP_SHARED la modi­
ficación que ha realizado el proceso A sobre la región ha sido trasladada el archivo t ext o l . txt en el
disco. Esto se puede comprobar abriendo el archivo con un editor o a través de un intérprete de comandos
escribiendo la orden: more text o l . txt
•
4.2.3.
Estructuras de datos gestionadas por el núcleo asociadas al espacio de direcciones
virtuales de un proceso
El núcleo mantiene diferentes estructuras para gestionar el espacio de direcciones de un proceso.
El nombre y la información contenida en estas estructuras dependen de cada SOBUNIX. Generalmente
a cada región existente se le asocia una estructura El que contiene, entre otros, los siguientes datos
sobre una región: dirección virtual base, tamaño, permisos de acceso y un puntero a la tabla de páginas.
Además existe una estructura E2 que contiene información sobre el número de regiones existentes, su
tamaño total y la localización de las estructuras El asociadas a las regiones. En la entrada asociada al
proceso en la tabla de procesos se suele mantener un puntero a su estructura E2.
e
Ejemplo 4.3
La implementación del espacio de direcciones virtuales que realiza Solaris está basada en la arquitec­
tura de gestión de memoria virtual de SunOS 4.0, también denominada abreviadamente en la literatura
[Vahalia, 1 995] como arquitectura VM (Virtual Memory, memoria virtual). Debido a su eficiencia y
versatilidad la arquitectura VM ha sido adoptada por diversos SOBUNIX, como por ejemplo: SVR4 y
Solaris.
En la arquitectura VM se utiliza el término segmento para referirse a una región del espacio de direcciones
virtuales. Además se extiende el uso de los archivos mapeados para la construcción de todas las regiones
del espacio de direcciones virtuales tanto de un proceso como del núcleo.
Cada segmento mapea un determinado objeto de datos que puede estar asociado a: parte o la totalidad de
un archivo en el sistema de archivos, bloques de datos del área de intercambio, un buffer de un dispositivo,
SOBUNIX : administración de memoria
153
etc. Cada objeto de datos comprende un rango contiguo de bytes que puede ser accedido por el rango de
direcciones virtuales contiguas que comprende el segmento. Por otra parte cada objeto tiene asociado un
nodo-v. El tamaño de un objeto es siempre un múltiplo del tamaño de una página.
Un objeto de datos constituye la fuente a partir de la cual se inicializa el contenido de los marcos de
página asociados a las páginas virtuales de un segmento. Además es el almacenamiento de respaldo
persistente de las páginas de dicho segmento. La memoria principal actúa como una memoria caché de
las páginas de los objetos de datos. La primera vez que se referencie a una dirección virtual contenida en
una página i de un segmento se producirá un fallo de página. Al tratar el fallo se asignará a la página i un
marco j de la memoria principal el cual debe ser inicializado adecuadamente a partir del objeto de datos
al que está mapeado el segmento al que pertenece la página i.
Un objeto de datos especial es el objeto anónimo que se utiliza como fuente de páginas llenas de ceros,
las cuales se utilizan, por ejemplo, en la creación del montículo y la pila de un proceso. El objeto anónimo
se implementa como un puntero al nodo-v NULL o al nodo-v del archivo / dev / z er o .
En función del objeto mapeado y del espacio d e direcciones vittuales (usuario o núcleo) e n que s e mapea
se pueden distinguir diferentes tipos de segmentos. Entre los tipos de segmentos más frecuentemente
utilizados en Solaris se encuentran los siguientes :
•
s eg_vn. Segmento perteneciente al espacio de direcciones virtuales de un proceso de usuario que
se utiliza para mapear archivos regulares o el objeto anónimo. Todos los segmentos del espacio
de direcciones de un proceso de usuario son segmentos de este tipo. Los segmentos de código y
de datos inicializados se construyen mediante el mapeo del código y los datos inicializados del
archivo ejecutable correspondiente. La región de datos no inicializados, el montículo y la pila se
construyen mediante el mapeo del objeto anónimo.
•
s eg_map . Segmento petteneciente al espacio de direcciones virtuales del núcleo que se utiliza
para mapear archivos regulares. Las páginas de un segmento de este tipo se alojan en marcos
bloqueados de memoria principal. Este tipo de segmento se utiliza para implementar la caché de
páginas de archivos del núcleo.
•
s e g_kmen. Segmento perteneciente al espacio de direcciones del núcleo que se utiliza para mapear
archivos regulares o el objeto anónimo. Las páginas de un segmento de este tipo se alojan en
marcos bloqueados de memoria principal. Los segmento de código, datos, pila y montículo del
núcleo son segmentos de este tipo.
Sobre los segmentos de un mismo tipo se opera con un determinado driver del segmento que queda
definido por un conjunto de datos privados y rutinas.
En Solaris cada proceso tiene asignada por el núcleo una estructura proc donde se mantiene diferente
información relativa a un proceso. Entre la información contenida en proc existe un puntero p_a s a una
estructura as que contiene, entre otros, los siguientes datos:
•
a_s i z e . Tamaño en bytes del espacio de direcciones virtuales.
154
Ampliación de sistemas operativos
•
a_n s e g s . Número de segmentos que forman parte del espacio de direcciones virtuales del proceso.
•
a_s egtree. Puntero a una estructura que implementa un árbol AVL4 con todos los segmentos del
espacio.
•
a_hat . Puntero a una estructura hat (ver sección 4.3) con información sobre las tablas de páginas.
s t ru c t
seg
s t ruct
S -base
S-s i z e
S - as
S -t r e e
S -base
S -dat a
S- s i z e
Operaciones del driver
de los segmentos tipo
S - as
S -t r e e
s e g_vn
s _ops
r--
seg
s e gvn_map ( )
s _op s
r-
S -da t a
s e gvn_ f ree ( )
s e gvn_ f au l t ( )
!
1
s t ru c t
s t ru c t
s e gvn_da t a
s e gvn_dat a
Figura 4.3 - Estructuras de datos usadas en Solaris para describir un segmento de tipo s eg_vn
A su vez cada segmento tiene asociada una estructura s eg que contiene, entre otros, los siguientes datos
(ver Figura 4.3):
•
s_ba s e . Dirección virtual base de comienzo del segmento.
•
s_s i z e . Tamaño del segmento en bytes.
•
s_a s . Puntero a la estructura a s a la que pertenece.
•
s_t r e e . Punteros para construir el árbol AVL de segmentos del que forma parte.
•
s_op s . Puntero a las funciones del driver del segmento que definen las operaciones que pueden
realizarse sobre el segmento una vez creado.
•
s_da t a . Puntero a una estructura que contiene diferentes datos sobre el segmento. Estos datos
dependen del tipo de segmento y son utilizados por las funciones del driver del segmento.
En la Figura 4.4 se muestra a modo de resumen un diagrama con las estructuras de datos utilizadas en
Solaris para describir el espacio de direcciones virtuales de un proceso.
•
4Un árbol AVL es un tipo especial de árbol binario autobalanceable [Cormen et al. , 2009] inventado por los matemáticos
rusos Adelson-Velskii y Landis.
SOBUNIX: administración de memoria
155
s t ru c t proc
1
1
1
1
1
1
1
1
r-- 1-p_as
Librerías
1
1
1
1
1
1
1
1
1
1
t
1
1
1
1
1
1
1
1
1
1
s t ru c t s e g
-r-
Montículo
s -b a s e
s size
S
-
as
-
S-t r e e
s_op s
....
Datos
s t ru c t a s
J
a_s e g t r e e
a- s i z e
a_n s e g s
a hat
S - da t a
s t ru c t s e g
Código
1=
'---
s -ba s e
S- s i z e
S
Árbol AVL
-a s
S -t r e e
s_op s
s da t a
Figura 4.4 - Estructuras de datos usadas en Solaris para describir el espacio de direcciones virtuales de
un proceso
4.2.4.
Memoria anónima
Una página anónima es una página que antes de su creación no dispone de un almacenamiento
persistente de respaldo en memoria secundaria. Las páginas anónimas son utilizadas por ejemplo, en la
región de datos no inicializados, el montículo y la región de pila. También son utilizadas en las regiones
asociadas a archivos mapeados en memoria con el indicador MAP_PRIVA TE, este el caso por ejemplo de
la región de datos inicializados.
Una página anónima solo se crea cuando se accede por primera vez a ella durante una operación de
escritura. Es durante el tratamiento del fallo de página correspondiente cuando se le asigna un marco de
memoria principal, se inicializa el marco con ceros o con la copia del contenido de otra página, y se le
asigna espacio en el área de intercambio.
Cuando se intenta escribir por primera vez en una página del segmento de datos no inicializados,
el montículo o la pila se produce una excepción hardware que al ser tratada por el núcleo produce la
creación de una página anónima que es inicializada con ceros. A esta operación se le denomina llenar
Ampliación de sistemas operativos
156
con ceros por demanda (Zero-Fill-On-Demand, ZFOD).
Cuando se intenta escribir por primera vez en una página de un segmento asociado a una archivo
mapeado en memoria con el indicador MAP_PRIVATE se genera una excepción hardware que al ser
tratada por el núcleo produce la creación de una página anónima en la cual se copia el contenido de
la página que originó la excepción. A esta estrategia de copiar el contenido de una página únicamente
cuando la página se modifica se le denomina copiar al escribir. Esta estrategia permite evitar durante la
creación de un proceso hijo (ver sección 4.2.7) la duplicación de ciertos segmentos del proceso padre.
El duplicado de una página de un segmento se aplaza hasta que el proceso hijo desea escribir en ella. Es
en ese momento cuando se le asigna una página anónima en la que se carga una copia de la página del
proceso padre.
Al conjunto de páginas anónimas utilizadas por un proceso se le denomina memoria anónima del
proceso. La memoria anónima se asigna por regiones del espacio de direcciones virtuales mediante el
uso de diferentes estructuras de datos. El núcleo manipula estas estructuras mediante el uso de diferentes
funciones. El nombre y el contenido de las estructuras de datos que implementan la memoria anónima,
así como el nombre y la definición de las funciones del núcleo que operan sobre dicha memoria dependen
de cada SOBUNIX.
e
Ejemplo 4.4
En los SOBUNIX que utilizan la arquitectura VM de gestión de memoria, como por ejemplo Solaris,
una página anónima se crea la primera vez que se desea realizar una operación de escritura sobre una
dirección virtual contenida en una página perteneciente a:
•
Un segmento que ha sido construido con un mapeado de tipo MAP_PRIVATE a un archivo. Este es
el caso por ejemplo, del segmento de datos inicializados de un proceso.
•
Un segmento que ha sido construido con un mapeado al objeto anónimo. Este es el caso de los
segmentos de pila, montículo y datos no inicializados .
seg
Array de referencias
a estructuras anon
.-----li-s da t a
a non
anon_map
base
a non
s i ze
cont re f = l
s e gvn_dat a
Estructuras de datos usadas en Solaris para describir las páginas anónimas de segmento de
tipo s eg_vn
Figura 4.5
-
Para este tipo de segmentos la estructura s egvn_da t a (ver Figura 4.5), a la que apunta el campo s_da t a
d e la estructura s eg que implementa u n segmento, tiene u n puntero amp a una estructura anon_rnap que
S OBUNIX: administración de memoria
157
contiene la dirección de inicio ba s e y el tamaño s i z e de un array de referencias a estructuras anon.
En este array existe una entrada por cada página del segmento. Cada entrada contiene un puntero a una
estructura anon que representa a una página anónima. Esta estructura contiene información sobre la
localización de la página anónima en el área de intercambio (ver sección 4.5). Además contiene un con­
tador de referencias que se incrementa en una unidad cada vez que el segmento de un proceso referencia
a dicha página anónima.
Sobre la memoria anónima el núcleo trabaja usando un determinado conjunto de funciones que constitu­
yen la denominada como capa anónima, entre las funciones que forman parte de esta capa se encuentran
las siguientes [Vahalia, 1 995] :
•
anon_a l l o c . Esta función permite obtener una página anónima nueva.
•
anon_dup . Esta función duplica las referencias a un conjunto de páginas anónimas. Se utiliza
durante el tratamiento de la llamada al sistema f o rk para duplicar en el espacio del proceso hijo un
segmento del proceso padre que tiene páginas anónimas. El efecto de esta operación es incrementar
en una unidad el contador de referencias de las estructuras anon de cada página anónima del
segmento compartida por el padre y el hijo.
•
anon_ f r e e . Elimina las referencias a un conj unto de páginas anónimas. El efecto de esta ope­
ración es decrementar en una unidad el contador de referencias de las estructuras anon de cada
página privada del conjunto. Solamente cuando el contador alcanza el valor O se puede eliminar
dicha página anónima y dej ar la estructura anon desasignada.
•
anon_priva t e . Hace una copia privada de una página y le asigna una estructura anon.
•
anon_ z e r o . Crea una página llena de ceros y le asigna una estructura anon.
•
4.2.5.
Memoria compartida
Una región de memoria compartida es un mecanismo IPC que permite compartir datos entre distintos
procesos. Para que un proceso pueda acceder a dichos datos debe mapear la región dentro de su espacio de
direcciones virtuales. En la sección 3 .5 . 1 al describir los mecanismos IPC del System V se describieron
las llamadas al sistema que debe invocar un proceso para crear y poder usar una región de memoria
compartida. También se comentó que el núcleo mantiene una tabla con una entrada por cada mecanismo
IPC del tipo memoria compartida existente en el sistema. Aparte de esta tabla global el núcleo mantiene
diferentes estructuras de datos para implementar las regiones de memoria compartida. El nombre y el
contenido de estas estructuras dependen de cada SOBUNIX.
e
Ejemplo 4.5
En los SOBUNIX que usan la arquitectura VM de gestión de memoria, como Solaris , una región de
memoria compartida se implementa como un segmento de tipo s eg_vn mapeado al obj eto anónimo con
158
Ampliación de sistemas operativos
Proceso A
s e gvn_dat a
Proceso B
Array d e referencias
a estructuras anon
a non
cont
re f = l
anon_map
base
c o n t re f = 3
a non
s egvn_da t a
cont
re f = l
Tabla de recursos IPC
del tipo
memoria compartida
Figura 4.6 - Estructuras de datos usadas en Solaris para implementar u n recurso IPC del tipo memoria
compartida
un mapeo del tipo MAP_SHARED. La primera vez que se escribe en una página del segmento de memoria
compartido se crea una página anónima que tiene el área de intercambio como almacenamiento de res­
paldo persistente. La estructura anon_rnap asociada a este segmento contiene un contador de referencias
que indica el número de estructuras que le referencian.
En la Figura 4.6 se muestran, a modo de ejemplo, las estructuras de datos de un recurso IPC del tipo
memoria compartida que está siendo compartido por dos procesos A y B. Se observa que el contador
de referencias de la estructura anon_rnap contiene el valor 3, ya que son tres las estructuras de datos
que la referencian: la estructura s egvn_da t a del proceso A, la estructura s egvn_da t a del proceso B
y la entrada asociada al recurso de la tabla global de recursos IPC del tipo memoria compartida. Solo
cuando este contador de referencias alcance el valor O, el núcleo podrá eliminar las páginas anónimas
asociadas al segmento y desasignar las estructuras de datos. Nótese que aunque finalicen los procesos A
y B , las páginas anónimas del segmento de memoria compartida seguirán existiendo si no se ha invocado
explícitamente a la llamada al sistema shrnc t l con la orden I PC_RMID o se ejecuta el comando ipcrrn.
Solo en ese caso se desasignará la entrada asociada a este mecanismo IPC en la tabla global y el contador
de referencias de anon_rnap alcanzará el valor O.
Nótese también que el contador de referencia de la estructura anon de una página anónima perteneciente
a un recurso IPC del tipo memoria compartida contiene el valor l . Esto es así porque todos los proce­
sos que tienen mapeado en su espacio de direcciones este recurso IPC comparten la misma estructura
anon_rnap y el mismo array de referencias a estructuras anon. A diferencia de lo que ocurre cuando se
duplica un segmento, en cuyo caso el segmento original y el duplicado tienen cada uno su propia estruc­
tura anon_rnap y su propio array de referencias a estructuras anon. Como ambos arrays de referencias
SOBUNIX : administración de memoria
159
apuntan a las mismas páginas anónimas entonces el contador de referencias de las estructuras anon de
estas páginas contienen el valor 2.
•
4.2.6.
Operaciones sobre el espacio de direcciones virtuales de un proceso
Sobre el espacio de direcciones virtuales de un proceso el núcleo puede realizar diferentes operacio­
nes. Estas operaciones se pueden clasificar en dos grandes grupos :
•
Operaciones que afectan a todo e l espacio de direcciones de u n proceso. Como l a creación de
un nuevo espacio de direcciones, y la duplicación o eliminación de un espacio de direcciones ya
existente.
•
Operaciones que afectan a una región o segmento del espacio de direcciones de un proceso. Como
la creación de una nueva región, la eliminación de una región, la configuración y la comprobación
de los permisos de acceso a una región, etc.
Cada SOBUNIX define qué operaciones sobre el espacio de direcciones soporta y cómo las imple­
menta.
e
Ejemplo 4.6
En los SOBUNIX que utilizan la arquitectura VM de gestión de memoria, como por ejemplo Solaris,
hay definidas diferentes operaciones que trabaj an sobre la estructura as que representa el espacio de
direcciones virtuales de un proceso. Algunas de estas operaciones afectan a todo el espacio de direcciones
virtuales del proceso, como por ejemplo:
•
as_a l l o c . Crea un nuevo espacio de direcciones virtuales. Esta función se invoca durante el
tratamiento de las llamadas al sistema fork y exe c .
•
as_dup . Duplica u n espacio de direcciones . Esta función s e invoca durante el tratamiento d e la
llamada al sistema f o rk.
•
as_f r e e . Elimina un espacio de direcciones ya existente. Esta función se invoca durante el trata­
miento de la llamada al sistema exi t .
Otras operaciones trabaj an a nivel de segmento, como por ejemplo:
•
as_map . Crea un segmento en el espacio de direcciones, es decir, mapea un objeto en memoria.
•
as_unmap . Elimina un segmento del espacio de direcciones.
•
as_fau l t. Trata un fallo de página originado por una dirección virtual del espacio.
Las operaciones que trabajan con la estructura a s a nivel de segmento suelen invocar, en la mayoría de
los casos, a funciones del driver del segmento para realizar las operaciones correspondientes. Recuérdese
que cada tipo de segmento tiene asignado un driver de segmento determinado.
•
160
4.2. 7.
Ampliación de sistemas operativos
Creación del espacio de direcciones virtuales de un proceso
Una de las tareas principales que debe realizar el núcleo durante el tratamiento de fork es la creación
del espacio de direcciones virtuales del proceso hijo. La implementación de esta tarea depende de cada
SOBUNIX, aunque de forma general puede afirmarse que en los SOBUNIX modernos la creación del
espacio de direcciones virtuales del proceso hijo se realiza duplicando las estructuras de datos asociadas
al espacio de direcciones virtuales del proceso padre.
Por el contrario, las páginas del proceso padre no son inicialmente duplicadas en memoria durante el
tratamiento de f ork, ya que así se ahorra memoria principal y se disminuye la sobrecarga. Las páginas
asociadas a la región de código del proceso padre o las regiones de código de las librerías compartidas,
son de solo lectura, y pueden ser compartidas por el proceso padre y el proceso hijo. También son
compartidas las páginas de las regiones de memoria compartida y las regiones asociadas a archivos
mapeados del tipo MAP_SHARED.
Por otra parte, sobre las páginas asociadas a la región de datos, a la región de pila y a las regiones
asociadas a archivos mapeados del tipo MAP_PRIVATE se aplica la técnica de copiar al escribir, es decir,
la página es copiada en memoria únicamente cuando un proceso tiene que escribir por primera vez sobre
la página. De esta forma dicho proceso hijo dispone de una copia privada de la página sobre la que realiza
las modificaciones.
e
Ejemplo 4.7
En los SOBUNIX que implementan una arquitectura VM de gestión de memoria, como Solaris, la crea­
ción del espacio de direcciones virtuales de un proceso hijo durante el tratamiento de una llamada al
sistema f ork se realiza siguiendo los siguientes pasos [Vahalia, 1 995] :
l . Tras asignar e inicializar una estructura proc para el proceso hijo se invoca a la función as_dup .
Esta función en primer lugar invoca a la función as_a l l o c para asignar una nueva estructura a s
para el proceso hijo.
2. La función as_a l l o c recorre el árbol AVL de segmentos del proceso padre e invoca para cada
segmento a la función dup del driver de segmento correspondiente con el objetivo de duplicar el
segmento dentro de la estructura as del proceso hijo. Por ejemplo, para un segmento tipo s eg_vn
se invocaría a la función s egvn_dup .
3 . Una vez que todos los segmentos han sido duplicados, la función as_dup invoca a la función
hat_dup que duplica la estructura hat (ver sección 4.3) y las tablas de páginas del proceso padre .
•
SOBUNIX: administración de memoria
4.3.
Traducción de direcciones virtuales a direcciones físicas en
SOBUNIX
4.3.1.
Tablas de páginas y MMU
161
Una de las principales tareas que es necesario realizar en la implementación de la técnica de gestión
de memoria mediante demanda de página es la traducción de direcciones virtuales a direcciones físicas.
Para su realización se utilizan dos elementos:
•
Tabla de página. Una tabla de páginas es una estructura de datos que contiene una entrada por cada
página existente en un espacio de direcciones virtuales. El tamaño de una entrada suele ser de 32
bits o de 64 bits que se descomponen en diferentes campos. El número, orden, tamaño y contenido
de los campos viene determinado por la arquitectura del computador. Entre los campos presentes
habitualmente en una entrada de una tabla de páginas se encuentran los siguientes :
- Número de marco de página. Contiene e l número de marco j de memoria principal donde se
encuentra almacenada la página i
- Validez o presencia. Este campo consta de un único bit v que se activa si la página i está
cargada en el marco j. Si la página no pertenece actualmente al espacio de direcciones del
proceso o no está cargada en memoria principal este bit está desactivado.
- Bits de protección. Este campo en su forma más simple consta de un único bit que en función
de su valor indica si la página es de solo-lectura o de lectura-escritura.
- Referenciada. Este campo consta de un único bit r que se activa cuando la página i es referen­
ciada por una dirección virtual. Este bit suele ser consultado para decidir que página puede
ser reemplazada (ver sección 4.4.2).
- Modificada. Este campo consta de un único bit m que se activa cuando la página i es modi­
ficada en una operación de lectura. Su activación indica al núcleo que debe copiar la página
en memoria secundaria antes de reemplazarla.
Cuanto mayor sea el espacio de direcciones virtuales de un proceso mayor será el tamaño de su
tabla de páginas y más espacio de memoria principal consumirá. Para ahorrar memoria algunas
arquitecturas soportan el uso de tabla de páginas paginadas de dos o más niveles. También algunas
arquitecturas trabajan con tablas de páginas invertidas.
En un determinado instante de tiempo en la memoria del núcleo existen cargadas varias tablas de
página. Generalmente existe una única tabla de páginas para describir las páginas del espacio de
direcciones del núcleo y una o más tablas para describir las páginas del espacio de direcciones de
un proceso. En algunos S OBUNIX se asocian las tablas de páginas por regiones, existiendo una
tabla de páginas asociada a cada región.
•
MMU. Es un componente hardware que se encarga de realizar la traducción de una dirección
virtual en una dirección física. Para poder realizar la traducción, en un registro de la MMU se
Ampliación de sistemas operativos
162
carga la dirección física de comienzo de la tabla de páginas del proceso en ejecución. Además se
carga en el TLB de la MMU una copia de un conjunto de entradas de dicha tabla de páginas.
Cuando la MMU recibe del procesador una dirección virtual, la descompone en dos campos : número
de página i y desplazamiento, y comprueba si la entrada de la tabla de páginas asociada a la página i está
cargado en el TLB . Si no es así se produce un fallo de TLB que al ser tratado por el hardware, el núcleo,
o ambos en colaboración, hace que se cargue en una entrada del TLB la entrada de la tabla de páginas
que se estaba buscando.
Una vez encontrada la entrada del TLB que contiene una copia de la entrada de la tabla de páginas
asociada a la página i, la MMU comprueba el campo protección para verificar que no se está intentando
realizar una operación no permitida sobre la página. Si se intenta realizar un tipo de operación no auto­
rizada la MMU genera una excepción hardware denominada fallo de protección. Si no existe un fallo de
protección comprueba el bit de validez v y si está activado se accede al campo marco j de dicha entrada
en el TLB para construir junto con el campo desplazamiento la dirección física. Si el bit de validez está
Dirv
N° de página i
1 6 bits
1
. ..
1
Sin usar
}i
9
bits
IETPN3
1
9
. ..
1
bits
. ..
IETPN2
9
bits
9
IETPN 1
bits
. ..
IETPNO
1
1 2 bits
Desplazamiento
1
llicrn
Registro
CR3
�
IrFI
Marco l
Marco m
DirFo
! Marco
m
Tabla de
páginas
de nivel 3
w
1 Marco 1
1�
4
DirF 3
Tabla de
páginas
de nivel 2
! Marco k
Tabla de
páginas
de nivel 1
Marco k
w
1 Marcoj
Tabla de
páginas
de nivel O
Marco j
w
Págma
Figura 4.7 - Tablas de páginas paginadas de 4 niveles soportadas en la arquitectura x64 de AMO
1
S OBUNIX: administración de memoria
163
desactivado se produce una excepción denominada fallo de válidez que debe ser tratado por el núcleo.
La traducción de direcciones requiere la colaboración entre el subsistema de gestión de memoria
del núcleo y la MMU. El subsistema de gestión de memoria se encarga de asignar espacio, configurar y
actualizar las tablas de páginas. Además se encarga de cargar los registros y el TLB de la MMU cada vez
que se produce un cambio de contexto. También se encarga de atender las excepciones generadas por la
MMU.
Por su parte la MMU se encarga de comprobar la validez de los accesos, generar una excepción si el
acceso no es válido, traducir las direcciones virtuales a direcciones físicas, y activar los bits referenciada
o/y modificada.
Con el objetivo de ahorrar espacio de memoria principal los SOBUNIX suelen trabaj ar con tablas
de páginas paginadas, el número de niveles de paginación utilizados es fijado por cada SOBUNIX en
función de la arquitectura.
e
Ejemplo 4.8
Solaris cuando se ejecuta en la arquitectura x64 de AMO utiliza un tamaño de página de 4 KiB y tablas
de paginas paginadas de 4 niveles de paginación (ver Figura 4.7). Cuando un proceso es planificado para
ejecución la dirección física Dirpo de la tabla de paginas del nivel 3 del espacio de direcciones de dicho
proceso es cargada en el registro CR3 del computador. Cuando durante la ejecución de dicho proceso
se referencia a una determinada dirección virtual Dirv para traducirla a la dirección física Dirp a la que
hace referencia se realizan los siguientes pasos :
l . Se suma Dirpo con el valor del campo índice de la entrada de la tabla de páginas del nivel 3
(IETPN3) de la dirección virtual Dirv para obtener la dirección física Dirp¡ de la entrada de la
tabla de páginas de nivel 3 que almacena el número m del marco de página que contiene a la tabla
de páginas del nivel 2.
2. Se accede a Dirp¡ para leer dicho número de marco m y se suma a la dirección física base del
marco m el valor del campo IETPN2 de Dirv . Se obtiene así la dirección física Dirp2 de la entrada
de la tabla de páginas de nivel 2 que almacena el número l del marco de página que contiene a la
tabla de páginas del nivel l .
3 . Se accede a Dirp2 para leer dicho número de marco l y se suma a la dirección física base del marco
l el valor del campo IETPN l de Dirv . Se obtiene así la dirección física Dirp3 de la entrada de la
tabla de páginas de nivel 1 que almacena el número k del marco de página que contiene a la tabla
de páginas del nivel O.
4. Se accede a DirF3 para leer dicho número de marco k y se suma a la dirección física base del marco
k el valor del campo IETPNO de Dirv . Se obtiene así la dirección física Dirp4 de la entrada de la
tabla de páginas de nivel O que almacena el número j del marco de página que contiene a la página
i referenciada en Dirv .
5 . Se accede a Dirp4 para leer dicho número de marco j y se suma a la dirección física base del marco
164
Ampliación de sistemas operativos
j el valor del campo desplazamiento de Dirv . Se obtiene así la dirección física Dirp a la que hace
referencia Dirv .
Señalar que aunque la arquitectura x64 de AMD soporta direcciones virtuales de 64 bits, realmente los
16 bits más significativos de una dirección virtual de 64 bits no se utilizan y por ello se configuran todos
a O o todos l . Pese a ello el espacio de direcciones virtuales sigue siendo bastante grande: 24 8 bytes= 256
TiB .
•
El núcleo para gestionar las tablas de páginas de los distintos niveles y la MMU utiliza diferentes es­
tructuras de datos y funciones, cuyo nombre, definición e implementación dependen de cada SOBUNIX
y de la arquitectura del computador donde se ejecuta.
e
Ejemplo 4.9
En los SOBUNIX que implementan la arquitectura VM de gestión de memoria, como Solaris, la tarea
de traducción de direcciones la realiza una capa de software denominada capa HAT (Hardware Address
Translation, traducción de direcciones) . Esta capa contiene todas las funciones y estructuras del núcleo
que requieren conocer los detalles del hardware relativos a la traducción de direcciones. La implementa­
ción de esta capa depende de cada arquitectura.
El uso de la capa HAT evita que el resto del subsistema de gestión de memoria del núcleo tenga que
conocer los detalles del hardware, lo cual facilita la portabilidad del núcleo entre diferentes plataformas.
Solo la capa HAT depende del hardware y en consecuencia es distinta en cada arquitectura.
La capa HAT se encarga de la realización de las siguientes tareas:
•
Creación, configuración y destrucción de las tablas de páginas.
•
Control de la MMU.
•
Atención de las excepciones hardware provocadas por la MMU durante el proceso de traducción
de direcciones.
La capa HAT utiliza una estructura ha t para mantener todos los datos relativos a la traducción de direc­
ciones del espacio de direcciones de un determinado proceso, entre ellos, un puntero a la tabla de páginas
de más alto nivel. Recuérdese (ver sección 4.2.3) que la estructura as asociada al espacio de direcciones
virtuales de un proceso mantiene un puntero a la estructura ha t asociada al espacio del proceso.
Los drivers de los segmentos invocan a una determinada función de la capa HAT para la realización de
una determinada tarea, como por ejemplo:
•
hat_a l l o c . Asigna una estructura hat para el espacio de direcciones virtuales de un proceso.
•
hat_free_end. Destruye la estructura ha t de un proceso.
•
hat_mem l o ad. Crea la traducción de direcciones de una determinada página.
SOBUNIX: administración de memoria
165
hat_unl oad. Elimina o invalida la traducción de direcciones de una determinada página.
•
Las funciones de la capa HAT reciben argumentos de entrada que son independientes del hardware como
por ejemplo: direcciones virtuales, tamaños, punteros de página y modos de protección.
•
4.3.2.
Tratamiento de los fallos de página
La MMU durante el proceso de traducción de una dirección virtual en una dirección física realiza
diferentes comprobaciones en orden secuencial. Si el resultado de una comprobación no es satisfactorio
genera una excepción denominada fallo de página que debe ser atendida por el núcleo. De forma general
se distinguen dos posibles tipos de fallos de página:
•
Fallo de validez. Se produce cuando una dirección virtual referencia a una página i cuya entrada
asociada en la tabla de páginas tiene el bit de validez desactivado (v = 0). Este bit se encuentra
desactivado si la página i no está cargada en un marco j de memoria principal o si la página no
pertenece al espacio de direcciones virtuales del proceso.
•
Fallo de protección. Se produce si la operación (lectura, escritura o ejecución) que se desea rea­
lizar sobre la página i referenciada por la dirección virtual no está autorizada por los permisos
establecidos en su entrada de la tabla de páginas.
La implementación del tratamiento de los fallos de página depende de cada SOBUNIX. Aunque de
forma general puede afirmarse que el núcleo para tratar las excepciones producidas por la MMU ejecuta
un manejador de fallos de página que realiza diferentes tareas en función del tipo de fallo de página que
se haya producido. Si se ha producido un fallo de protección o si se produce un fallo de validez porque
se ha intentado acceder a una página que no pertenece al espacio de direcciones del proceso, entonces
el manejador se lo notifica al proceso en ejecución enviándole una señal, generalmente S IGS EGV, cuya
acción establecida por defecto es la terminación del proceso .
S i s e h a producido u n fallo d e validez porque l a página i n o estaba cargada en u n marco j d e memoria
principal, entonces se le asigna un marco j de la lista de marcos de página libre y se carga en él la página i
leyéndola del área de intercambio o desde el sistema de archivos. Una vez cargada el manej ador actualiza
el contenido de la entrada asociada a la página i en la tabla de páginas y manipula el contexto hardware
salvado del proceso que produjo el fallo de página para que cuando vuelva a ser planificado para ser
ejecutado lo haga justo desde la instrucción cuya ejecución produjo el fallo de página.
e
Ejemplo 4.10
En los SOBUNIX que implementan una arquitectura VM de gestión de memoria, como S olaris, el trata­
miento de los fallos de página se realiza de la siguiente forma:
l. El manipulador de excepciones del núcleo identifica el tipo de fallo, el tipo de acceso y localiza
la estructura as del proceso cuya ejecución produjo el fallo de página. Una vez localizada dicha
estructura invoca a la función as_faul t para tratar el fallo.
166
Ampliación de sistemas operativos
2. La función as_faul t localiza el segmento del espacio de direcciones virtuales al que pertenece
la dirección virtual cuya referencia produjo el fallo de página.
3. Una vez localizado el segmento, as_faul t invoca a la función de tratamiento de fallos de página
del driver del segmento. Recuérdese que cada tipo de segmento dispone de un driver distinto y en
consecuencia su función de tratamiento de fallos de página también será distinta. Se va suponer
que el segmento es de tipo s eg_vn, luego se invocaría a la función de tratamiento de fallos de
página del driver de segmentos tipo s e g_vn, es decir, a la función segvn_faul t . Esta función
realiza diferentes acciones en función del tipo de fallo de página.
Si se trata de un fallo de protección o de un fallo de validez porque se ha intentado acceder a una
página que no pertenece al espacio de direcciones del proceso, entonces s egvn_ f au l t envía una
señal S I GSEGV al proceso que produjo el fallo de página. La acción por defecto asociada a esta
señal es terminar el proceso.
Por otra parte si se trata de un fallo de validez asociado a que la página i no estaba cargada en
un marco j de memoria principal entonces las acciones que realiza la función s e gvn_ f au l t
dependen del estado de la página:
•
Si la página tiene asignada una entrada en anon_map entonces invoca a anon_ge tpage
para leer la página en el área de intercambio.
•
Si la página no tiene asignada una entrada en anon_map y el segmento está mapeado a una
archivo, entonces invoca a la función ge tpage del nodo-v del archivo. Esta función si no
encuentra la página cargada en memoria entonces la lee en el disco.
•
Si la página no tiene asignada una entrada en anon_map y el segmento está mapeado al
objeto anónimo, entonces invoca a la función anon_ z e r o que crea una página privada llena
de ceros.
Una vez que la página está cargada en la memoria principal la función segvn_fau l t comprue­
ba si tiene que aplicar la técnica de copiar al escribir y en caso afirmativo invoca a la función
anon_private para hacer una copia privada de la página referenciada.
4. Cuando termina s egvn_ f au l t la función as_faul t invoca a la función ha t_menl oad para
actualizar el contenido de la entrada de la tabla de página tanto en memoria como en el TLB de la
MMU.
•
4.4.
Gestión de la memoria física en SOBUNIX
4.4.1 .
Estructuras de datos utilizadas en la gestión de la memoria física
Los SOBUNIX reservan una parte de la memoria principal para almacenar el código y los datos
estáticos del núcleo. El resto de la memoria principal se encuentra disponible para albergar los datos
SOBUNIX: administración de memoria
167
dinámicos del núcleo y las páginas de los procesos de los usuarios. Los marcos de página ocupados
por páginas del núcleo son marcados en su mayoría como marcos bloqueados, es decir, marcos cuyo
contenido no puede ser intercambiado fuera de la memoria principal. Con esta medida se pretende evitar
que existan fallos de página durante la ejecución del núcleo que afecten a su rendimiento. Algunos
SOBUNIX permiten que algunas pequeñas partes de su núcleo se alojen en marcos no bloqueados. Por
ejemplo, en Solaris las páginas de las pilas de los procesos ligeros se alojan en marcos no bloqueados.
Memoria principal
------
����?_i�Q
______
Zona
reservada
M arco j=N - 1
Marcoj=N
Marcoj=N+ I
ED j=N
ED j=N+ l
Zona asignable
dinámicamente
ED j=M- 1
Estructuras
de datos (ED)
asociadas a
los marcos
de página
de la zona
asignable
dinámicamente
Marcoj=M- 1
Figura 4.8 - Distribución típica de la memoria principal en los SOBUNIX
Para gestionar la parte de memoria de la memoria principal que se asigna dinámicamente el núcleo
mantiene una estructura de datos por cada marco de página existente (ver Figura 4.8). Dicha estructura
mantiene información sobre la página cargada en el marco, así como diferentes punteros para implemen­
tar diferentes listas, como por ejemplo la lista de marcos de página libres que es consultada cuando se
requiere asignar un marco de página libre para cargar una página en memoria. La implementación y la
gestión de las estructuras de datos asociados a los marcos de página, así como de las diferentes listas
mantenidas a partir de estas estructuras, dependen de cada SOBUNIX.
e
Ejemplo 4. 1 1
En los SOBUNIX que utilizan la arquitectura V M d e gestión d e memoria, como por ejemplo Solaris,
cada marco de página de la memoria principal tiene asociado una estructura page que contiene, entre
otros, los siguientes datos:
•
Identidad de la página cargada en el marco. Cada página cargada en un memoria principal queda
identificada de manera unívoca por el par de valores [nodo-v, desplazamiento], es decir, con el
Ampliación de sistemas operativos
168
nodo-v del objeto de datos a partir del cual fue creada la página y el desplazamiento (expresado en
páginas) dentro del objeto.
•
Contador de referencias. Se incrementa en una unidad por cada proceso que comparte el acceso a
la página cargada en el marco.
•
Información relacionada con las estructuras ha t . Como por ejemplo la localización de todas las
tablas de páginas que apuntan al marco.
•
Punteros. Para poder implementar las siguientes listas:
- Lista hash de marcos de página. El núcleo usa esta estructura para encontrar rápidamente al
marco que contiene una determinada página. El par de valores [nodo-v, desplazamiento] que
identifican a la página se introducen a modo de clave en una función hash que devuelve el
índice de una entrada de la lista hash. Cada entrada de la tabla hash estará vacía o contendrá
una cola de estructuras page. Todas las estructuras en una misma cola contienen páginas
cuyo par de valores [nodo-v, desplazamiento] generan el mismo índice al ser introducidos en
la función hash. Una vez conocido el índice hay que examinar la cola para ver si contiene la
página buscada. Obviamente este procedimiento es más rápido que examinar una a una todas
las estructuras page.
- Lista de páginas del nodo-v. Cada nodo-v (ver sección 5 .3 . 1 ) mantiene una lista de todas las
páginas que se encuentran cargadas en memoria principal del objeto al que hace referencia el
nodo-v. Esta lista es utilizada por las rutinas del núcleo que trabajan sobre todas las páginas
cargadas en memoria de un determinado objeto. Por ejemplo, cuando se borra un archivo el
núcleo debe invalidar todas las páginas del archivo que están cargadas en memoria.
- Lista de marcos de página libres. Forman parte de esta lista las estructuras page de los
marcos de página que no contienen ninguna página o contienen páginas que no son mapeadas
por ningún proceso ya que han sido liberadas por la función page_free.
- Lista de E/S. Forman parte de esta lista las estructuras page de los marcos de página que
contienen páginas cuyo contenido ha sido modificado y debe ser salvadas en el disco antes
de reemplazar su contenido.
•
4.4.2.
Reemplazamiento de páginas
Una de las tareas fundamentales que debe realizar un sistema operativo para implementar la técnica
de demanda de página es el reemplazamiento de páginas que consiste en seleccionar una página k cargada
en un marco de página j para ser reemplazada por la página i asociada a la dirección virtual que produjo
el fallo de página.
SOBUNIX : administración de memoria
169
Para implementar el reemplazamiento de página el núcleo debe seleccionar el conjunto de páginas
candidatas a ser reemplazadas, y usar algún algoritmo de reemplazamiento que seleccione, de entre el
conjunto de páginas candidatas, la página víctima que puede ser reemplazada.
En los SOBUNIX generalmente el conjunto de páginas candidatas está formado por todas las páginas
cargadas en la memoria principal en marcos no bloqueados, es decir, utilizan lo que en la literatura se
conoce como estrategia o política de reemplazamiento global.
Asimismo, el algoritmo de reemplazamiento utilizado mayoritariamente en los S OBUNIX es alguna
aproximación del algoritmo LRU (Least Recently Used, usada menos recientemente). La implementa­
ción de un algoritmo LRU estricto produce bastante sobrecarga por lo que se suele usar algún algoritmo
cuyo funcionamiento se aproxime al del algoritmo LRU pero que produzca menos sobrecarga.
e
Ejemplo 4.12
El algoritmo del reloj con dos manecillas (two-handed clock algorithm) utilizado en diversos SOBU­
NIX, como por ejemplo: BSD4.3, SunOS 4.0, SVR4 y Solaris, es una aproximación del algoritmo LRU
que elige como página víctima aquella no usada recientemente, en vez de la página menos usada recien­
temente que se selecciona en un algoritmo LRU.
Este algoritmo examina las estructuras de datos asociados a los marcos de página no bloqueados, a los
que considera organizados en una lista circular (horas del reloj). Para examinar las estructuras utiliza dos
punteros (manecillas) . Cada puntero apunta a una estructura. La separación entre los punteros, es decir,
el número de estructuras entre ellos, se mantiene siempre constante, siendo esta separación un parámetro
configurable del algoritmo. Ambos punteros se mueven simultáneamente en sentido horario.
Para describir el funcionamiento del algoritmo se va denominar puntero 1 al puntero que va por delante
y puntero 2 al que va por detrás (ver Figura 4.9). El puntero 1 pone a O el bit referenciada (r) de la
entrada de la tabla de páginas que referencia a la página cargada en el marco j. Por su parte el puntero
D
ED
x
D
=Estructura de datos asociada al marco
Figura 4.9
-
x
Algoritmo del reloj de dos manecillas
170
Ampliación de sistemas operativos
2 comprueba el bit r de la página cargada en el marco k. Si r = O entonces la página puede ser elegida
para ser reemplazada ya que la página no ha sido referenciada en el tiempo transcurrido desde que el
puntero 1 pasó por ella. El puntero 2 también comprueba el bit modificada m de la página cargada en el
marco k, si dicho bit está 1 la página es colocada en la lista de páginas que deben ser salvadas al área de
intercambio.
•
En los SOBUNIX para mejorar el rendimiento del sistema la búsqueda de páginas víctimas se realiza
antes de que ya no quede memoria libre disponible. Periódicamente, o cuando el tamaño de la lista de
marcos de página libres cae por debaj o de un determinado umbral, se invoca a un proceso del sistema
denominado escáner de paginas5 • Este proceso se crea cuando se arranca el sistema y generalmente tiene
asignado el PID=2.
El escáner de páginas, cuando es invocado, ejecuta el algoritmo de reemplazamiento para seleccionar
un cierto número de marcos de página cuyo contenido puede ser reemplazado. Los marcos seleccionados
cuyo contenido no ha sido modificado son colocados en la lista de marcos libres. Los marcos cuyo
contenido ha sido modificado son colocados en la lista de marcos modificados, los cuales deben ser
salvados en el área de intercambio. Cuando se realice esta operación los marcos serán colocados en la
lista de marcos libres.
Nótese que en consecuencia en la lista de marcos libres no solo hay marcos que contienen páginas que
pertenecen a procesos que ya han finalizado sino también marcos que contienen páginas pertenecientes
a procesos que pueden estar todavía activos pero que como no han sido recientemente referenciadas han
sido seleccionados como candidatas a ser reemplazadas.
Por este motivo el núcleo cuando se produce un fallo de página comprueba si dicha página se en­
cuentra en la lista de marcos de página libres y de esta forma ahorrarse tener que realizar una operación
de E/ S al disco. De hecho algunos SOBUNIX, distinguen dos tipos de listas de marcos de páginas libres :
en una lista se mantienen los marcos que contienen páginas que no van a volver a ser necesitadas y en
otra lista se mantienen páginas que pueden ser necesitadas. Solo cuando la primera se agota se empiezan
asignar marcos de la segunda.
El escáner de páginas se ejecuta hasta que se cumple un determinada condición de parada: haber
seleccionado para reemplazar un determinado número máximo de marcos de página, haber consumido
una cantidad preestablecida de ciclos de CPU, etc. Cuando se cumple la condición de parada el escáner
de páginas entra en el estado dormido hasta que vuelve a ser despertado porque haya transcurrido un
cierto tiempo o porque haya caído la memoria libre por debajo de un cierto límite.
Puesto que la disponibilidad de memoria libre afecta al rendimiento del sistema, la prioridad de
ejecución del escáner de páginas es bastante elevada.
5 A este proceso también se le conoce con el nombre de demonio de páginas (page daemon) o ladrón de páginas (page
stealer). En general el nombre de este proceso suele depender de cada SOBUNIX. En este texto se utiliza el nombre que emplea
Solaris: escáner de páginas, el cual describe bastante bien la tarea que realiza el proceso.
S OBUNIX : administración de memoria
4.4.3.
171
Intercambio de procesos
Si el número de procesos cargados parcialmente en la memoria principal supera un cierto valor
máximo, los conjuntos de trabaj o de los procesos, es decir, sus páginas referenciadas más frecuentemente,
no pueden estar todos contenidos en la memoria principal con lo que comienzan a producirse fallos de
página continuamente.
Una posible forma de eliminar el trasiego consiste en intercambiar de memoria principal al área de
intercambio todas las páginas de uno o varios procesos. En los SOBUNIX, esta tarea la realiza un pro­
ceso del sistema denominado proceso intercambiador (swapper). Este proceso tiene asignado el PID=O,
ya que es el primer proceso que se crea cuando se arranca un S OBUNIX. Este proceso inicialmente crea
al proceso ini t (PID= 1 ) y el escáner de páginas (PID=2), y a continuación pasa a ejecutar una fun­
ción, denominada s ched en algunos SOBUNIX, que contiene todo el código asociado al intercambio de
procesos.
El proceso intercambiador es invocado cada cierto tiempo o si el tamaño de la lista de marcos libres
cae frecuentemente por debajo de un cierto valor límite, lo cual recuérdese propiciaba la invocación
del escáner de páginas. El proceso intercambiador debe seleccionar de acuerdo con unos determinados
criterios los procesos cuyas páginas van a ser intercambiadas al área de intercambio. Cuando termina
de realizar su tarea el proceso intercambiador entra en el estado dormido a la espera de volver a ser
invocado.
La implementación y los criterios de selección que utiliza el proceso intercambiador dependen de
cada SOBUNIX.
e
Ejemplo 4.13
En Solaris se distinguen dos posibles tipos de intercambio :
•
Intercambio suave. Se produce s i e l tamaño d e l a lista d e marcos d e página libre permanece por
debajo de un cierto valor mínimo de s f ree durante alrededor de 30 segundos. El proceso inter­
cambiador, también denominado planificador de memoria, comienza a buscar procesos que han
estado inactivos durante al menos maxs lp segundos. Para cada proceso que cumple está condi­
ción intercambia al área de intercambio todas sus páginas privadas y las estructuras de datos del
núcleo asociadas a la gestión de sus hilos.
•
Intercambio duro. S e produce si se dan simultáneamente las siguientes condiciones: existen más
de dos procesos en las colas de procesos preparados para ejecución, el tamaño de la lista de marcos
de página libre permanece por debajo de un cierto valor mínimo de s f ree durante alrededor de
30 segundos, y la razón de fallos de página es mayor que maxpg i o . El intercambiador selecciona
en primer lugar para ser intercambiadas todos las páginas pertenecientes a módulos del núcleo que
no están activos. A continuación los procesos son intercambiados secuencialmente hasta que se
consigue el espacio libre suficiente.
•
172
Ampliación de sistemas operativos
El proceso intercambiador también comprueba periódicamente si los procesos intercambiados pue­
den volver a ser cargados en la memoria principal. El criterio de retorno que se utiliza depende de la
memoria libre disponible.
4.4.4.
Asignación de memoria principal
En los SOBUNIX la asignación de marcos de página de memoria principal la realiza un componente
del subsistema de gestión de memoria principal denominado asignador a nivel de página. Este asignador
atiende las peticiones de memoria del sistema de paginación y del asignador de la memoria del núcleo
(ver Figura 4. 1 0) .
Lista d e marcos libres
Marco j
Estructuras
de datos
para los
subsistemas
del núcleo
Procesos
usuarios
Caché de
buffers
de bloques
de disco
Figura 4.10 - Asignación de memoria principal en SOBUNIX
El sistema de paginación es la funcionalidad de la arquitectura de gestión de memoria virtual en­
cargada de asignar (y liberar) marcos de página para alojar en memoria principal las páginas virtuales
referenciadas por los procesos durante su ejecución. En algunos S OBUNIX también se encarga de asig­
nar marcos para la caché de buffers de bloques de disco. El sistema de paginación solicita marcos de
página al asignador a nivel de página para repartirlos entre sus clientes: los procesos de los usuarios o la
caché de buffers de bloques de E/S .
Por su parte, el asignador de la memoria del núcleo solicita marcos de página al asignador a nivel de
página para atender las peticiones de memoria de los diferentes subsistemas del núcleo.
El asignador a nivel de página trabaja sobre la lista de marcos de página libres sobre la que realiza,
entre otras, las siguientes operaciones:
S OBUNIX: administración de memoria
173
•
Eliminar marcos. Cuando el sistema de paginación o el asignador de la memoria del núcleo nece­
sitan una determinada cantidad de memoria principal invocan al asignador a nivel de página para
que les asigne marcos libres de memoria principal, los cuales son eliminados de la lista de marcos
de página libres.
•
Añadir marcos. Cuando el sistema de paginación o el asignador de la memoria del núcleo liberan
una cierta cantidad de memoria invocan al asignador a nivel de página para que añada los marcos
liberados a la lista de marcos de página libres.
•
Buscar páginas en los marcos. Durante determinados eventos, como por ejemplo , el tratamiento
de un fallo de página, el sistema de paginación puede solicitar al asignador a nivel de página que
busque en la lista de marcos de página libres si se encuentra cargada en un marco de dicha lista la
página cuya referencia originó el fallo de página. Puede suceder que dicha página se encuentre en
esta lista por haber sido seleccionada por el escáner de página para ser reemplazada. Si la página
se encuentra en la lista se elimina de la misma. Nótese que encontrar una página en esta lista evita
tener que leerla del disco, con lo cual se ahorra tiempo, ya que una operación de búsqueda sobre
la lista requiere de menos tiempo que una operación de lectura a disco.
El asignador a nivel de página se implementa como un conjunto de rutinas que pueden ser invocadas
por el sistema de paginación o el asignador de la memoria del núcleo. Dichas rutinas implementan toda
las operaciones que realiza el asignador.
e
Ejemplo 4.14
Entre las rutinas que implementan el asignador a nivel de página de Solaris se encuentran las siguientes:
•
page_c reat e_va . Esta función devuelve una lista enlazada con todos los marcos que han sido
extraídos de la lista de marcos de página libres de acuerdo con la cantidad de memoria solicitada.
•
page_f r e e . Esta función libera un marco de página y lo coloca en la lista de marcos de página
libres.
•
page_l ookup . Esta función busca la existencia de una determinada página, identificada por su
nodo-v y desplazamiento, en la lista de marcos de página libres.
•
4.5.
Gestión del área de intercambio en SOBUNIX
La implementación de la técnica de gestión de memoria mediante demanda de página requiere la
existencia de un espacio de almacenamiento en memoria secundaria en el que copiar aquellas páginas de
procesos activos cargadas en la memoria principal que son seleccionadas para ser reemplazadas. Obvia­
mente las páginas pertenecientes a procesos terminados no necesitan ser copiadas. A dicho espacio se le
174
Ampliación de sistemas operativos
denomina área de intercambio. En los SOBUNIX el área de intercambio está formada típicamente por
una o varias particiones de discos no formateadas a alto nivel y a las que se accede mediante operaciones
de E/S en bruto.
Las páginas pertenecientes a la mayoría de las regiones del espacio de direcciones virtuales de
un proceso (datos no inicializados, montículo, pila, archivos mapeados en memoria con el indicador
MAP_PRIVATE, etc) son copiadas en el área de intercambio si son seleccionadas para ser reemplazadas.
Las páginas de código de los procesos o de las librerías compartidas no son copiadas en el área de
intercambio. Estas páginas son generadas desde el archivo ejecutable correspondiente si es necesario
cargarlas de nuevo en la memoria principal debido a un fallo de página. Lo mismo ocurre con las páginas
seleccionadas para ser reemplazadas pertenecientes a archivos mapeados con el indicador MAP_SHARED.
En este caso, además, si las páginas han sido modificadas son salvadas en los bloques de disco del
archivo.
Cuando se crea una región del espacio de direcciones virtuales de un proceso que no sea de código
se reserva el espacio suficiente en el área de intercambio para poder almacenar todas sus páginas. Una
página i perteneciente a una determinada región de un proceso activo X se copia en el área de intercambio
la primera vez que ésta es seleccionada por el escáner de páginas para ser reemplazada. Si posteriormente
la ejecución del proceso X produce un fallo de página asociado a la página i el núcleo comprueba si
existe una copia de la página en el área de intercambio. En caso afirmativo la página es copiada en
memoria principal desde el área de intercambio. Más tarde si la página i vuelve a ser seleccionada
para ser reemplazada de la memoria principal solo se copiará de nuevo en el área de intercambio si
su contenido ha sido modificado (el bit m de su entrada de la tabla de páginas está activo), es decir, si la
copia de la página i en memoria principal difiere de la copia de la página i en el área de intercambio.
El núcleo mantiene una lista de espacio libre en el área de intercambio que consulta cuando necesita
asignar espacio del área de intercambio. También mantiene alguna clase de mapa de intercambio para
poder localizar rápidamente las páginas almacenadas en el área de intercambio. La implementación y
mantenimiento de estas estructuras depende de cada SOBUNIX.
e
Ejemplo 4.15
En los SOBUNIX que implementan la arquitectura VM de gestión de memoria, como Solaris, el área
de intercambio se utiliza para almacenar temporalmente las páginas anónimas pertenecientes a proce­
sos activos que son eliminadas de memoria principal. En consecuencia la implementación del área de
intercambio está estrechamente relacionada con la capa anónima.
Solaris implementa en la memoria principal un pseudosistema de archivos denominado swapfs que utiliza
para asignar espacio de intercambio virtual a las páginas anónimas. En un determinado instante de tiempo
el tamaño del espacio virtual definido en swapfs viene determinado por la suma del tamaño del espacio
libre existente en el área de intercambio y el tamaño del espacio libre existente en la zona paginada de
memoria principal.
S olaris también define un conj unto de funciones denominado capa swapfs que utiliza para operar sobre
el pseudosistema y sobre el área de intercambio. Las funciones de la capa swapfs son invocadas por
funciones de la capa anónima cuando se requiere asignar espacio de intercambio a una página anónima.
SOBUNIX: administración de memoria
175
Cada página anónima tiene asociado el nodo-v de un archivo de swapfs y un desplazamiento dentro de
dicho archivo medido en páginas. Nótese que el archivo no ocupa espacio físico sino virtual. Solo cuando
la página anónima es seleccionada para ser reemplazada es necesario asignarle espacio real dentro del
área de intercambio, el cual queda localizado mediante el nodo-v del archivo asociado al dispositivo
físico (ver sección 5 . 5 .2) donde se encuentra el espacio de intercambio real y un desplazamiento, medido
en páginas, dentro de dicho archivo. Si el espacio dentro del área de intercambio se agota, entonces se
utiliza como espacio de intercambio marcos libres de memoria principal, los cuales son marcados como
bloqueados.
La asignación de espacio virtual a través de swapfs permite no malgastar espacio de intercambio real. A
diferencia de lo que sucede en otros SOBUNIX, como SVR4, que utilizan una política más conservadora
consistente en reservar y asignar espacio de intercambio a todas las páginas de un segmento aunque
posiblemente algunas de ellas nunca vayan a utilizarlo.
Cuando se crea un segmento de memoria virtual que se mapea al objeto anónimo o a un archivo con un
mapeado del tipo MAP_PRIVA TE se crea un array de referencias a estructuras anon. En este array existe
una entrada por cada página virtual existente en el segmento. Cada entrada contiene un puntero a una
estructura anon, la cual contiene información sobre la localización de la página anónima en el espacio de
intercambio. En el caso de S olaris (ver Figura 4. 1 1 ) entre los campos presentes en una estructura anon
se encuentran los siguientes:
•
an_vp. Contiene un puntero al nodo-v de un archivo de swapjs.
•
an_o f f . Contiene el desplazamiento medido en páginas desde el comienzo del archivo ubicado
en swapfs.
•
an_pvp. Contiene el valor NULL si todavía no ha sido necesario asignar espacio de intercambio
real a la página anónima. En caso contrario contiene al nodo-v del archivo asociado al dispositivo
físico donde se encuentra el espacio de intercambio real.
•
an_po f f . Contiene el valor NULL si todavía no ha sido necesario asignar espacio de intercambio
real a la página anónima. En caso contrario contiene el desplazamiento medido en páginas desde el
comienzo del archivo asociado al dispositivo físico donde se encuentra el espacio de intercambio
real.
Luego el par de valores [an_vp, an_o f f ] permite localizar a una página anónima en swapfs, es decir, en
el espacio de intercambio virtual . Mientras que el par de valores [an_pvp, an_po f f] permite localizar
a una página anónima en el área de intercambio, es decir, en el espacio de intercambio real.
Cuando el driver de un segmento invoca a la función anon_a l l o c para obtener una página anónima
nueva, esta función invoca a su vez a la función swap f s_ge tvp para obtener un nodo-v de swapfs,
y posteriormente a la función swap f s_ge tpage para crear una nueva página virtual en el archivo de
swapfs. Esta función devuelve el desplazamiento dentro del archivo. Con esta información se inicializa
los campos an_vp y an_o f f de una estructura anon.
176
Ampliación de sistemas operativos
Nodo-v
an_vp
an o f f -----+--�
an__pvp =NULL
swapfs
an__p o f f =NULL
(a)
Nodo-v
swapfs
Nodo-v
Área
de
intercambio
(b)
Figura 4.11 - Asignación de espacio de intercambio virtual y real : (a) En el momento de la creación de
una página anónima. (b) Cuando la página es transferida por primera vez fuera de memoria principal.
Por otra parte los campos an__pvp y an__po f f de una estructura anon se inicializan con el valor NULL.
Cuando la página sea seleccionada por primera vez por el escáner de páginas para ser reemplazada
entonces se le asignará espacio en el área de intercambio y se configurarán adecuadamente los valores
de estos campos.
Para asignar espacio real de intercambio el escáner de páginas busca el nodo-v asignado a la página e
invoca a una operación putpage de dicho nodo-v. En el caso de una página anónima el nodo-v apunta a
un archivo de swapfs y en consecuencia se invoca a la función swap f s__pu tpage. Esta función asigna
un bloque del tamaño de una página en el área de intercambio y configura adecuadamente los valores
de los campos an__pvp y an__po f f de la estructura anon asociada a la página. Ahora sí la página tiene
asociado espacio de intercambio real y puede ser intercambiada fuera de memoria principal.
•
SOBUNIX: administración de memoria
4.6.
Gestión de la memoria perteneciente al núcleo en SOBUNIX
4.6.1.
Espacio de direcciones virtuales del núcleo
177
El núcleo al igual que los procesos de los usuarios dispone de un espacio de direcciones virtuales. La
localización de dicho espacio depende de cada SOBUNIX y de la arquitectura del computador donde se
ejecute. En algunas arquitecturas existe un único espacio de direcciones virtuales el cual es compartido
por el núcleo y los procesos de los usuarios. En dicho caso, generalmente, el espacio de direcciones
virtuales del núcleo ocupa las direcciones virtuales más altas.
En otras arquitecturas el núcleo y los procesos disponen de espacios de direcciones independientes.
En ese caso el núcleo y los procesos tiene a su disposición todo el rango de direcciones virtuales, desde
la dirección virtual O hasta una cierta dirección virtual máxima.
El espacio de direcciones del núcleo se descompone en diferentes regiones o segmentos: región de
código, región de datos, montículo, etc. Las regiones existentes en el espacio de direcciones virtuales del
núcleo y su organización dependen de cada SOBUNIX y de la arquitectura del computador.
El núcleo mantiene diferentes estructuras de datos para gestionar su propio espacio de direcciones
virtuales. Además tiene que mantener una tabla de páginas para que la MMU pueda traducir las direc­
ciones virtuales del núcleo en direcciones físicas.
e
Ejemplo 4.16
En la Figura 4. 1 2 se muestra la distribución del espacio de direcciones virtuales del núcleo de 32 bits
de Solaris en la arquitectura x64 de AMD. Se observan los siguientes segmentos en el espacio virtual
del núcleo : datos, código, estructuras de datos para la gestión de memoria, montículo y la caché de pá­
ginas de archivos ( s eg_map) . Esta caché contiene las páginas de archivos que han sido leídas o escritas
recientemente durante el tratamiento de las llamadas al sistema read o wr i te (ver sección 5 .2. 1 ) . Ini­
cialmente la dirección virtual base de la caché de archivos es OxC3 0 0 2 0 0 0 aunque puede extenderse
dentro del rango de direcciones virtuales denominado zona roja.
Como sucedía con el espacio de direcciones virtuales de los procesos el núcleo mantiene una estructura
as para mantener su propio espacio de direcciones. La dirección de la estructura as del núcleo se man­
tiene en la variable kas . Recuérdese que una estructura as contenía información sobre los segmentos de
un espacio de direcciones virtuales. En el caso del núcleo sus segmentos pueden ser, principalmente, de
tres tipos:
•
s eg_kmen. Las páginas de un segmento de este tipo se alojan en marcos bloqueados de memoria
principal. Los segmento de código, datos, pila y montículo del núcleo son segmentos de este tipo.
•
seg_map . Las páginas de un segmento de este tipo se alojan en marcos bloqueados de memoria
principal. Este tipo de segmento se utiliza para implementar la caché de páginas de archivos del
núcleo.
•
s eg_kp . Las páginas de un segmento de este tipo se alojan en marcos no bloqueados de memoria
principal. Las pilas de los procesos ligeros se alojan en segmentos de este tipo.
178
Ampliación de sistemas operativos
OxFFFFFFFF
1
1
- - - - - - - - - - - - - - - -
1
1
OxFF8 0 0 0 0 0
Datos del núcleo
OxFE C O O O O O
Código del núcleo
O x FE 8 0 0 0 0 0
va r i ab l e
Estructuras
de datos de gestión
de la memoria
Montículo
del núcleo
va r i a b l e
seg_map
OxC3 0 0 2 0 0 0
Zona roja
OxC3 0 0 0 0 0 0
Espacio de
direcciones
virtuales
de usuario
OxO O O O O O O O
-
Figura 4.12 Distribución del espacio de direcciones virtuales del núcleo de 32 bits de Solaris en la
arquitectura x64
•
4.6.2.
Asignación de la memoria del núcleo
Los subsistemas del núcleo necesitan memoria principal para alojar dinámicamente diferentes es­
tructuras de datos. Generalmente el tamaño de estas estructuras suele ser más pequeño que el tamaño de
una página y por ello asignarles páginas completas supone un desperdicio de memoria. Este es el motivo
por el que en los SOBUNIX existe un componente denominado asignador de la memoria del núcleo
que solicita marcos de página al asignador a nivel de página y los descompone en trozos más pequeños
que reparte entre los subsistemas del núcleo que solicitan memoria. Este asignador es el encargado de
atender las peticiones de memoria física realizadas por los subsistemas del núcleo para aloj ar diferentes
estructuras de datos.
El asignador de la memoria del núcleo puede implementarse de diferentes formas, las cuales pueden
ser comparadas atendiendo a criterios tales como la fragmentación de memoria que producen y la rapidez
SOBUNIX: administración de memoria
179
con que atienden las peticiones. Entre las implementaciones más usadas en los SOBUNIX se encuentran
el sistema buddy y el asignador slab. El sistema buddy se describe en la sección 6.5.2, en la siguiente
subsección se describe el asignador slab.
Asignador slab
El asignador slab 6 fue desarrollado por Jeff B onwick [Bonwick, 1 994] para implementar el asignador
de la memoria del núcleo de Solaris 2.4. Debido a su eficiencia y rapidez ha sido exportado a otros
SOBUNIX, como por ejemplo, Linux.
El asignador slab utiliza tres tipos de elementos :
•
Objeto. Hace referencia a u n determinado tipo d e estructura d e datos. Cada objeto queda identifi­
cado por el tamaño que ocupa y el nombre que se le asigna, que es una cadena de caracteres que
lo describe, por ejemplo: nodo-v, nodo-i, etc. Todos los objetos que se refieren a un mismo tipo
de estructura de datos tienen el mismo tamaño y el mismo nombre. Un objeto puede estar libre o
asignado
•
Slab. Es un conjunto de No objetos de un mismo tipo. Cada slab se construye con Np marcos de
página contiguos de memoria principal que son suministradas por el asignador a nivel de página.
•
Cache de objetos. Es un conjunto de Ns slabs de obj etos de un mismo tipo.
El asignador slab trabaj a con varias cachés de objetos. Si un subsistema del núcleo necesita crear
una caché para un determinado tipo de objetos entonces invoca a la función kmem_c ache_c r e a t e . Por
el contrario para eliminarla invoca a la función kmem_c ache_de s t roy. Si desea solicitar la asignación
de un objeto de una caché debe invocar a la función kmem_c ache_a l l o c . Cuando termine de usar el
objeto lo liberará invocando a la función kmem_c ache_f r e e .
Cuando todos los objetos d e una caché están asignados entonces e l asignador slab solicita al asigna­
dar a nivel de página un conjunto de marcos de página contiguos para crear un nuevo slab en la caché.
También es posible destruir un slab cuando todos sus objetos están libres y devolver al asignador a nivel
de páginas las páginas que ocupa dicho slab.
Dentro de una caché por cada slab existente se mantiene una estructura que contiene, entre otros, los
siguientes datos: el número de objetos asignados en el slab, una lista de objetos libres y punteros para
mantener una lista doblemente enlazada de slabs de la caché.
El asignador slab se basa en el hecho de que los subsistemas del núcleo trabaj an siempre con es­
tructuras de datos de unos determinados tamaños que son asignadas y liberadas dinámicamente. Por
ello resulta más eficiente y produce menos fragmentación mantener cachés con las estructuras que son
liberadas, para que puedan ser reutilizadas, que volver asignarles memoria para construirlas desde cero.
e
Ejemplo 4 . 17
En la Figura 4. 1 3 se muestra en un determinado instante de tiempo el estado del asignador slab, se
observa la existencia de dos cachés de objetos: una para objetos X1 de 2 KiB y otra para obj etos X2 de
6 Slab es una palabra inglesa que se puede traducir como lámina, pedazo,
bloque
o
tajada.
180
Ampliación de sistemas operativos
3 KiB . En la Figura 4. 14 se detalla el estado de la caché de objetos X 1 , se observa la existencia de dos
slabs. Cada slab consta de ocho obj etos y ocupa cinco marcos de página contiguos de 4 KiB . Nótese
que de los 20 KiB ocupados por un slab, 1 6 KiB son para almacenar los ocho objetos que contiene y los
restantes 4 KiB para almacenar la información de gestión del slab.
•
Asignador slab
..................................................
Caché de
objetos X l
de 2 KiB
Objetos X l
Subsistemas
del núcleo
Objetos X2 ¡
..
1
�! ; �� ,
Caché de
o eo 2
[_ - -
Páginas
Páginas
-
Figura 4.13 - Asignador slab
del Ejemplo 4.1 7
Marcos de página
de memoria principal
Caché de objetos X l de 2 KiB
Slab
. ..... ............. ...... ... . ..
-- . . ..
,....-
.
.
...=:::._
:
--,
_
.
. .
Objeto X l de 2 KiB
asignado a
un subsistema
del núcleo
··
·····
····
···
····
Asignado
LíQre
Libre
Asignado
Libre
Libre
Libre
Asigna o
".... ... . ..... .. .. ... ........ ...... ........ ......
. ..
. . .
.
.
.
................. ........................................ l======l
................. ..................
.----- ---... ..... ......... . ..... ...... . ......................,...-----,
Slab
..
.
····
····
······
····
I,.._____________J
Figura 4.14 -
Asignador
a nivel
se página
...
.
...................... 1....-..----'
..
................
............... ,____
..........
____
_J
Caché de objetos X 1 de 2 KiB de asignador slab del Ejemplo 4. 1 7
20 KiB
SOBUNIX: administración de memoria
4. 7.
181
Resumen
El subsistema de administración de memoria es el componente del núcleo de un sistema operativo
encargado de administrar, en colaboración con el hardware, la memoria principal entre los restantes
subsistemas del núcleo y entre todos los procesos de usuario que se ejecutan en el computador. Para
realizar esta tarea se pueden usar diferentes técnicas de administración de memoria. En los SOBUNIX se
utiliza la técnica de paginación por demanda la cual posibilita también la implementación de la memoria
virtual.
Un archivo mapeado en memoria es una región del espacio de direcciones virtuales de un proceso en
la que se establece una correspondencia byte a byte con parte o con la totalidad de un archivo. Una vez
mapeado en memoria, el acceso a un determinado byte del archivo puede ser realizado como a cualquier
otro contenido del espacio de direcciones virtuales, es decir, indicando su dirección virtual, lo que evita
tener que realizar llamadas al sistema, con lo que el acceso es mucho más rápido.
Una página anónima es una página que antes de su creación no dispone de un almacenamiento
persistente de respaldo en memoria secundaria. Las páginas anónimas son utilizadas por ejemplo, en
la región de datos no inicializados, el montículo y la región de pila. Al conjunto de páginas anónimas
utilizadas por un proceso se le denomina memoria anónima del proceso.
Con el objetivo de ahorrar espacio de memoria principal los SOBUNIX suelen trabaj ar con tablas
de páginas paginadas, el número de niveles de paginación utilizados es fijado por cada SOBUNIX en
función de la arquitectura.
En los SOBUNIX generalmente el conjunto de páginas candidatas a ser reemplazadas está formado
por todas las páginas cargadas en la memoria principal en marcos no bloqueados, es decir, utilizan lo que
en la literatura se conoce como estrategia o política de reemplazamiento global. Asimismo, el algoritmo
de reemplazamiento utilizado mayoritariamente en los SOBUNIX es alguna aproximación del algorit­
mo LRU. La implementación de un algoritmo LRU estricto produce bastante sobrecarga por lo que se
suele usar algún algoritmo cuyo funcionamiento se aproxime al del algoritmo LRU pero que produzca
menos sobrecarga. Un ejemplo de un algoritmo con estas características es el algoritmo del reloj de dos
manecillas.
El área de intercambio en los SOBUNIX está formada típicamente por una o varias particiones de
discos no formateadas a alto nivel y a las que se accede mediante operaciones de E/S en bruto. Las
páginas pertenecientes a la mayoría de las regiones del espacio de direcciones virtuales de un proceso
son copiadas en el área de intercambio si son seleccionadas para ser reemplazadas.
En los SOBUNIX la asignación de marcos de página de memoria principal la realiza un componente
del subsistema de gestión de memoria principal denominado asignador a nivel de página. Este asignador
atiende las peticiones de memoria del sistema de paginación y del asignador de la memoria del núcleo.
El asignador de la memoria del núcleo puede implementarse de diferentes formas, las cuales pueden
ser comparadas atendiendo a criterios tales como la fragmentación de memoria que producen y la rapidez
con que atienden las peticiones. Entre las implementaciones más usadas en los SOBUNIX se encuentran
el sistema buddy y el asignador slab.
182
4.8.
Ampliación de sistemas operativos
Lecturas recomendadas
Si se desea obtener una explicación adicional de los contenidos tratados en este capítulo se pueden
consultar, por ejemplo: los capítulos 1 2 a 1 5 de [Vahalia, 1 995] , los capítulos 8 a 1 3 de [McDougall y
Mauro, 2006] y el capítulo 1 O de [Tanenbaum, 2009] .
4.9.
Autoevaluación
4 . 1 . ¿Qué técnica de administración de memoria se utiliza generalmente en los SOBUNIX?
(Respuesta en sección 4. 1 )
4 . 2. Enumerar y describir las regiones o segmentos e n que s e puede descomponer el espacio d e direc­
ciones virtuales de un proceso. (Respuesta en sección 4.2. 1 )
4 .3 . ¿Qué comando s e puede utilizar en los SOBUNIX para obtener información sobre e l espacio de
direcciones virtuales de un proceso? (Respuesta en sección 4.2. 1 )
4 . 4 . Explicar cómo s e inicializa u n marco de página de la memoria principal en función del tipo de
región a la que pertenece la página del espacio de direcciones virtuales de un proceso que se va
alojar en dicho marco. (Respuesta en sección 4.2. 1 )
4 .5 . ¿Qué e s u n archivo mapeado e n memoria? ¿Qué ventajas e inconvenientes presenta s u uso?
(Respuesta en sección 4.2.2)
4 . 6 . Explicar la utilidad y la sintaxis de las llamadas al sistema rrunap y munmap.
(Respuesta en sección 4.2.2)
4 .7 . Explicar cómo se implementa de forma general en los SOBUNIX el espacio de direcciones virtua­
les de un proceso. (Respuesta en sección 4.2.3)
4 . 8 . ¿Qué se entiende por objeto de datos en Solaris? ¿Qué es el objeto anónimo?
(Respuesta en sección 4.2.3)
4 . 9 . Enumerar y describir brevemente los tipos de segmentos más frecuentemente utilizados en Solaris.
(Respuesta en sección 4.2.3)
4 . 10. Dibuj ar un diagrama que ilustre la relación entre las estructuras de datos usadas en Solaris para
describir el espacio de direcciones virtuales de un proceso. Comentar brevemente la información
que contiene cada estructura. (Respuesta en sección 4.2.3)
4 . 1 1 . ¿Qué es una página anónima? ¿Cuándo se crea? ¿Qué se entiende por memoria anónima de un
proceso? (Respuesta en sección 4.2.4)
SOBUNIX: administración de memoria
183
4.12. Dibujar un diagrama que ilustre la relación entre las estructuras de datos usadas en Solaris para
describir las páginas anónimas de un segmento de tipo seg_vn. Comentar brevemente la informa­
ción que contiene cada estructura. (Respuesta en sección 4.2.4)
4.13. ¿Qué es la capa anónima de Solaris? ¿Qué funciones desempeña? (Respuesta en sección 4.2.4)
4.14. Dibujar un diagrama que ilustre la relación entre las estructuras de datos usadas en Solaris para
implementar un recurso IPC del tipo memoria compartida. Suponer que la memoria compartida es
un segmento de tipo seg_vn. Comentar brevemente la información que contiene cada estructura.
(Respuesta en sección 4.2.5)
4.15. ¿Qué operaciones se puede realizar sobre el espacio de direcciones virtuales de un proceso?
(Respuesta en sección 4.2.6)
4.16. ¿Cómo se realiza de forma general en los SOBUNIX la creación del espacio de direcciones vir­
tuales de un proceso? (Respuesta en sección 4.2.7)
4.17. Explicar razonadamente como colaboran el hardware (MMU) y el núcleo en la traducción de
direcciones virtuales a direcciones físicas en la técnica de paginación por demanda.
(Respuesta en sección 4.3.1)
4.18. ¿De qué depende el número de niveles de paginación utilizado en los SOBUNIX?
(Respuesta en sección 4.3.1)
4.19. Explicar qué es, para qué sirve y cómo se implementa la capa HAT utilizada en los SOBUNIX que
implementan la arquitectura VM de gestión de memoria. (Respuesta en sección 4.3.1)
4.20. Explicar razonadamente cómo se realiza de forma general el tratamiento de los fallos de página en
los SOBUNIX. (Respuesta en sección 4.3.2)
4.21. Describir cómo se distribuye generalmente la memoria principal en los SOBUNIX.
(Respuesta en sección 4.4.1)
4.22. ¿Qué información debe mantener el núcleo para gestionar la memoria principal?
(Respuesta en sección 4.4.1)
4.23. ¿Para qué utiliza Solaris una estructura page? ¿Qué información contiene?
(Respuesta en sección 4.4.1)
4.24. Enumerar las listas en que organiza Solaris las estructuras page. Comentar la utilidad de dichas
listas. (Respuesta en sección 4.4.1)
4.25. ¿Qué tipo de estrategia o política de reemplazamiento de páginas utilizan los SOBUNIX? ¿Cuál
es el algoritmo de reemplazamiento utilizado mayoritariamente por los SOBUNIX?
(Respuesta en sección 4.4.2)
184
Ampliación de sistemas operativos
4 . 26 . Describir el funcionamiento del algoritmo de reemplazamiento de páginas del reloj con dos mane­
cillas utilizado en diversos SOBUNIX. (Respuesta en sección 4.4.2)
4 . 27 . ¿Qué es y para qué se utiliza el escáner de páginas? ¿Cuándo se invoca? (Respuesta en sección 4.4.2)
4 . 28 . ¿Por qué el núcleo cuando se produce un fallo de página comprueba si la página que ha originado
el fallo se encuentra en la lista de marcos de página libres? (Respuesta en sección 4.4.2)
4 . 29 . ¿Qué es y para qué se utiliza el proceso intercambiador? ¿ Cuándo se invoca?
(Respuesta en sección 4.4.3)
4 .30 . ¿Qué es y a quién atiende el asignador a nivel de páginas? ¿ Qué operaciones realiza sobre la lista
de marcos de página libres? (Respuesta en sección 4.4.4)
4 .31 . ¿Cómo se forma el área de intercambio en los SOBUNIX? ¿Para qué se utiliza en los SOBUNIX
modernos? (Respuesta en sección 4.5)
4 .32 . Describir la gestión del área de intercambio en los SOBUNIX. (Respuesta en sección 4.5)
4 .33 . ¿Para que se utiliza el pseudosistema de archivos swapfs en Solaris? (Respuesta en sección 4.5)
4 .34 . ¿Qué es y para qué se utiliza la capa swapfs de Solaris? (Respuesta en sección 4.5)
4 .35 . ¿Qué parte del espacio de direcciones virtuales se reserva para el núcleo en los SOBUNIX si éste
comparte el espacio con los procesos de usuario? ¿Qué regiones o segmentos se suelen distinguir
en el espacio de direcciones virtuales del núcleo? (Respuesta en sección 4.6.1)
4 .36 . ¿Qué tareas realiza el asignador de la memoria del núcleo de los SOBUNIX? ¿Cómo se imple­
menta? (Respuesta en sección 4.6.2)
4 .37 . Explicar razonadamente la implementación y el funcionamiento del asignador slab en Solaris.
(Respuesta en sección 4.6.2)
4.10.
Ejercicios
4 . 1 . Modificar el programa prog4 1 de la Figura 4.2 para que el mapeado del archivo t ex t o l . txt sea
de tipo privado. Explicar razonadamente los efectos de esta modificación.
4 . 2 . Considérese el programa prog4 2 cuyo código C se muestra en la Figura 4. 1 5 . Invocarlo en segun­
do plano desde la línea de órdenes del intérprete de comandos de un SOBUNIX:
a) Cuando aparezca el primer mensaje en la pantalla escribir la orden prnap [ P I D ] donde
[ P I D ] hace referencia al PID del proceso asociado al programa. Explicar la información que
se muestra en la pantalla.
,
b) Repetir el apartado anterior pero ahora cuando aparezca el segundo mensaje en pantalla.
SOBUNIX: administración de memoria
185
# i nc lude < s t d i o . h>
ma i n ( )
{
int x= O ;
char * b ;
x=g e tp i d ( ) ;
pr i n t f ( " \ nPID= %d due rme 2 0 s \ n " ,
x) ;
s l e ep ( 2 0 ) ;
pr i n t f ( " \ n P ID= %d vu e lve a dorm i r o t r o s 2 0 s \ n " ,
b= ( char * )
x) ;
rna l l o c ( 1 4 * s i z e o f ( char ) ) ;
s l e ep ( 2 0 ) ;
pr i n t f ( " \ n P ID= %d F i na l i z a \ n " ,
x) ;
Figura 4.15 -
Código C del programa prog 4 2
4 .3 . Ejecutar en u n intérprete d e comandos d e u n S OBUNIX l a orden vms tat 5 2 . Consultar el ma­
nual de ayuda man para explicar la funcionalidad de este comando y el significado de la salida que
muestra en la pantalla.
Capítulo 5
SOBUNIX: gestión de archivos y gestión
de la E/S
Objetivos docentes
Los objetivos docentes de este capítulo son los siguientes:
•
Conocer las características principales de la gestión de archivos en los SOBUNIX, así como las
principales llamadas al sistema disponibles para la realización de esta tarea.
•
Saber qué es, para qué se utiliza y cómo se implementa la capa nodo virtual/ sistema de archivos
virtual existente en los SOBUNIX modernos.
•
Conocer cómo se realiza el análisis de nombres de rutas en los SOBUNIX.
•
Conocer las características principales, la estructura en disco y cómo se gestiona un sistema de
archivos UFS .
•
Saber cómo se realiza la gestión de la E/S en los SOBUNIX.
•
Saber qué son y cómo se utilizan los conectores (sockets) en los SOBUNIX.
5.1.
Introducción
Este capítulo está dedicado al estudio de la gestión de archivos y la gestión de la E/S en los SO­
BUNIX. En primer lugar se explican las características principales de los archivos, los directorios, los
enlaces y los sistemas de archivos en los SOBUNIX. Asimismo se enumeran y describen las principales
llamadas al sistema disponibles en los SOBUNIX para la gestión de estos elementos . En segundo lugar
se describe la capa nodo virtual/sistema de archivos virtual utilizada en la mayoría de los SOBUNIX
modernos para poder soportar diferentes tipos de sistemas de archivos. En tercer lugar se explica cómo
1 87
188
Ampliación de sistemas operativos
se analizan los nombres de rutas en los SOBUNIX. En cuarto lugar se describe el sistema de archivos
UFS , el cual es utilizado en diversos SOBUNIX. En cuarto lugar se describe la gestión de la E/S en
los SOBUNIX. El capítulo finaliza con una introducción a los conectores que son uno de los principales
mecanismos utilizados en los SOBUNIX para implementar las conexiones en red.
5.2.
Gestión de archivos en SOBUNIX: características principales y
llamadas al sistema
5.2.1.
Archivos
En los SOBUNIX la información contenida en un archivo se estructura como una secuencia lineal de
bytes. El núcleo no interpreta dicha información, simplemente se limita a operar (leer o escribir) con ella
a nivel de byte. Son los procesos los encargados de interpretar la información contenida en los archivos .
E l acceso a l contenido d e u n archivo s e realiza por defecto d e forma secuencial. Aunque también e s
posible realizar u n acceso directo o aleatorio a u n determinado byte d e u n archivo.
El nombre de un archivo es una cadena de caracteres ASCII. Se pueden usar todos los caracteres
excepto los caracteres 1 y \ o La longitud máxima de un nombre depende del tipo de sistema de
archivos al que pertenezca el archivo. Como se verá en la sección 5 . 2.4 los SOBUNIX soportan el uso
de diferentes tipos de sistemas de archivos.
A diferencia de otros sistemas operativos, en los SOBUNIX el nombre de un archivo no tiene por qué
tener una extensión ya que el núcleo no la interpreta. De nuevo, el uso de extensiones y su interpretación
recae en los procesos. En este sentido, conviene señalar que en los SOBUNIX un nombre puede tener
más de una extensión. Teniendo en cuenta lo anterior los nombres prueba, prueba . e y prueba . e . g z
serían nombres d e archivos válidos e n SOBUNIX.
1
1
1
1
•
Tipos de archivos
En los SOBUNIX, de forma general, se distinguen los siguientes tipos de archivos:
•
Archivos regulares. También denominados archivos ordinarios. Dentro de esta categoría de archi­
vos se encuentran los archivos binarios y los archivos ASCII. Un archivo binario es aquél que
contiene información de un determinado tipo (código compilado, texto formateado, imágenes, vi­
deo, etc) con una estructura determinada que únicamente puede ser interpretada por los programas
que los utilizan. Un archivo ASCII está compuesto de líneas de caracteres ASCII codificadas en
binario que no requieren un programa que los interprete.
•
Directorios. Son archivos cuyos bloques de datos almacenan una lista con los archivos y subdi­
rectorios aloj ados en el directorio. Cada entrada de una lista de un directorio contiene el nombre
de un archivo (o subdirectorio) alojado en el directorio y el número del nodo-i asociado a dicho
archivo (o subdirectorio).
SOBUNIX: gestión de archivos y gestión de la E/ S
•
189
Archivos especiales. Son archivos que representan a dispositivos (ver sección 5 . 5 .2). Existen dos
tipos de archivos especiales:
- Archivos de dispositivos modo carácter. Se utilizan para modelar dispositivos de E/S de tipo
serie como el teclado, el ratón, la impresora y el módem.
- Archivos de dispositivos modo bloque. Se utilizan para modelar la E/ S en bruto a particiones
de discos duros.
•
Tuberías. Una tubería (ver sección 3.5 .2) es un canal de comunicación unidireccional por el que
se pueden transmitir flujos de datos no estructurados con un tamaño máximo fijo.
•
Conectores (sockets). Son uno de los principales mecanismos usados en los S OBUNIX para im­
plementar las conexiones en red (ver sección 5 .6).
•
Enlaces simbólicos. Un enlace simbólico es un archivo que contiene el nombre de ruta absoluta o
relativa de otro archivo.
Atributos de un archivo
Además del nombre de un archivo, el núcleo tiene que mantener otras informaciones relativas a un
archivo. A los elementos componentes de dicha información se les denomina atributos del archivo. Los
atributos de un archivo se almacenan en el nodo-i asociado a dicho archivo.
Entre los atributos frecuentemente mantenidos en los S OBUNIX se encuentran los siguientes: identi­
ficador del dispositivo donde reside el archivo, número del nodo-i asociado al archivo, máscara de modo
del archivo, número de enlaces duros, UID, GID, número de dispositivo mayor y número de dispositivo
menor (está información se almacena si se trata de un archivo de dispositivo (ver sección 5 . 5 .2)), tamaño
en bytes, fecha del último acceso (lectura) al archivo, fecha de la última modificación (escritura) del
archivo, y fecha de la última modificación de los atributos del archivo. Señalar que esta última fecha no
tiene en cuenta las modificaciones en las fechas del último acceso o modificación del archivo.
Los atrib �tos de un archivo se pueden obtener mediante la llamada al sistema s ta t 1. También el
comando l s l in permite visualizar varios atributos de un archivo.
-
e
Ejemplo 5 . 1
Supóngase que en el directorio de trabajo actual existe un archivo llamado text o l . txt. Si se ejecuta la
orden
l s - l in t ext o l . tx t
entonces en la pantalla aparecerá una línea con algunos de los atributos del archivo t ex t o l . txt. Su­
póngase que la línea que aparece en la pantalla es la siguiente:
1En algunos SOBUNIX, como por ejemplo Linux, también existe un comando s t a t el cual internamente invoca a la
llamada al sistema s t a t .
190
Ampliación de sistemas operativos
1024
-
rw r
-
--
r
--
1 1 0 1 1 0 4 7 2 0 1 2 - 0 3 - 1 6 1 0 : 0 2 text o 1 . txt
El significado de los componentes de esta línea es el siguiente: 1 0 2 4 es el número de nodo-i asociado al
archivo, - r w- r --r --es la máscara de modo del archivo, 1 es el número de enlaces duros, 1 0 1 es el
UID, 1 o es el GID, 4 7 es el tamaño del archivo en bytes, y 2 o 1 2 - o 3 -1 6 1 o : o 2 es la fecha de la última
modificación del archivo.
•
Descriptores de archivos
Para que un proceso pueda poder operar sobre un archivo, éste primero tiene que ser abierto mediante
la invocación de la llamada al sistema open. La rutina del núcleo del sistema operativo que trata esta
llamada al sistema crea en la memoria principal una estructura de datos denominada objeto de archivo
abierto y asigna a dicha estructura un número entero positivo pequeño denominado descriptor de archivo
para identificarla. Nótese que si un proceso abre el mismo archivo dos veces, o si dos procesos abren el
mismo archivo, el núcleo creará una estructura de objeto abierto y un descriptor de archivo en cada
invocación de la llamada al sistema open. Luego se tendrían dos obj etos de archivo abierto, cada una
con su correspondiente descriptor de archivo.
La llamada al sistema open devuelve el descriptor del archivo abierto al proceso que invocó la
llamada. Para poder operar sobre un archivo abierto el proceso debe pasar el descriptor del archivo como
argumento de las llamadas al sistema asociadas a las operaciones que desee realizar sobre el archivo.
Todos los descriptores de archivos asociados a un proceso se indexan en una tabla denomina tabla
de descriptores de archivos. Esta tabla es local a cada proceso, es decir, cada proceso tiene su propia
tabla de descriptores de archivos. Luego un mismo descriptor de archivo puede referirse en dos procesos
distintos a archivos diferentes.
Cada entrada de una tabla de descriptores de archivos contiene un puntero a la estructura de objeto
de archivo abierto a la que está asociado el descriptor, y una serie de indicadores que especifican el
tratamiento que debe dar al descriptor ante la aparición de determinados eventos. Por construcción las tres
primeras entradas (entradas O a 2) de la tabla de descriptores de archivos de un proceso están asociadas a
los siguientes archivos: archivo estándar de entrada (descriptor 0), archivo estándar de salida (descriptor
1 ) y archivo estándar de salida de errores (descriptor 2) . Por defecto el archivo estándar de entrada está
asociado al teclado y el archivo estándar de salida está asociado a la pantalla.
Por su parte, un objeto de archivo abierto contiene la información necesaria para poder operar sobre
un archivo:
•
Puntero de lectura/ escritura. Indica el byte del archivo donde se realizará la próxima operación
de lectura o de escritura. Se especifica como un desplazamiento desde el origen del archivo. Re­
cuérdese que en SOBUNIX el acceso al contenido de un archivo se realiza por defecto de forma
secuencial.
•
Contador de referencias. Especifica el número de descriptores de archivos que hacen referencia al
objeto de archivo abierto. Normalmente el contador vale 1 , pero puede tomar valores superiores si
SOBUNIX: gestión de archivos y gestión de la E/ S
191
se duplica el descriptor usando las llamadas al sistema dup o dup2 . También cuando un proceso
padre crea un proceso hijo se duplican los descriptores de archivos del proceso padre para asignár­
selos al proceso hijo. De esta forma, el proceso hij o puede acceder a los archivos abiertos por el
proceso padre.
•
Modo de apertura del archivo. Establece las operaciones que se pueden realizar sobre el archivo
abierto. Por ejemplo, solo lectura, solo escritura, lectura y escritura, etc. El modo de apertura se
especifica como un argumento de la llamada al sistema open, bien en la forma de un número octal
similar en estructura a la máscara de modo de un archivo o en la forma de una constante simbólica.
Cada vez que se va a realizar una operación sobre el archivo abierto el núcleo comprueba el modo
de apertura del archivo para permitir o denegar la realización de la operación.
•
Puntero al nodo virtual del archivo. Un nodo virtual, o más abreviadamente nodo-v, es una es­
tructura de datos que el núcleo crea en memoria principal para cada archivo activo. La utilidad y
contenido de esta estructura de datos se describirá en la sección 5 . 3 . 1 .
La implementación de las tablas de descriptores de archivos y de los objetos de archivos abiertos
depende de cada SOBUNIX.
e
Ejemplo 5 . 2
En Solaris la tabla de descriptores de archivos asociada a un proceso se implementa mediante un array
f i_l i s t que está indexado por el número de descriptor de archivo. Cada elemento del array está for­
mado por una estructura u f_entry que contiene, entre otras informaciones, un puntero a un objeto de
.
archivo abierto, el cual se implementa mediante una estructura f i l e .
Una estructura f i l e contiene los siguientes campos :
•
f_vnode . Puntero a l nodo-v asociado a l archivo abierto.
•
f_o f f s e t . Puntero de lectura/escritura.
•
f_c red. Modo de apertura del archivo.
•
f_c oun t . Contador de referencias. Especifica el número de descriptores de archivos que referen­
cian al objeto de archivo abierto.
En la Figura 5 . 1 se muestra la relación entre estas estructuras para el caso de dos procesos A y B que han
abierto el mismo archivo. Cada proceso tiene su propia tabla de descriptores de archivos. El proceso A
referencia al archivo mediante un descriptor de archivo igual a 3 mientras que el proceso B lo referen­
cia mediante un descriptor de archivo igual a 4. Cada descriptor apunta a un obj eto de archivo abierto
distinto. Como los dos procesos han abierto el mismo archivo ambos objetos abiertos apuntan al mismo
nodo-v.
•
192
Ampliación de sistemas operativos
fi l i st
O
u f_ent ry
u f_entry
2
u f_entry
3
u f_ent ry
s t ru c t f i l e
f vnode
f off set
1
1
1
f cred
f c ount
!
11
1
1
1
1
•-------------------·
Objeto de archivo abierto
Tabla de descriptores
de archivos de un proceso A
nodo-v
f i l i st
O
uf_ent ry
uf_ent ry
2
u f_entry
3
u f_entry
4
u f_ent ry
f count
Objeto de archivo abierto
1
1
1
1
1
1
1
•-------------------'
Tabla de descriptores
de archivos de un proceso B
-
Relación existente entre las estructuras de datos asociadas a un archivo abierto por dos
procesos A y B en Solaris
Figura 5.1
Llamadas al sistema
Un proceso para operar sobre un archivo debe invocar a la llamada al sistema apropiada. De forma
general los SOBUNIX proporcionan a los procesos de los usuarios las siguientes llamadas al sistema
para poder operar sobre los archivos:
•
fd=creat ( ruta , modo ) . Esta llamada al sistema permite crear y abrir un archivo con el nombre
de ruta especificado en ruta con la máscara de modo octal 0302010o especificada en modo . Si
la llamada se ejecuta con éxito entonces en f d se guarda el descriptor del archivo. En caso de
error en fd se guarda el valor -l. Si el archivo que se deseaba crear ya existía entonces se borra su
contenido y su longitud se trunca a cero bytes.
SOBUNIX: gestión de archivos y gestión de la E/ S
•
193
fd=open ( ruta , modo_a ) . Esta llamada al sistema permite abrir el archivo localizado en ruta
con el modo de apertura especificado en modo_a . El modo de apertura se especifica en la forma de
un número octal similar en estructura a la máscara de modo de un archivo o en la forma de alguna
de las constantes simbólicas definidas en el archivo de cabecera f cnt l . h. Por ejemplo, las cons­
tantes O_RDONLY y O_WRONLY indican que el archivo se debe abrir con permisos de solo lectura
o de solo escritura, respectivamente. Mientras que la constante O_RDWR indica que el archivo se
debe abrir con permisos de lectura y escritura.
Si la llamada al sistema se ejecuta con éxito entonces en fd se guarda el descriptor del archivo. En
caso de error en fd se guarda el valor l
-
.
•
r = c l o s e ( f d ) . Esta llamada al sistema cierra el archivo con descriptor de archivo fd. Si la lla­
mada se ejecuta con éxito en r se guarda el valor O. En caso de error en r se guarda el valor
-l.
•
r = read ( fd , bu f f e r , N ) . Esta llamada permite leer N bytes del archivo con descriptor f d y escri­
birlos en memoria a partir de la posición apuntada por bu f f er. La operación de lectura comienza
desde la posición indicada en el puntero de lectura/escritura almacenado en el objeto de archivo
abierto al que apunta el descriptor de archivo fd. Si la llamada se ejecuta con éxito entonces en
r se guarda el número de bytes que se han podido leer. Luego r puede ser menor o igual a N. En
caso de error en r se guarda el valor 1
-
.
•
r=wr i t e ( f d , bu f f e r , N ) . Esta llamada permite leer N bytes desde la posición de memoria apun­
tada por bu f f er y escribirlos en el archivo con descriptor fd. La operación de escritura comienza
desde la posición indicada en el puntero de lectura/escritura almacenado en el objeto de archivo
abierto al que apunta el descriptor de archivo fd. Si la llamada se ejecuta con éxito entonces en r
se guarda el número de bytes que se han podido escribir. Luego r puede ser menor o igual a N. En
caso de error en r se guarda el valor - 1 .
•
r = l s eek ( f d , o f f s e t , o r igen ) . Esta llamada al sistema permite desplazar o f f s e t bytes desde
o r i gen el puntero de lectura/escritura del archivo con descriptor fd. El argumento o r i gen puede
tomar los siguientes valores: O o SEEK_SET que indica que el desplazamiento se realizará desde el
inicio del archivo, 1 o SEEK_CUR que indica que el desplazamiento se realizará desde la posición
actual del puntero, y 2 o SEEK_END que indica que el desplazamiento se realizará desde el final
del archivo. Por su parte, el argumento o f f s e t puede ser un número entero positivo o negativo.
Si es positivo entonces el puntero avanzará, mientras que si es negativo el puntero retrocederá. Si
la llamada al sistema se ejecuta con éxito entonces en r se guarda la nueva posición, medida en
bytes, que toma el puntero de lectura/escritura con respecto al inicio del archivo. En caso de error
en r se guarda el valor - l .
•
r = s tat ( ruta , &bu f f er ) . Esta llamada al sistema copia en la estructura bu f f e r de tipo predefi­
nido s ta t los atributos del archivo localizado en rut a . Si la llamada se ejecuta con éxito entonces
en r se guarda el valor O, en caso contrario se guarda el valor - l .
194
Ampliación de sistemas operativos
•
r = f s tat ( fdl &bu f f e r ) . Esta llamada al sistema presenta la misma funcionalidad que la llamada
s t a t . Se diferencia de dicha llamada en que recibe como argumento de entrada el descriptor del
archivo fd en lugar del nombre de ruta.
•
r = f cnt l ( fdl op 1arg ) . Esta llamada al sistema permite realizar diferentes operaciones de con­
trol sobre un archivo abierto con descriptor fd. Las operaciones op disponibles se encuentran
definidas en el archivo de cabecera f en t 1 h. Entre dichas operaciones una de las más útiles es la
.
posibilidad de bloquear o desbloquear el acceso a otros procesos a parte o la totalidad del conte­
nido de un archivo. De esta forma un proceso puede garantizarse el acceso con exclusión mutua a
un archivo usado por múltiples procesos concurrentes sin necesidad de utilizar mecanismos IPC.
Esta operación también se puede realizar utilizando la función de librería l o c k f .
Los argumentos necesarios para cada operación s e especifican e n arg. Si l a llamada s e ejecuta con
éxito en r se almacena un valor que depende de cada operación. En caso de error se almacena el
valor -l.
e
Ejemplo 5 .3
Supóngase que en el directorio de trabajo actual no existe ningún archivo. Si un proceso A invoca a la
llamada al sistema
r = c reat ( " da t o s " 10 6 6 6 ) ;
entonces se creará y se abrirá el archivo da t o s con la máscara de modo octal 0 6 6 6 , es decir, todos los
usuarios pueden leer y escribir en el archivo. El descriptor del archivo se almacenará en r .
Si a continuación e l proceso A invoca a la llamada a l sistema
wr i t e ( r1o r i gen15 0 ) ;
entonces se leerían los 50 primeros bytes desde la posición de memoria apuntada por o r i gen y se
escribirían en el archivo con descriptor r .
Supuesto que el proceso A ha terminado de usar el archivo entonces debería invocar una llamada al
sistema
close ( r ) ;
para cerrarlo.
S i posteriormente otro proceso B invoca a la llamada al sistema
f = open ( " da t o s " 1O_RDONLY ) ;
entonces el archivo da t o s se abrirá con permiso de solo lectura y el descriptor del archivo se almacenará
en f. Señalar que la constante O_RDONLY podría haberse sustituido por el número octal 0 4 0 0 .
S i el proceso B invoca a la llamada al sistema
SOBUNIX: gestión de archivos
y
gestión de la E/ S
195
l s e ek ( f , 2 5 , 0 ) ;
entonces el puntero de lectura/escritura se desplazará 25 bytes comenzando desde el origen del archivo.
Es decir, supuesto que los bytes comienzan a numerarse desde O, el puntero pasa a apuntar al byte no 25
del archivo.
Si a continuación el proceso B invoca a la llamada al sistema
read ( f , de s t i no , l O ) ;
entonces se leerían 1 O bytes en el archivo con descriptor f comenzando desde el byte no 25 y se escribirían
en memoria a partir de la posición de memoria apuntada por de s t ino.
Supuesto que el proceso B ha terminado de usar el archivo entonces debería invocar una llamada al
sistema
c lose ( f ) ;
para cerrarlo.
•
5.2.2.
Directorios
El núcleo, las aplicaciones y los usuarios organizan sus archivos en directorios. En los SOBUNIX un
directorio es un archivo en cuyos bloques de datos se almacena una lista con los archivos y directorios
contenidos en el directorio.
En los sistemas de archivos desarrollados para SOBUNIX una entrada de una lista de un directorio
contiene, entre otras informaciones, el número del nodo-i asociado a un archivo y su nombre. Además
existen dos entradas especiales : la entrada punto
que se refiere al propio directorio y la entrada punto­
punto " . . " que se refiere al directorio padre.
Los SOBUNIX implementan una estructura de directorios de gráfica acíclica. El directorio raíz es el
directorio / ' . Este carácter también se utiliza para separar cada componente del nombre de ruta absoluta
o relativa de un archivo.
1 • 1
1
Número de nodo-i
1 20
52
256
350
Tabla 5.1 - Lista
Nombre del archivo
o
o
proye c to
l i s tar
de archivos almacenada en el directorio al ex de la Figura 5 .2
196
Ampliación de sistemas operativos
Directorio 1
bin
boot
Directorio
dev
home
home
Directorio
Directorio
sara
Figura
e
5.2- Estructura de directorios del SOBUNIX del Ejemplo 5.2
Ejemplo 5.4
En la Figura 5.2 se muestra a modo de ejemplo un diagrama con la estructura de directorios de un
cierto SOBUNIX. Asimismo en la Tabla 5 . 1 se muestra la lista de archivos aloj ada en el directorio
/ home / al ex. La primera entrada corresponde a la entrada punto
que hace referencia al propio direc­
torio. Su número de nodo-i es 1 20.
1 • 1
La segunda entrada corresponde a la entrada punto-punto " . . " que hace referencia al directorio padre
del directorio / home / al ex, en este caso el directorio / home . Su número de nodo-i es 52.
La tercera entrada corresponde al archivo proyect o cuyo número de nodo-i es 256. Este archivo de
acuerdo con la Figura 5.2 es un directorio, pero realmente esto no se puede saber hasta que no se consulte
el tipo de archivo en el nodo-i número 256.
Finalmente la cuarta entrada corresponde al archivo l i s t ar cuyo número de nodo-i es 350.
•
En los SOBUNIX existen varias llamadas al sistema que permiten operar a nivel de directorios, como
por ejemplo:
•
r = chdi r ( ruta) . Esta llamada al sistema cambia el directorio de trabajo. El nuevo directorio de
trabaj o es el especificado en rut a. Si la llamada al sistema se ejecuta con éxito en r se almacena
el valor O, en caso de error se almacena el valor - 1 . Señalar que el comando cd que se utiliza para
cambiar de directorio de trabaj o invoca internamente a esta llamada al sistema.
SOBUNIX: gestión de archivos y gestión de la E/S
•
197
r=mkd i r ( ruta , modo ) . Esta llamada al sistema permite crear un directorio en el nombre de
ruta especificado en ruta con la máscara de modo octal Ü3ÜzÜ¡Üo especificada en modo. Si la
llamada se ejecuta con éxito entonces en r se guarda el valor O, en caso de error se almacena el
valor - 1 . Señalar que el comando mkd i r que permite crear un directorio invoca internamente a
esta llamada al sistema.
•
r = rmdi r ( ruta ) . Esta llamada al sistema permite eliminar el directorio localizado en ruta. Para
que pueda ser eliminado el directorio debe estar vacío. Si la llamada se ejecuta con éxito entonces
en r se guarda el valor O, en caso de error se almacena el valor -l. Señalar que el comando rmdir
que permite borrar un directorio invoca internamente a esta llamada al sistema.
5.2.3.
Enlaces
Una de las características principales de una estructura de directorios de gráfica acíclica es la posi­
bilidad de compartir archivos o directorios entre varios usuarios mediante el uso de enlaces. Un enlace
permite conectar un directorio origen con un elemento (archivo o subdirectorio) ya existente en otro
directorio destino. Se distinguen dos posibles tipos de enlaces: enlaces duros y enlaces simbólicos.
Un enlace duro es una entrada de un directorio. En los SOBUNIX un archivo puede ser referenciado
por múltiples entradas de directorios. En el nodo-i asociado al archivo, entre otras informaciones, existe
un contador de enlaces duros. Cada vez que se crea una entrada de un directorio que referencia al archivo,
es decir, un enlace duro, el contador se incrementa en una unidad.
Cuando se crea un directorio el contador de enlaces duros de su nodo-i toma el valor 2. Un enlace
corresponde a la entrada del directorio dentro de su directorio padre la cual contiene el nombre del
directorio. El otro enlace corresponde a la entrada
del directorio creado.
Cada vez que se crea un subdirectorio dentro de un directorio A, el contador de enlaces duros del
del subdirectorio creado, la
nodo-i del directorio se incrementa en una unidad debido a la entrada
cual referencia a su directorio padre, es decir, al directorio A. El contador se decrementa cada vez que se
borra un subdirectorio. En general, el número de enlaces duros NEo de un directorio es igual al número
de subdirectorios Ns más dos:
NEo = Ns + 2
(5 . 1 )
1
•
1
11
e
•
•
11
Ejemplo 5 .5
En la Figura 5 . 3 se muestra en detalle parte de la estructura de directorios del sistema de archivos del
Ejemplo 5 .4. Se observa que cuatro entradas de directorios apuntan al directorio / home : la entrada aso­
ciada al directorio / home en el directorio raíz, la entrada
del propio directorio / home , la entrada
del subdirectorio / home / s ara. Luego el con­
del subdirectorio / home / a l ex y la entrada
tador de enlaces duros del nodo-i del directorio / home tendrá almacenado el valor 4. Este valor podría
haberse determinado también usando (5 . 1 ).
1
11
•
•
11
11
•
•
•
1
11
•
S i un archivo, excepto si es de tipo directorio, tiene NEo enlaces duros eso implica que tiene NEo
nombres distintos.
198
Ampliación de sistemas operativos
Directorio 1
:
home
:
�
�hh�me ��
Directorio
. .
J
al ex
sara
Dinxtori
s a ra
. .
Directorio
al
ex
:
/
. .
:
Figura 5.3 -
Detalle de parte de la estructura de directorios del sistema de archivos del Ejemplo 5.5
A diferencia de los restantes tipos de archivos un directorio solo puede tener un único nombre para
evitar la existencia de ciclos en el árbol de directorios.
Un enlace simbólico es un archivo cuyos bloques de datos contienen el nombre de ruta absoluta o
relativa de otro archivo o directorio. S i el nombre de ruta ocupa poco espacio entonces éste se puede
almacenar directamente en el nodo-i del archivo que implementa el enlace simbólico sin necesidad de
consumir bloques de datos.
La entrada asociada a un enlace simbólico en el directorio origen no contiene un puntero al nodo-i
del elemento destino, sino un puntero al nodo-i del archivo que implementa el enlace simbólico.
La máscara de modo simbólica de cualquier enlace simbólico siempre es l rwxrwxrwx por convenio.
Esta máscara solo es una notación y no transmite la información usual sobre los permisos de acceso del
propietario, grupo propietario y otros usuarios. Es la máscara de modo del elemento destino la que será
consultada para autorizar o denegar los accesos al archivo destino. De hecho cualquier operación de
cambio de permisos que se realice sobre el enlace simbólico en realidad se estará realizando sobre el
archivo destino.
La principal ventaj a de los enlaces simbólicos es que permiten crear enlaces a directorios. S u princi­
pal inconveniente es que consumen bloques de datos de disco y que retardan el análisis de los nombres
de ruta.
En los SOBUNIX, cuando se invoca una llamada al sistema cre a te o mkdir para crear un nuevo
archivo o directorio, respectivamente, se crea una entrada en el directorio de creación, es decir, un enlace
duro. Una vez creado el elemento destino se pueden utilizar las llamadas al sistema l ink y s yml ink
para crear más enlaces duros o enlaces simbólicos, respectivamente. Para eliminar un enlace se puede
SOBUNIX: gestión de archivos y gestión de la E/ S
199
usar la llamada al sistema unl in k. Estas tareas también se pueden realizar con los comandos 1 ink,
s yml ink y unl ink, los cuales internamente invocan a las llamadas al sistema homónimas. También el
comando ln que permite crear enlaces duros y simbólicos invoca internamente a las llamadas 1 ink o
syml ink.
A la hora de usar estas llamadas al sistema y comandos conviene recordar que si se aplican para crear
un enlace duro sobre un directorio se generará un mensaje de error, ya que los directorios solo pueden
tener un nombre, el que se les asigna en el momento de su creación.
e
Ejemplo 5. 6
Supóngase la estructura de directorios de la Figura 5 .2. Considérese que el directorio de trabajo actual
es / home / s ara y que el archivo / home / al ex/ proyect o / t empo . txt tiene asignado un nodo-i con
número de nodo-i igual a 2345 . La creación del enlace duro proybp al archivo t empo . txt ha podido
ser realizada por un usuario que disponga de los permisos adecuados usando el siguiente comando:
ln / home / al ex / proyect o / t empo . txt proybp
También se puede usar el comando:
l i nk / home / al ex / proyect o / t empo . txt proybp
Tras crear el enlace duro se tienen dos nombres distintos proybp y t empo . txt asociados al archivo con
número de nodo-i 2345 . El contador de enlaces duros almacenado en el nodo-i ahora tendrá el valor 2.
Esto se puede comprobar utilizando el comando:
l s - l i proybp
Cualquiera de los dos enlaces duros al archivo con número de nodo-i 2345 puede ser borrado usando el
comando unl ink. Por ejemplo, el comando
unl i nk / home / al e x / proyect o / t empo . txt
eliminaría el primer enlace duro del archivo.
Por otra parte, el enlace simbólico / home / al ex / l i s tar al archivo /bi n / l s ha podido ser creado
usando el comando
ln - s / b i n / l s / home / al ex / l i s tar
También se puede usar el comando
syml i nk /bi n / l s / home / al ex / l i s t ar
Si se utiliza el comando
l s - l i / b i n / l s / home / al ex / l i s tar
200
Ampliación de sistemas operativos
se puede comprobar que los archivos / b in / l s y / home / a l ex / l i s tar tienen números de nodos-i
distintos, a diferencia de que lo sucede con los enlaces duros. Esto es así porque un enlaces simbólico es
un archivo distinto del archivo destino y en consecuencia tiene asignado otro nodo-i distinto.
•
5.2.4.
Sistemas de archivos
Durante el proceso de instalación de un SOBUNIX se realiza un formateo a alto nivel de una partición
del disco duro para crear el sistema de archivos principal donde se aloj a el directorio raíz !'. Cada
SOBUNIX establece el tipo de sistema de archivos principal que crea, por ejemplo, SVR3 crea un sistema
s5fs, B SD4.2 crea un sistema FFS , Linux un sistema EXT4, Solaris un sistema ZFS , etc.
Aparte de este sistema de archivos principal, los SOBUNIX son capaces de reconocer y manipular
otros sistemas de archivos del mismo o distinto tipo ubicados en memoria secundaria: discos duros,
discos ópticos (CDs, DVDs o B lu-Ray), pendrives, etc. Por ejemplo, Solaris soporta, entre otros, los
siguientes tipos de archivos : UFS , ZFS , NFS , FAT-32 e ISO 9660.
Para poder acceder a los contenidos de un determinado sistema de archivos ubicado en memoria
secundaria, éste debe ser previamente montado en algún directorio dentro de la estructura de directorios
del sistema de archivos principal. A dicho directorio se le denomina punto de montaje. Por ejemplo, el
punto de montaje del sistema de archivos principal es el directorio raíz !'.
El núcleo almacena en un archivo una tabla de montaje con los sistemas de archivos que tiene que
montar al arrancar el sistema y desmontar al apagarlo. Dicho archivo suele almacenarse en el directorio
/ e t c y su nombre depende de cada SOBUNIX. Por ejemplo, en Solaris se le denominamnt tab, mientras
que en Linux se denomina mtab. En cada entrada de la tabla de montaje se suelen mantener, entre otros,
los siguientes datos: dispositivo que se monta, punto de montaje y tipo de sistema de archivos.
En SOBUNIX la estructura de directorios accesible por el usuario queda constituida por el sistema
de archivos principal y todos los sistemas de archivos montados sobre éste. El acceso a un directorio o
archivo de un sistema de archivos montado sobre el sistema de archivos principal se realiza exactamente
igual que a cualquier archivo o directorio del sistema de archivos principal, es decir, especificando su
nombre de ruta absoluta o relativa.
Por otra parte, los permisos de acceso a un sistema de archivos montado se establecen configurando
los permisos de acceso del punto de montaje.
Algunos comandos útiles para trabaj ar con sistemas de archivos son los siguientes:
1
1
•
moun t . Monta un cierto sistema de archivos en un determinado punto de montaje. Este comando
internamente invoca a la llamada al sistema moun t .
•
umount . Desmonta un cierto sistema de archivos. Este comando internamente invoca a la llamada
al sistema umount .
•
mk f s . Crea u n sistema d e archivos de u n tipo soportado por e l SOBUNIX correspondiente en un
cierto dispositivo.
SOBUNIX: gestión de archivos
y
gestión de la E/ S
201
•
f s ck. Comprueba y repara la existencia de inconsistencias en un determinado sistema de archivos.
•
d f . Muestra datos sobre la distribución de espacio libre y asignado de un determinado sistema de
archivos.
e
Ejemplo S.7
Supóngase que el núcleo de un cierto SOBUNIX asocia a la unidad de CD-ROM el archivo de dispositivo
/ dev/ s r O . Supóngase que se inserta en la unidad de CD-ROM un disco con un sistema de archivos de
tipo ISO 9660 cuyo contenido es el que se muestra en la Figura 5 .4a. Para poder acceder a los contenidos
del sistema de archivos del CD-ROM primero debe ser montado en el sistema de archivos principal en
algún punto de montaje. Supóngase por ejemplo que se desea utilizar como punto de montaje el directorio
/ c drom.
El montaje del sistema de archivos del CD-ROM en el punto de montaje seleccionado se puede realizar
desde un intérprete de comandos mediante la siguiente orden:
mount / dev / s r O / c dr om
Una vez montado se puede listar el contenido del sistema de archivos del CD-ROM usando el comando:
ls
-1
/ c drom
El acceso a un archivo o directorio del CD-ROM se realiza igual que a cualquier otro archivo del sistema
de archivos principal, es decir, especificando su nombre de ruta. Por ejemplo, supóngase que en el direc­
torio raíz del CD-ROM existe el archivo ASCII l e eme . txt. Para mostrar su contenido en la pantalla se
puede usar la siguiente orden:
mo re / c drom / l e eme . txt
Cuando se termine de usar el CD-ROM para desmontar su sistema de archivos se debe usar la siguiente
orden:
umount / dev/ s r O
Conviene señalar que cuando un directorio D s e utiliza como punto de montaje l a lista de archivos
que contenía originalmente D es sustituida por la lista de archivos del directorio raíz ( 1 ) del sistema
de archivos montado, y en consecuencia no es posible acceder a los archivos aloj ados originalmente
en D. Por ejemplo, en la Figura 5 .4a el directorio / c drom contiene el archivo da t o s . txt. Cuando
dicho directorio pasa a utilizarse como punto de montaje (ver Figura 5 .4b) ya no se puede acceder a
da t o s . txt ya que la lista de archivos que contenía originalmente el directorio ha sido sustituida por la
lista de archivos del directorio raíz del sistema de archivos del CD-ROM. Cuando el sistema de archivos
del CD-ROM sea desmontado entonces se restaurará la lista de archivos original y podrá accederse de
nuevo al archivo da t o s . txt.
1
1
•
202
Ampliación de sistemas operativos
Directorio 1 del
sistema de archivo principal
bin
boot
dev
Directorio
home
�����--��cdrom
1
cdrom
datos.txt
(a)
Directorio 1 del
sistema de archivo principal
bin
boot
dev
home
cdrom
Directorio
cdrom
leeme.txt
vid.mpg
(b)
del sistema de archivos principal del Ejemplo 5.7 antes (a)
el sistema de archivos del CD-ROM
Figura 5.4 - Estado
5.3.
y
después (b) de montar
Capa nodo virtual/sistema de archivos virtual
Los primeros SOBUNIX únicamente soportaban un único tipo de sistema de archivos: S5FS en los
SOBUNIX basados en el System V y FFS en los SOBUNIX basados en BSD. Posteriormente, el auge
de las redes de comunicación conduj o al desarrollo de sistemas de archivos en red, como RFS de AT &T
o NFS de Sun Microsystems, lo que hizo que algunos SOBUNIX fuesen adaptados para poder soportar­
los. Asimismo, también existía en la comunidad de SUBONIX el deseo de poder soportar sistemas de
archivos nativos de otros sistemas operativos, como FAT de MS-DOS , para así acceder a la información
de las particiones de discos duros o disquetes formateadas con estos sistemas de archivos.
Con el fin de dar soporte a diferentes tipos de sistemas de archivos en 1 985 Sun Microsystems
introdujo en el núcleo de Sun OS 2.0 una capa de software conocida en la literatura como sistema
de archivos virtual (Virtual File S ystem, VFS) o capa nodo virtual (nodo-v)fsistema de archivos virtual
(SAV). Debido a su eficiencia, flexibilidad y elegancia la capa nodo-v/SAV ha sido adoptada por muchos
SOBUNIX: gestión de archivos
y
gestión de la E/S
203
SOBUNIX, aunque cada uno la implementa de distinta forma.
La capa nodo-v/SAV permite aislar los detalles de la implementación de cada tipo de sistema de
archivos del resto del núcleo, lo que simplifica su diseño. Cualquier operación sobre un archivo o sobre un
sistema de archivos completo invocada por el usuario a través de una llamada al sistema o internamente
por algún subsistema del núcleo es redireccionada por la capa nodo-v/SAV hacía la rutina dependiente
del sistema de archivos al que pertenezca el archivo que da soporte a dicha operación. Obviamente, el
núcleo de cada SOBUNIX debe disponer, por cada tipo de sistema de archivos que soporte, de las rutinas
que implementan las operaciones sobre dicho sistema de archivos.
En definitiva la capa nodo-v/SAV permite descomponer las operaciones sobre un archivo en dos
partes : una independiente del tipo de sistema de archivos y otra dependiente del tipo de sistema de
archivos. La capa nodo-v/SAV es la interfaz que permite el paso entre ambas partes (ver Figura 5 .5).
Interfaz de llamadas al sistema
(read ( )
Funciones independientes
del tipo de sistema de archivos
1
wri te ( )
1
open ( )
1
mount ( )
1
•
•
•
)
Capa nodo-v/SA V
Funciones
dependientes
de un sistema
UFS
Funciones
dependientes
de un sistema
FAT
Figura 5.5 -
- - - - - -
Funciones
dependientes
de un sistema
ISO 9660
Capa nodo-v /SAV
La capa nodo-v/SAV trabaj a con dos tipos de estructuras de datos básicas : los nodos-v y los sistemas
de archivos virtuales. La implementación y gestión de estas estructuras depende de cada S OBUNIX.
5.3.1.
Nodos virtuales
Un nodo virtual o nodo-v es una estructura de datos que representa a un archivo activo. El núcleo
asigna un nodo-v cuando se crea o se abre un archivo durante el tratamiento de las llamadas al sistema
c r e a te u open. El descriptor del archivo tiene un puntero al objeto de archivo abierto, el cual tiene a su
vez un puntero al nodo-v asociado al archivo (ver Figura 5 . 1 ) .
Nótese que s i dos procesos A y B abren e l mismo archivo ( o s i el mismo proceso abre dos veces el
mismo archivo) existirán dos descriptores de archivos y dos estructuras de objeto abierto distintas, pero
solo una estructura nodo-v. El nodo-v mantiene un contador de referencias con el número de estructuras
de datos que lo referencian. En este caso el contador de referencias contendrá el valor 2. Si un proceso
ejecuta una llamada al sistema e l o s e sobre dicho archivo el contador de referencias se decrementará en
una unidad.
En general cada vez que el núcleo referencia, a través de alguna de sus estructuras de datos, al nodo­
Y de un archivo se incrementa en una unidad el contador de referencias del nodo-v. Por el contrario,
204
Ampliación de sistemas operativos
cuando el núcleo elimina una referencia al nodo-v el contador de referencias se decrementa en una
unidad. Solo cuando el contador de referencias de un nodo-v toma el valor O entonces el nodo-v puede
ser desasignado (liberado) y las estructuras de datos (nodo-i) y bloques de datos del archivo cargadas en
memoria principal pueden ser eliminadas. Si bien dicha eliminación no se realiza de forma inmediata
sino que se demora en el tiempo por si el archivo vuelve a ser abierto en un futuro próximo. De esta
forma se evita tener que leer de nuevo en el disco el nodo-i y los bloques de datos del archivo.
Aparte de la apertura de un archivo existen otras circunstancias en las que es necesario asignar un
nuevo nodo-v o referenciar a un nodo-v ya creado, y en consecuencia incrementar su contador de refe­
rencias [Vahalia, 1 995] :
•
Un proceso mantiene una referencia al nodo-v de su directorio de trabajo actual. Cuando un pro­
ceso cambia su directorio de trabajo tiene que referenciar al nodo-v del nuevo directorio de trabaj o
y eliminar l a referencia a l nodo-v del directorio d e trabaj o antiguo.
•
Cuando se monta un nuevo sistema de archivos se crea una referencia al nodo-v del directorio
utilizado como punto de montaje.
•
Cuando el núcleo analiza un nombre de ruta absoluta o relativa introducido como argumento de
alguna llamada al sistema o comando tiene que referenciar al nodo-v de cada directorio intermedio
que aparece en la ruta. Dicha referencia se crea para poder buscar en un directorio. Cuando termina
la búsqueda en dicho directorio la referencia a su nodo-v se elimina.
La principal función del nodo-v asociado a un archivo es la de redireccionar las operaciones que se
vayan a realizar sobre el archivo hacía las rutinas dependientes del tipo de sistema de archivos al que
pertenece el archivo que implementan dichas operaciones. Por ejemplo, en Solaris la invocación de una
llamada al sistema read sobre un archivo previamente abierto perteneciente a un sistema de archivos
UFS hace que se invoque a la operación virtual VOP_ READ ( ) del nodo-v la cual invoca a su vez a
la función u f s_read ( ) . VOP_ READ ( ) es una función independiente del tipo de sistema de archivos
mientras que u f s_ read ( ) es la función que implementa dicha operación en los sistemas tipo UFS .
La estructura que implementa un nodo-v suele contener, entre otros, los siguientes datos:
•
Contador de referencias. Indica el número de estructuras de datos del núcleo que referencian al
nodo-v.
•
Tipo de nodo-v. Coincide con el tipo de archivo al que está asociado el nodo-v: archivo regular,
directorio, archivo de dispositivo modo bloque, etc.
•
Puntero a una estructura de datos dependiente del tipo de sistema de archivos. Dicha estructura
se denomina de forma general como nodo índice (nodo-i) y la información que contiene depende
de cada tipo de sistema de archivos. Por ejemplo, para un archivo perteneciente a un sistema de
archivos S 5FS o UFS el nodo-i contiene los atributos del archivo y la localización en el disco de los
bloques de datos del archivo. En este caso el nodo-i asociado al archivo al que apunta un nodo-v es
una copia en memoria principal del nodo-i almacenado en el disco. El tamaño que ocupa la copia
SOBUNIX: gestión de archivos y gestión de la E/ S
205
de un nodo-i en memoria principal es mayor que el tamaño del nodo-i en el disco, ya que contiene
más información, como por ejemplo, un puntero al nodo-v y el número de nodo-i del archivo.
•
Puntero al vector de operaciones sobre un archivo. El vector de operaciones sobre un archivo es
un array de punteros a funciones dependientes del tipo de sistema de archivos al que pertenece el
archivo. Estas funciones implementan todas las posibles operaciones sobre un archivo.
•
Lista de páginas del archivo cargadas en la memoria principal. Esta lista se consulta cuando el
contador de referencias del nodo-v toma el valor O para localizar y eliminar de memoria principal
las páginas del archivo. Puesto que el archivo ya no está activo puede ser eliminado de la memoria
principal.
.--------------------------... - - - ... - - - -------------------------------- - -------- - ----------------
s t ruct vnode op s
u f s_ c r e a t e ( )
u f s _open ( )
u f s_c l o s e ( )
u f s read ( )
u f s _wr i t e ( )
D Bloques
O de datos
O del archivo
Vector de operaciones del archivo
s t ru c t
inode
Partición de disco duro
Sistema de archivos UFS
nodo-i
--------- - - - - - - - - - - - - - - - - - - - - - ---- - --------- - -- - - - - - - - - - - - - - - - - - - - - - - - - -- - --- - - - --- - - - - - - - - - J
Estructuras en memoria principal
Figura 5.6 -
e
Implementación de un nodo-v en Solaris
Ejemplo 5 . 8
En Solaris un nodo-v (ver Figura 5 .6) se implementa con una estructura vnode que contiene, entre otros,
los siguientes campos :
•
v_type . Contiene el tipo del nodo-v, como por ejemplo: VREG (archivo regular), VD I R (directorio),
VBLK (dispositivo modo bloque), VCHR (dispositivo modo carácter), etc.
•
v_c ount. Contador de referencias.
206
Ampliación de sistemas operativos
•
v_op. Puntero al vector de operaciones virtuales sobre el archivo. Dicho vector se implementa con
una estructura vnodeop s , entre las funciones virtuales que se pueden invocar se encuentran las
siguientes: vop_open ( ) , vop_read ( ) , vop_wr i t e ( ) , vop_c l o s e ( ) , etc.
•
v_data. Puntero a una estructura de datos dependiente del tipo de sistema de archivos, es decir, a
un nodo-i.
•
v_v f sp. Puntero a la estructura v f s asociada al sistema de archivos al que pertenece el archivo.
•
v_mount edhere. Puntero a la estructura v f s asociada al sistema de archivos montado en este
directorio, si existe alguno.
•
v_page s . Lista de páginas del archivo cargadas en memoria.
•
5.3.2.
Sistemas de archivos virtuales
Un sistema de archivos virtual (SAV) es una estructura de datos que representa a un sistema de
archivos activo. El núcleo asigna un SAV cuando se monta un sistema de archivos y lo desasigna cuando
lo desmonta.
La principal función del SAV asociado a un sistema de archivos archivo es la de redireccionar las
operaciones que se vayan a realizar sobre el sistema de archivo hacía las rutinas dependientes del tipo de
sistema de archivos que implementan dichas operaciones. Por ejemplo, en Solaris la invocación de una
llamada al sistema mount para montar un cierto sistema de archivos UFS , hace que se le asigne un SAV
y que se invoque al procedimiento v f s_ mount ( ) del SAV, que es una función independiente del tipo
de sistema de archivos. A su vez esta función invoca a la función u f s_mount ( ) que implementa esta
operación en un sistema de archivos tipo UFS .
La estructura que implementa un SAV suele contener, entre otros, los siguientes datos:
•
Puntero al siguiente SAV. El núcleo mantiene una lista con todos los SAV montados.
•
Puntero al vector de operaciones sobre el sistema de archivos. El vector de operaciones sobre
un sistema de archivos es un array de punteros a funciones dependientes del tipo de sistema de
archivos que implementan todas las posibles operaciones sobre dicho sistema de archivos.
•
Puntero a una estructura de datos dependiente del tipo de sistema de archivos.
•
Puntero al nodo-v del punto de montaje.
•
Tipo de sistema de archivos. Coincide con el tipo de sistema de archivos al que está asociado el
SAV y que debe ser alguno de los soportados por el núcleo: S5FS , UFS , NFS , EXT2, FAT, etc.
Recuérdese que cada SOBUNIX establece los tipos de sistemas de archivos que soporta.
SOBUNIX : gestión de archivos y gestión de la E/ S
e
207
Ejemplo 5 .9
En Solaris un SAV se implementa con una estructura v f s . Esta estructura, contiene entre otros, los
siguientes campos :
•
vf s_next . Puntero a la siguiente estructura v f s de la lista de sistema de archivos montados. Esta
lista se implementa como una lista enlazada de estructuras v f s . La variable global r o o t v f s apun­
ta a la primera estructura vf s de la lista que siempre corresponde al sistema de archivo principal,
es decir, el que se monta sobre el directorio raíz 1
'
•
'.
v f s_ f s typ e . Tipo del sistema de archivos montado. E n Solaris s e soportan sistemas d e archivos
en discos (UFS , ZFS, UDF, PCFS, HSFS , VxFS , QFS , . . ), sistemas de archivos en red (NFS) y
pseudosistemas de archivos mantenidos en la memoria principal (procfs, swapfs, tmpfs, . . . ) .
•
vf s_op . Vector de operaciones sobre el sistema de archivos.
•
v f s_data. Puntero a una estructura de datos dependiente del sistema de archivos .
•
vf s_vnodec overed. Puntero a l nodo-v del directorio punto d e montaje.
En la Figura 5.7 se muestra una posible configuración del inicio de la lista de sistemas de archivos
montados de un sistema Solaris. La variable global r o o tv f s apunta a la primera estructura v f s de la
lista que está asociada al sistema de archivos principal o raíz que es de tipo UFS . A su vez esta estructura
contiene un puntero a la siguiente estructura v f s de la lista asociada a un sistema de tipo NFS .
s t ruct vf s
s t ru c t v f s
rootvf s
...,.
-
v f s next
v f s _ f s typ e
�
v f s_op
v f s data
v f s data
-
...
:
SAV
SAV
s t ru c t vf s op s
s t ruct vf sop s
u f s _mount ( )
n f s _mount ( )
u f s _unmount ( )
n f s _unmount ( )
:
Vector de operaciOnes del
sistema de archivos principal
de tipo UFS
Figura 5.7 -
----
v f s _ f s type
v f s _op
:
-
v f s next
:
Vector de operaciones de un
sistema de archivos tipo NFS
Posible configuración del inicio de la lista de sistemas de archivos montados de un sistema
Solaris
•
208
5.3.3.
Ampliación de sistemas operativos
Análisis de nombres de rutas en SOBUNIX
Algunas llamadas al sistema, como open, creat o exe c , tienen entre sus argumentos de entrada
el nombre de ruta absoluta o relativa de un archivo. El núcleo tiene que analizar dicha ruta para poder
localizar el nodo-v del archivo y así poder invocar a la función dependiente del tipo de sistema de archivos
que implementa la operación de la llamada al sistema.
El análisis de cada componente de la ruta requiere localizar el nodo-v de su directorio padre y buscar
en su lista de archivos y subdirectorios la entrada asociada a la componente. Nótese que la búsqueda en la
lista del directorio se implementa con una función dependiente del tipo de sistema de archivos por ello es
necesario localizar el nodo-v del directorio padre del componente. Dicha entrada, aparte del nombre del
componente, que es el que se utiliza para buscar, contiene el número del nodo-i asociado al componente.
Si dicho nodo-i está cargado en memoria entonces tendrá asignado un nodo-v, en caso contrario hay que
cargarlo y asignarle uno.
e
Ejemplo 5 . 10
El nombre de ruta absoluta 1 d i r l 1 archi vol contiene tres componentes: el directorio raíz ! el di­
rectorio di r l y el archivo archi vo l . Supóngase que el análisis de este nombre de ruta absoluta se
realiza en Solaris. La función del núcleo l o okuppn ( ) es la encargada de analizar un nombre de ruta
de un archivo o directorio. Esta función lee la variable r o o t d i r para localizar el nodo-v del directorio
raíz e invoca una operación VOP_LOOKUP sobre el nodo-v lo que produce la invocación de la función
apropiada dependiente del sistema de archivos. Supuesto que se trata de un sistema de archivos UFS se
invocaría a la función u f s_l o o kup ( ) .
'
',
Esta función, a partir del nodo-i del directorio raíz, localiza los bloques de datos que contienen la lista
de archivos y subdirectorios del directorio, y busca en ella la existencia de una entrada para el directorio
di r l . Si la encuentra, entonces dicha entrada contiene el número del nodo-i asociado a di r l . Si dicho
nodo-i ya estaba cargado en memoria entonces tendrá un nodo-v asignado y se incrementa su contador de
referencias. Si el nodo-i no estaba cargado en memoria entonces se creará y se le asignará un nodo-v. La
función u f s_lookup ( ) devuelve a l o okuppn ( ) un puntero al nodo-v de / di r l . Si u f s_l o okup ( )
no encuentra la entrada entonces devuelve un error a l o o kuppn ( ) .
A continuación l ookuppn ( ) decrementa el contador de referencias del nodo-v asociado al directo­
rio raíz, ya que ya ha terminado de trabaj ar con él, e invoca una operación VOP_LOOKUP sobre el
nodo-v del directorio / di r l la cual produce la invocación de la función u f s_ l o okup ( ) para buscar
la existencia de una entrada asociada al archivo archi vo l en la lista del directorio di r l . El funciona­
miento de esta función es idéntico al descrito en el párrafo anterior. Si se encuentra la entrada entonces
uf s_l o o kup ( ) devuelve a l o o kuppn ( ) un puntero al nodo-v de 1 d i r l 1 archi vo l .
Finalmente l o o kuppn ( ) decrementa el contador de referencias del nodo-v asociado al directorio 1 d i r l
y devuelve u n puntero a l nodo-v d e 1 d i r l 1 archi vo l a la rutina del núcleo que la había invocado .
•
Para reducir el número de lecturas en disco y el tiempo de búsqueda de entradas en directorios, los
SOBUNIX implementan una caché de búsqueda de nombres en directorios. Se trata de una caché de
estructuras de datos que se implementa en el espacio de direcciones del núcleo. Cada estructura de datos
SOBUNIX: gestión de archivos y gestión de la E/S
209
de la caché contiene, entre otros, los siguientes datos sobre una entrada de un directorio recientemen­
te accedida: un puntero al nodo-v del directorio y el nombre y un puntero al nodo-v de un archivo o
subdirectorio contenido en dicho directorio.
Cuando el núcleo tiene que buscar la entrada de un archivo o subdirectorio determinado dentro de
la lista de un directorio, primero busca la existencia de dicha entrada en la caché. En caso de acierto se
ahorra el tiempo de leer en disco el bloque de datos que contiene la lista del directorio y buscar dentro
de la lista. En general la implementación y gestión de esta caché depende de cada S OBUNIX.
El sistema de archivos UFS
5.4.
5.4.1.
Características principales
UFS (UNIX File System, sistema de archivos UNIX) es un sistema de archivos soportado por di­
versos SOBUNIX, como por ejemplo: Solaris, FreeBSD y A/UX. El sistema UFS deriva del sistema de
archivos FFS de BSD, el cual en su momento supuso una auténtica revolución dentro de los SOBUNIX
los cuales utilizaban el sistema de archivos S5FS que tenía limitaciones importantes.
Las características principales de un sistema de archivos UFS son las siguientes:
•
Trabaj a con un tamaño de bloque de datos de 4 KiB o 8 KiB . Además para reducir la fragmentación
interna cada bloque se divide en fragmentos que pueden ser asignados individualmente. De esta
forma la fragmentación interna promedio pasa de ser de medio bloque a medio fragmento. Tanto el
tamaño de bloque como el número de fragmentos ( 1 , 2, 4 o 8) se fij a al crear el sistema de archivos.
•
Tiene en cuenta la geometría del disco a la hora de alojar los nodos-i y los bloques de datos de
los archivos. Con ello se consigue mejorar el rendimiento del sistema ya que se reduce el tiempo
de búsqueda de las cabezas de lectura/escritura del disco, y en consecuencia, el tiempo de las
operaciones de E/S .
•
Por motivos de seguridad mantiene varias copias del superbloque, que es una estructura de da­
tos que contiene información administrativa y estadística de todo el sistema de archivos . Si solo
existiese una copia del superbloque, como pasaba en los sistemas de archivos S5FS , y ésta se
corrompiera debido algún error en el disco todo el sistema de archivos quedaría inutilizado.
•
Las entradas de los directorios son de tamaño variable y pueden ser compactadas para reducir la
fragmentación. El nombre de un archivo puede tener hasta 255 caracteres.
•
Soporta enlaces simbólicos los cuales pueden ser creados con la llamada al sistema syml ink.
•
Soporta la llamada al sistema rename que permite renombrar de forma atómica a un archivo o
directorio. Con el uso de r ename se evita tener que invocar primero a la llamada al sistema l i nk
para crear un enlace duro que establezca el nuevo nombre del archivo y a continuación usar la
llamada al sistema un l ink para borrar el enlace duro que establecía el nombre antiguo.
210
Ampliación de sistemas operativos
Conviene señalar que cada S OBUNIX implementa UFS de una determinada forma y con diversas
extensiones, las cuales influyen en su portabilidad ya que dichas extensiones solo son reconocidas úni­
camente por el SOBUNIX que las introduce. Por ejemplo Solaris, implementa UFS logging que permite
implementar la técnica de registro por diario (journaling) en los sistema de archivos UFS de Solaris.
5.4.2.
Estructura de un sistema de archivos UFS
Un sistema de archivos UFS presenta la siguiente estructura en la partición de disco donde se crea
(ver Figura 5 . 8):
•
Á rea de arranque. Se sitúa al principio de la partición. Contiene el código necesario para arrancar
el SOBUNIX si dicha partición se usa como partición activa.
•
Superbloque. Se sitúa a continuación del área de arranque. Es una estructura de datos que contiene
información estadística y administrativa del sistema de archivo, como por ejemplo: un número
mágico que identifica al sistema como de tipo UFS , el número, el tamaño y la localización de los
grupos de cilindros, el tamaño de bloque de datos que se utiliza, el número total de bloques de datos
y de nodos-i, etc. Esta información se configura al crear el sistema de archivos en la partición.
•
Grupos de cilindros. Un grupo de cilindros está formado por un conjunto de cilindros contiguos.
El número de grupos de cilindros (NG) y el número de cilindros que contiene un grupo son confi­
gurados cuando se crea el sistema de archivos UFS . Cada grupo de cilindro contiene la siguiente
información:
- Una copia del superbloque. La información que contiene el superbloque es fundamental para
poder operar con el sistema de archivos. En previsión de la aparición de posibles errores en
el disco el superbloque se replica en cada grupo de cilindros. La ubicación de la copia del
superbloque en cada grupo de cilindros se elige cuidadosamente para evitar que todas las
copias se encuentren en la misma superficie o plato del disco.
- Estructura de grupo de cilindros. Contiene información estadística y administrativa del grupo
de cilindros.
- Mapas de bits. Especifica cuales son los bloques, fragmentos y nodos-i libres en el grupo de
cilindros.
- Nodos-i del grupo de cilindros. Cada nodo-i tiene un tamaño de 128 bytes y almacena los
atributos del archivo. También almacena la localización de los bloques de datos de un archivo.
En concreto contiene 1 5 direcciones de bloques de disco de 32 bits cada. Las 12 primeras
direcciones son las de los 1 2 primeros bloques de datos del archivo, también denominados
bloques directos. Las tres direcciones restantes localizan a un bloque de indirección simple,
un bloque de indirección doble y un bloque de indirección triple, respectivamente.
- Bloques de datos del grupo de cilindros. Contienen los datos propiamente dichos de los
archivos.
SOBUNIX: gestión de archivos
y
gestión de la E/ S
211
Partición de disco
Arranque
Superbloque
Grupo de cilindro
NG- 1
Grupo de cilindro
o
- - - - - - - - - - - - - -
Mapa de bits
o de cil indro
Figura 5.8
5.4.3.
-
Nodos-i
Bloques de datos
Estructura de un sistema de archivos UFS
Implementación de directorios en UFS
En un sistema de archivos UFS la lista de archivos y subdirectorios de un directorio se implementa
con entradas de tamaño variable. En cada entrada se almacena la siguiente información: número de
nodo-i, longitud en bytes de la entrada, longitud en bytes del nombre, el nombre del archivo, un carácter
nulo para marcar el final del archivo y los caracteres nulos de relleno necesarios hasta alcanzar una
frontera de 4 bytes. El nombre de archivo en UFS puede tener un tamaño máximo de 255 caracteres.
Cuando se borra una entrada de un directorio, excepto si se trata de la primera, la entrada anterior se
expande hasta ocupar el espacio que tenía asignado la entrada borrada. Esta forma de proceder ayuda a
reducir la fragmentación.
e
Ejemplo 5 . 1 1
En l a Figura 5 .9a s e muestra u n ejemplo de l a implementación de u n directorio e n u n sistema UFS . El
directorio consta de 4 entradas : la primera asignada a la entrada ' . ', la segunda a la entrada " . . ", la
tercera asignada al archivo prueba y la cuarta asignada al archivo f o t o s . Las dos primeras entradas
tienen un tamaño de 1 2 bytes, mientras que las dos últimas tienen un tamaño de 1 6 bytes. Se observa
como el nombre de una entrada siempre termina con un carácter nulo \ o seguido de tantos caracteres
nulos como sean necesarios hasta completar una frontera de 4 bytes.
'
'
En la Figura 5 .9b se muestra el estado del directorio después de borrar el archivo f o t o s . Se observa
como la entrada del archivo prueba ha sido expandida hasta ocupar el espacio que tenía asignado la
entrada borrada.
•
212
Ampliación de sistemas operativos
Longitud entrada (2 bytes)
Longitud nombre (2 bytes)
N° nodo-i (4 bytes)
Nombre + caracteres de relleno
+
\0 \0 \0
\0 \0
35
12
1
36
12
2
51
16
6
p
r
u
e
b
15
16
5
f
o
t
o
S
\0 \0
\0 \0 \0
a
(a)
35
12
1
36
12
2
\0 \0 \0
\0 \0
\0 \0
\0 1 \0 1 \0 1 \0 \o 1 \o \o 1 \o \0 \0 \0 \0 \0 \0 \0 \0
51
16
p
6
r
u
e
b
a
(b)
Figura 5.9 - Implementación de
un directorio en UFS : (a) Estado inicial. (b) Después de borrar el archivo
fotos
5.4.4.
Gestión de un sistema UFS
Nodos-i
El núcleo para poder trabajar con un archivo, aparte de asignarle un nodo-v, necesita tener cargado
en la memoria principal el nodo-i asociado al archivo, ya que contiene los atributos y la localización de
sus bloques de datos. El núcleo copia el contenido de un nodo-i en una estructura de datos que crea en
su espacio de direcciones. El nombre que recibe dicha estructura depende de cada SOBUNIX, el cual lo
asigna en función del tipo de sistema de archivos. En lo que resta de sección se denotará por nodo-im a
la estructura de datos de memoria principal que contiene una copia de un nodo-i del disco duro.
En un nodo-im, aparte de una copia de un nodo-i, también se almacenan, entre otros, los siguientes
datos: un puntero al nodo-v asociado al nodo-im, punteros para colocar al nodo-im en una de las colas
hash que mantiene el núcleo en función del número de nodo-i para localizar a los nodos-im, y punteros
para colocar al nodo-im en una lista de nodos-im libres.
El núcleo coloca a un nodo-im en la lista de nodos-im libres si el contador de referencias de su nodo­
v asociado alcanza el valor O. La posición de la lista en que coloca al nodo-im depende de si la lista de
páginas de nodo-v está vacía o contiene alguna página. Por ejemplo, dependerá de cada SOBUNIX, si
SOBUNIX : gestión de archivos
y
gestión de la E/ S
213
está vacía entonces el núcleo coloca al nodo-im al principio de la lista de nodos-im libres. Por el contrario
si contiene alguna página lo coloca al nodo-im al final de la lista.
Si el núcleo no localiza a un nodo-im en la cola hash en que le correspondería estar en función de su
número de nodo-i, entonces eso significa que dicho nodo-i no está cargado en memoria. En ese caso el
nodo-i debe ser copiado en un nodo-im. El núcleo selecciona para ello al primer nodo-im de la lista de
nodos-i libres.
e
Ejemplo 5 . 12
En Solaris la estructura de datos que implementa un nodo-im de un archivo de un sistema UFS se deno­
mina inode. Esta estructura contiene, entre otros, los siguientes campos :
•
i_forw. Puntero a l siguiente nodo-im d e la cola d e hash a l a que pertenece este nodo-im.
•
i_backw. Puntero al anterior nodo-im de la cola de hash a la que pettenece este nodo-im.
•
i_free f . Puntero al siguiente nodo-im de la lista de nodos-im libres.
•
i f reeb. Puntero al anterior nodo-im de la lista de nodos-im libres.
•
i c ommon. Estructura de datos donde se copian los datos de un nodo-i del disco. Entre otros con­
tiene los siguientes campos :
- i c_smode. Máscara d e modo del archivo que establece el tipo y los permisos d e acceso. Se
distinguen, entre otros, los siguientes tipos: archivo regular (I FREG), directorio ( I F D I R) ,
enlace simbólico ( I FLNK), dispositivo modo bloque ( I FBLK), dispositivo modo carácter
( I FCHR), tuberías ( I F I FO) y sockets ( I F SOCK). Este campo toma el valor O si el nodo-i
está libre, es decir, no está asociado a ningún archivo.
- i c _nl ink. Número de enlaces duros.
- i c_su i d. UID del propietario del archivo.
- i c_sgid. GID del grupo propietario del archivo.
- i c_l s i z e . Tamaño del archivo en bytes.
- i c_a t ime . Fecha y hora del último acceso al archivo.
- i c_mt ime . Fecha y hora de la última modificación del archivo.
- i c_c t ime . Fecha y hora de la última modificación de algún campo del nodo-i asociado al
archivo.
- i c_db. Direcciones de los 12 primeros bloques de datos del archivo (bloques directos).
i c_ib. Direcciones de los tres bloques de indirección (simple, doble y triple).
•
i_vnode. Puntero al nodo-v asociado al nodo-i.
•
i_dev. Número de dispositivo físico en que reside el nodo-i.
214
Ampliación de sistemas operativos
•
i_nurnber. Número del nodo-i.
En la Figura 5 . 1 0 se muestra un ejemplo de un posible estado de las colas hash de nodos-im y de la lista
de nodos-im libres de un sistema UFS en Solaris. En este ejemplo se ha considerado que el número de
colas hash implementadas es N=3 (j = O, 1 , 2) y que la función hash utilizada para colocar a los nodos-im
en las colas hash es J= i_nurnbe r %N. Se observa que en la cola hash j = O se encuentran los nodos-im
90 y 1 32, en la cola hash j = 1 los nodos-im 1 1 5, 9 1 , 1 27 y 1 30, y en la cola hash j = 2 se encuentran
los nodos-im 1 34, 1 3 1 y 86. Además los nodo-im 1 32, 1 1 5 y 1 3 1 forman parte de la lista de nodos-im
libres.
•
Cabecera
lista
nodos-i
libres
t
1o
o
o
•
Cabecera
cola hash
j=O
struct
inode
struct
ino de
132
90
..
!
o
¡---------------------------J
1
..
Cabecera
cola hash
j=l
struct
inode
115
,---------------------------o
o
struct
ino de
91
struct
ino de
127
struct
ino de
130
..
1
:
·---------------------------,
1
11--------------------------,
:o
o
•
Cabecera
cola hash
j=2
Figura 5.10 -
struct
inode
1 34
struct
ino de
13 1
struct
inode
86
Colas hash de nodos-im y lista de nodos-im libres de un sistema UFS en Solaris
SOBUNIX: gestión de archivos
y
gestión de la E/S
215
Asignación de espacio
En un sistema de archivos UFS el tamaño de un bloque de datos puede ser de 4 KiB o 8 KiB . Además
los bloques se pueden dividir en un número prefij ado de fragmentos: 1 , 2, 4 o 8. El tamaño mínimo que
puede tener un fragmento queda limitado por el tamaño de un sector del disco. Tanto el tamaño de bloque
como el número de fragmentos se configuran al crear un sistema de archivos UFS .
Cada fragmento de un bloque puede ser direccionado y asignado individualmente, esto implica sus­
tituir la lista de bloques libres por un mapa de bits que registre los fragmentos libres y los asignados.
Todos los bloques de datos de un archivo o directorio deben ocupar bloques de datos completos en el
disco. El último bloque del archivo puede estar totalmente lleno o solo ocupar uno o varios fragmentos
contiguos del bloque. Los fragmentos libres del último bloque de un archivo pueden ser utilizados para
alojar los fragmentos del último bloque de datos de otro archivo.
Con esta forma de asignación se consigue reducir la fragmentación interna promedio a medio frag­
mento por archivo. Sin embargo pueden afectar al rendimiento del sistema ya que produce operaciones
de copia adicionales cuando un archivo crece de tamaño. Por ejemplo, supóngase un bloque de disco X
que tiene cuatro fragmentos, uno de ellos está asignado al último bloque de un archivo A y los otros tres
al último bloque de un archivo B . Si el archivo A incrementa su tamaño en un fragmento el núcleo tendrá
que buscar un bloque Y que contenga dos fragmentos consecutivos libres y copiar en él el fragmento del
archivo A que estaba en el bloque X.
Por otra parte, el núcleo con objeto de reducir los tiempos de búsqueda en disco sigue las siguientes
reglas para ubicar en el disco los bloques de datos y los nodos-i de un archivo o directorio en un sistema
de archivos UFS [Vahalia, 1 995 ] :
•
Los nodos-i d e todos los archivos pertenecientes a u n mismo directorio s e intentan colocar e n un
mismo grupo de cilindros. Con esta medida se tiene en cuenta que los usuarios suelen trabaj ar
normalmente con los archivos de su directorio de trabajo, y que algunos comandos, como por
ejemplo l s , trabajan con los nodos-i de todos los archivos de un mismo directorio.
•
Cuando se crea un nuevo directorio éste se intenta ubicar en un grupo de cilindros diferente al de
su directorio padre. De esta forma los datos se distribuyen de manera uniforme por el disco.
•
Los bloques de datos de un archivo se intentan colocar en el mismo grupo de cilindros donde está
ubicado su nodo-i, ya que normalmente se suelen acceder de forma conjunta.
•
Los bloques directos de un archivo se aloj an en un grupo de cilindros y luego se va cambiando de
grupo de cilindros cada M bloques. El valor M es configurado al crear el sistema de archivos. De
esta forma los datos se distribuyen de manera uniforme por el disco y además se evita llenar por
completo un grupo de cilindros con un archivo de gran tamaño.
•
Los bloques de datos de un archivo se intentan colocar en posiciones rotacionales óptimas teniendo
en cuenta el factor de entrelazado del disco.
216
Ampliación de sistemas operativos
5.5.
Gestión de la E/S en SOBUNIX
5.5.1.
Perspectiva general
En los SOBUNIX los dispositivos de E/S son clasificados en dos grandes categorías :
•
Dispositivos modo bloque. Son aquellos que almacenan la información en bloques de tamaño fijo,
normalmente 5 1 2 bytes o una potencia de dos múltiplo de la anterior. Estos bloques pueden ser
accedidos de forma secuencial o aleatoria. Ejemplos de dispositivos modo bloque son los discos
(magnéticos u ópticos) y las cintas magnéticas.
•
Dispositivos modo carácter. Son aquellos que envían o reciben información como una secuencia
o flujo lineal de bytes. En ellos la información no se organiza con una estructura concreta, por lo
que no es direccionable y en consecuencia no permite la realización de operaciones de búsqueda.
Ejemplos de dispositivos modo carácter son las impresoras, el ratón, el teclado y el módem.
En los SOBUNIX si un dispositivo no encaj a como dispositivo modo bloque entonces se considera
que es un dispositivo modo carácter, independientemente de que tenga las características de este tipo de
dispositivos. Por ejemplo, el reloj hardware no tiene las características de un dispositivo modo bloque ni
las de un dispositivo modo carácter. Luego de acuerdo con el criterio establecido en los SOBUNIX el
reloj hardware se considera un dispositivo modo carácter.
Los SOBUNIX también soportan el uso de pseudodispositivos que son aquellos que se implementan
por software. Ejemplos de pseudodispositivos son el dispositivo nulo, que es un agujero de negro de bits,
y el dispositivo cero, que llena de ceros las paginas de memoria cuya dirección se le suministra como
entrada.
Los SOBUNIX integran los dispositivos de E/S dentro del sistema de archivos principal, general­
mente en el directorio 1 dev, para ello asignan a cada dispositivo un archivo de dispositivo modo bloque
o modo carácter. Esta integración permite operar con los dispositivos de E/S usando las mismas llamadas
al sistema que se utilizan para operar sobre los archivos : open, r ead, wr i t e , etc.
El subsistema de E/S es el componente del núcleo encargado de gestionar las operaciones con los
dispositivos de E/S . Para comunicarse con el controlador de E/ S, el subsistema de E/ S utiliza un código
especifico por cada dispositivo denominado driver del dispositivo. Los drivers son suministrados por los
fabricantes de los dispositivos de E/S existiendo una distribución por cada sistema operativo con lo que
puede funcionar el dispositivo. Los drivers envían órdenes a los controladores de E/ S de los dispositivos
para especificarles la operación que desean realizar. Cuando un dispositivo termina una operación de
E/S, el controlador de E/S del dispositivo avisa al driver correspondiente mediante la generación de
una interrupción. Para atender a dicha interrupción el núcleo invoca al manejador de la interrupción
apropiado.
SOBUNIX : gestión de archivos y gestión de la E/S
5.5.2.
217
Archivos de dispositivos
Número de dispositivo mayor y número de dispositivo menor
En los SOBUNIX cada dispositivo de E/S tiene asignado, en función de su tipo, un archivo de
dispositivo modo bloque o un archivo de dispositivo modo carácter. Recuérdese que la máscara de modo
del archivo que se almacena en el nodo-i del archivo contiene el tipo del archivo. Todos los archivos de
dispositivos generalmente suelen encontrarse aloj ados dentro del directorio 1 dev.
El contenido del nodo-i de un archivo de dispositivo, a diferencia del nodo-i de un archivo regular o
un directorio, no contiene las direcciones de los bloques de datos del archivo sino dos números enteros
positivos denominados : número de dispositivo mayor (major device number) y número de dispositivo
menor (minor device number) .
El número de dispositivo mayor permite identificar a una cierta clase de dispositivo y el número de
dispositivo menor a una instancia de dicho dispositivo.
Por otra parte, cada tipo de dispositivo (bloque o carácter) dispone de un conjunto independiente de
números de dispositivos mayores . Luego un mismo número de dispositivo mayor puede hacer referencia
a dispositivos distintos en función de si es un dispositivo modo bloque o modo carácter.
e
Ejemplo 5. 13
Un número de dispositivo mayor igual a 3 dentro del conjunto de dispositivos modo bloque puede re­
ferirse, por ejemplo, a un cierto tipo de disco duro conectado al computador. Por otra parte, dentro del
conj unto de dispositivos modo carácter un número de dispositivo mayor igual a 3 puede referirse a una
impresora.
Asimismo si existen dos discos duros iguales conectados al computador, tendrán asignado el mismo
número de dispositivo mayor (en este ejemplo 3), pero diferentes números de dispositivos menor, por
ejemplo: 1 y 2.
•
En conclusión en los SOBUNIX la tripleta [tipo de dispositivo, número mayor, número menor] iden­
tifica de manera unívoca a un dispositivo de E/S . Esta información se almacena en el nodo-i del archivo
de dispositivo que representa al dispositivo junto con el resto de atributos del archivo.
e
Ejemplo 5. 14
Supóngase que en un cierto SOB UNIX se representa a uno de los puertos serie del computador mediante
el archivo de dispositivo 1 dev 1 t tyS O . Supóngase además que si escribe en un intérprete de comandos
de este SOBUNIX la orden
ls
-1
/ dev / t tyS O
se muestra en la pantalla la siguiente salida:
c rw- rw- - - - 1 ro o t di a l ou t 4 ,
6 4 2 0 1 1 - 0 9 - 1 4 / dev / t tyS O
218
Ampliación de sistemas operativos
Analizando la información proporcionada por el comando se deduce que / dev / t tyS O es un archivo
asociado a un dispositivo modo carácter, su número de dispositivo mayor es igual a 4 y su número de
dispositivo menor es igual a 64.
•
Llamadas al sistema
La integración de los dispositivos de E/S dentro del sistema de archivos mediante el uso de archivos
de dispositivos permite operar con los dispositivos de E/ S usando las mismas llamadas al sistema que se
utilizan para operar con los otros tipos de archivos : open, read, wri t e , etc. Esta característica de los
S OBUNIX resulta de gran utilidad para los usuarios y los programadores, ya que pueden trabajar con los
dispositivos como si fuesen un archivo más. De esta forma solo necesitan conocer el nombre de ruta del
archivo de dispositivo y se evitan trabaj ar con la tripleta descriptiva del dispositivo que manej a el núcleo.
La creación de un archivo de dispositivo, a diferencia de los archivos regulares, no se realiza con la
llamada al sistema creat sino usando la llamada al sistema mknod, la cual permite crear cualquier tipo
de archivo. Esta llamada tiene la siguiente sintaxis:
r =mknod ( ruta , modo , dev ) ;
Donde ruta es el nombre de ruta absoluta o relativa del archivo que se va a crear y modo es la máscara de
modo del archivo. En el caso de que se desee crear un archivo de dispositivo hay que indicar su número
de dispositivo mayor y su número de dispositivo menor los cuales se codifican haciendo uso por ejemplo
de la macro makedev en una misma variable dev de tipo dev_t denominada número de dispositivo. Si
la llamada al sistema se ejecuta con éxito guarda el valor O en r . En caso de error guarda -l.
También existe un comando mknod que internamente utiliza la llamada al sistema homónima. Tanto
la llamada al sistema como el comando únicamente pueden ser utilizados por el superusuario, excepto
si se desea crear una tubería con nombre (ver sección 3 .5 .2), en cuyo caso pueden ser invocados por
cualquier usuario.
Existen unas pocas llamadas al sistema especiales que únicamente pueden usarse sobre los archivos
de dispositivos. Este es el caso por ejemplo de i o c t l .
Nodos-v y nodos-i d e archivos d e dispositivos
La implementación de los nodos-v y los nodos-i asociados a los archivos de dispositivos depende de
cada SOBUNIX. En algunos S OBUNIX, como por ejemplo SVR4, los nodos-i asociados a los archivos
de dispositivos se almacenan dentro de la partición de disco que contiene el sistema de archivos principal,
que será de un determinado tipo, por ejemplo UFS .
En esta implementación cuando el núcleo realiza una operación sobre el nodo-v de un archivo de
dispositivo, se redirecciona por defecto a una función dependiente del sistema de archivos principal. Por
ejemplo, una operación VO P_OPEN sobre el nodo-v de un archivo de dispositivo redirecciona, en el caso
de un sistema UFS , a la función u f s_open ( ) . Obviamente este no es el comportamiento deseado, sino
que se debe redireccionar a la función apropiada del driver del dispositivo.
SOBUNIX: gestión de archivos y gestión de la E/ S
219
Una de las soluciones adoptadas para resolver este problema consiste en usar una estructura de datos
adicional denominada nodo sombra (nodo-s) que se encarga de realizar esta redirección hacia las fun­
ciones del driver. Todas las operaciones sobre un archivo de dispositivo son redireccionadas a través de
su nodo-s, en vez de a través del nodo-v. Luego el nodo-s a todos los efectos oculta al nodo-v, de ahí
el nombre de nodo sombra. SVR4 usa el pseudosistema de archivos specfs para implementar todos los
nodos-s.
En otros SOBUNIX, como Linux, los nodos-i asociados a los archivos de dispositivos se crean en
tiempo de arranque y se almacenan en un pseudosistema de archivos, como por ejemplo tmpfs, que se
implementa únicamente en la memoria principal sin existir almacenamiento de respaldo en el disco. En
este esquema los nodos-i se integran dentro de los nodos-v. Con lo que solo es necesario mantener una
única estructura de datos asociada al archivo de dispositivo: su nodo-v2 . En dicha estructura existe un
puntero al vector de operaciones sobre el nodo-v el cual redirecciona dichas operaciones directamente
hacía las funciones del driver adecuadas.
5.5.3.
Subsistema de E/S
El subsistema de E 1 S es el componente del núcleo que se encarga de efectuar todas aquellas tareas
necesarias para la realización de las operaciones de E/S que son comunes a todos los dispositivos e inde­
pendientes de los mismos. Es decir, el subsistema de E/ S gestiona la parte independiente del dispositivo
de todas las operaciones de E/S . Entre las tareas que realiza se encuentran las siguientes : asignación y
protección de dispositivos, bloqueo de procesos en operaciones de E/S , planificación de la E/S, gestión
de los errores producidos en la E/S, gestión de los drivers de los dispositivos y almacenamiento temporal
de datos (buffering).
Con respecto al almacenamiento temporal de datos asociados a operaciones de E/ S en los SOBUNIX
se implementa una caché de buffers de bloques de disco. Se trata de un espacio reservado en la memoria
principal para almacenar los bloques de datos del disco accedidos recientemente. Cada bloque de datos se
almacena en un buffer de memoria principal. Para localizar rápidamente a los buffers el núcleo mantiene
varias colas hash de buffers a las que se accede en función del número de dispositivo y el número de
bloque.
Cuando el núcleo desea leer un bloque del disco, primero comprueba si existe dicho bloque en la
caché. En caso afirmativo el bloque es leído de la caché. En caso negativo, el bloque debe leerse en el
disco y cargarse en un buffer libre. Si no existe ningún buffer libre, deberá seleccionarse algún buffer
mediante el uso de algún algoritmo de reemplazamiento. En conclusión, con el uso de la caché de buffers
se pretende minimizar las operaciones de E/S a disco, las cuales son varios órdenes de magnitud más
lentas que los accesos a memoria principal.
En el caso de las operaciones de escritura primero se realizan sobre la caché. Periódicamente o si el
número de bloques escritos supera un cierto valor los bloques escritos son transferidos por el núcleo al
disco. Normalmente existe un proceso del sistema que se encarga de realizar esta tarea.
En los sistemas SOBUNIX modernos la operaciones de E/S sobre archivos se integran dentro de la
2En Linux no hacen uso de la terminología nodo-v, sino que directamente le denominan nodo-i.
220
Ampliación de sistemas operativos
memoria virtual. En estos sistemas la caché de buffers de bloques de disco se utiliza generalmente para
almacenar solo los bloques de datos que contienen metadatos de los sistemas de archivos o los archivos :
superbloque, nodos-i, bloques d e indirección simple, doble, etc. Por otra parte, los bloques d e datos
lógicos de un archivo son divididos en páginas. Cada página de un archivo puede contener, en función
del tamaño de bloque y del tamaño de página, parte de un bloque, un bloque o varios bloques de datos
del archivo. Estás páginas se cargan en la caché de páginas que se implementa en la memoria principal
la cual es gestionada por el subsistema de gestión de memoria principal del núcleo.
5.5.4.
Drivers de los dispositivos de E/S
Un driver de un dispositivo contiene el código que permite al núcleo controlar un determinado tipo
de dispositivo de E/S . Así, es necesario un driver para el ratón, otro para el teclado, otro para el disco
duro, etc. Los drivers son diseñados por los fabricantes de los dispositivos teniendo en cuenta las especi­
ficaciones de la interfaz de drivers del subsistema de E/ S del núcleo y las características del dispositivo.
Un driver de un dispositivo interactúa con el subsistema de E/S del núcleo y con el controlador de
E/ S que controla el dispositivo. Un driver puede invocar a ciertas rutinas del núcleo para realizar diversas
tareas, como por ejemplo, asignación de memoria y control del DMA. Además suministra al subsistema
de E/S el conjunto de funciones que se pueden realizar sobre el dispositivo.
Los drivers de dispositivos en SOBUNIX son parte del código del núcleo y se ejecutan en modo
núcleo. El núcleo puede invocar a un driver por diferentes causas [Vahalia, 1 995] :
•
Configuración. Cuando se arranca el sistema operativo el núcleo invoca a los drivers de los dispo­
sitivos para inicializar los dispositivos.
•
E/S . El subsistema de E/S del núcleo invoca a un driver para leer o escribir datos en un cierto
dispositivo.
•
Control. Un usuario puede solicitar realizar operaciones de control sobre un cierto dispositivo,
como por ejemplo rebobinar una cinta magnética, o abrir o cerrar un cierto dispositivo.
•
Interrupciones. Los controladores de E/S generan interrupciones cuando se ha completado una
operación de E/S sobre el dispositivo que supervisan o se ha producido algún cambio en su esta­
do. Las interrupciones son tratadas por los manipuladores de las interrupciones. Un manipulador
de una interrupción, entre otras tareas, debe despertar al driver del dispositivo, si éste se había
bloqueado en espera de que el controlador de E/S estuviera preparado para procesar otra petición
de E/S .
La invocación de operaciones del drivers debido a E/S o control se realiza de forma síncrona. Mien­
tras que la invocación de operaciones del driver debido a la aparición de interrupciones se realiza de
forma asíncrona.
Atendiendo a las diferentes formas de invocar a las operaciones de un driver se distinguen en su
diseño dos partes :
SOBUNIX: gestión de archivos y gestión de la E/S
221
•
Parte superior (top half). Contiene las rutinas del driver que se invocan de forma síncrona. Estas
rutinas se ejecutan en el contexto del proceso cuya ejecución ha producido la invocación del driver.
Pueden acceder al espacio de direcciones y al área-u del proceso invocador, además pueden poner
al proceso a dormir si fuese necesario.
•
Parte inferior (bottom half). Contiene las rutinas del driver que se pueden invocar de forma asín­
crona. Se ejecutan en el contexto del núcleo e interactúan con el controlador de E/ S del dispositivo
cargando en sus registros diferentes órdenes para que las efectúe sobre el dispositivo, comprobando
su estado e inicializándolo, si es necesario.
En los SOBUNIX, el núcleo mantiene dos tablas denominadas tablas de conmutación. Cada entrada
de una tabla de conmutación está asociada a un determinado driver y contiene una estructura de datos
con punteros a las funciones que implementan las operaciones soportadas por dicho driver. Existe una
tabla de conmutación para los drivers de los dispositivos modo bloque y otra tabla de conmutación para
los drivers de los dispositivos modo carácter.
Cuando el núcleo desea realizar alguna operación sobre un determinado dispositivo, en primer lugar
en función del tipo de dispositivo (bloque o carácter) selecciona la tabla de conmutación adecuada. A
continuación localiza la estructura de datos del driver en la tabla de conmutación usando el número
mayor del dispositivo e invoca a la función apropiada del driver. Esta función recibe del núcleo, entre
otros argumentos, el número mayor y el número menor del dispositivo. El driver mantiene unas tablas
internas para traducir estos números a la dirección del registro de control o puerto del controlador de E/S
del dispositivo especificado.
Nótese que es la interfaz del subsistema de E/ S del núcleo la que define las operaciones que debe ser
capaz de soportar un driver de un dispositivo, como por ejemplo: d_open ( ) , d_c l o s e ( ) , d_read ( ) ,
d_wr i t e ( ) y d_i o c t l ( ) . Los diseñadores del driver deben ajustarse a dicha interfaz. Ahora bien, un
driver puede que no soporte todas las operaciones de la interfaz. Por ejemplo, un driver de impresora
no necesita implementar una operación de lectura. En el caso de que el núcleo solicite una operación
no soportada por un driver, éste le devuelve un código de error ENODEV. También puede ocurrir que una
operación sobre un determinado driver no suponga la realización de ninguna acción por parte del driver.
Por ejemplo, muchos drivers no realizan ninguna acción para implementar una operación d_c l o s e ( ) ,
en dicho caso el driver implementa una rutina genérica que devuelve un O al núcleo para indicarle que la
operación se ha realizado correctamente.
Cada driver recibe un prefijo identificativo que depende de cada SOBUNIX. Dicho prefijo se utiliza
en todas las operaciones de dicho driver que son invocadas a través de la tabla de conmutación corres­
pondiente. Por ejemplo, en Solaris un driver del disco suele tener asociado el prefijo dk, luego el nombre
de sus operaciones empezará con dicho prefijo: dkread ( ) , dkwr i te ( ) , etc.
5.5.5.
Tratamiento de las interrupciones
La mayoría de SOBUNIX asignan a cada tipo de interrupción un número entero positivo denominado
nivel de prioridad de la interrupción (npi), que puede tomar valores comprendidos dentro del rango
222
Ampliación de sistemas operativos
[npimil� > npimaxl · Generalmente npim in es igual a O y corresponde a la prioridad más baj a. Los procesos de
los usuarios y la mayor parte del código del núcleo se ejecutan con este nivel de prioridad.
El valor de npimax depende de cada S OBUNIX. Por ejemplo en Solaris npimax = 1 5, mientras que en
BSD npimax=3 1 .
La configuración del npi a un determinado valor bloquea o enmascara todas las interrupciones con
npi igual o inferior. De esta forma se consigue priorizar la atención de las interrupciones. Por ejemplo, en
Solaris cuando llega una interrupción de reloj el npi se configura a 1 0, ello impide que se puedan atender
interrupciones con npi igual o inferior a 1 0, como es el caso, por ejemplo, de las interrupciones de disco
(npi=4) o las interrupciones de dispositivos de red (npi=7). Dichas interrupciones serán atendidas cuando
disminuya el valor del npi al valor apropiado.
El valor del npi se almacena en el registro de estado del procesador. Cada arquitectura suele in­
cluir diferentes instrucciones máquina especiales que permiten configurar el valor del npi. Además el
núcleo implementa en su núcleo diferentes funciones para configurar este valor haciendo uso de estas
instrucciones máquina.
Generalmente cuando se detecta una interrupción en un procesador se ejecuta una rutina genérica del
núcleo de tratamiento de las interrupciones que se encarga de salvar el contexto hardware del proceso
actualmente en ejecución, elevar el npi de acuerdo con el tipo de interrupción e invocar al manejador de
la interrupción apropiado. Cuando el manej ador de la interrupción completa su ejecución se devuelve
el control a la rutina genérica que disminuye el valor del npi al valor que tenía antes de atender la
interrupción y restaura el contexto hardware del proceso que se estaba ejecutando.
Puesto que el tratamiento de las interrupciones es una tarea crítica para el buen rendimiento del
sistema, los manej adores de las interrupciones suelen ser tener un código pequeño que varía en función
de la arquitectura hardware y que es rápido de ejecutar. Además su prioridad de ejecución es muy elevada.
En algunos SOBUNIX los manejadores se implementan como rutinas del núcleo que se ejecutan en
el contexto del proceso actualmente en ejecución. En otros SOBUNIX, como Solaris, los manej adores
de interrupciones se implementan como hilos del núcleo independientes no asociados a ningún proceso.
5.6.
Conectores
Los conectores (sockets) son uno de los principales mecanismos usados en los SOBUNIX para im­
plementar las conexiones en red. Otro mecanismo muy utilizado son los STREAMS [Vahalia, 1 995] . Un
conector permite establecer un canal de comunicación a través de una red (o localmente dentro de un
mismo computador) entre un proceso emisor y un proceso receptor (ver Figura 5 . 1 1 ) .
Los conectores son implementados mediante archivos que s e crean y s e eliminan dinámicamente. Un
conector se crea invocando a la llamada al sistema
r = s o c ke t ( f ami l i a , t ipo , pro t o c o l o ) ;
Esta llamada presenta los siguientes parámetros de entrada [Márquez, 2004] :
•
f ami l i a. Especifica la familia de direcciones o protocolos que se desea emplear. Dichas familias
SOBUNIX: gestión de archivos
.;--v
Pro � es
emisor
¡.- Espacio
� _...Conector
.
1
y
Red
---+
del usuario
Espacio
¡.- del núcleo
---+
y
gestión de la E/S
223
�
Conecto!:...
�
1
roceso
receptor
y
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
L--------------------------------------------------�
Figura 5 . 1 1
-
Comunicación en red mediante el uso de conectores
suelen estar definidas generalmente en el archivo de cabecera sys 1 s o cket . h. Dos de las familias
más usadas son:
- AF_UNIX (o PF_UNI X ) . Protocolos internos de UNIX. Esta familia se utiliza para comunicar
procesos que se ejecutan en la misma máquina. En consecuencia no requiere de la existencia
de una tarjeta de red en el computador ya que no la utiliza.
- AF_INET (o PF_INET ) . Protocolos de Internet, como por ejemplo TCP o UDP.
•
t ipo. Establece la semántica de conexión para el conector. Entre otros, puede tomar, los siguientes
valores :
- SOCK_STREAM. Conector con un protocolo orientado a conexión. Consiste en realizar una
búsqueda de enlaces libres que unan los dos computadores que se quieren conectar. Una vez
establecida la conexión se pueden enviar los datos en orden secuencial, como si fuese una
tubería, ya que la conexión es permanente y fiable.
- socK_DGRAM. Conector con un protocolo no orientado a conexión o datagrama. Se trata de
conexiones no permanentes o fiables. La transmisión por datagramas se realiza a nivel de
paquetes. Cada paquete puede seguir una ruta distinta. Además la recepción de los paquetes
puede no ser secuencial.
•
pro t o c o l o . Permite especificar el protocolo particular que se va utilizar dentro de una determina­
da familia. Normalmente cada tipo de conector tiene asociado un determinado protocolo, pero en
el caso de que existiera más de uno, se especifica el adecuado con este parámetro. Si este parámetro
se configura con el valor O, entonces la elección del protocolo se delega en el núcleo.
Si durante la ejecución de esta llamada al sistema se produce algún error entonces en r se almacena
el valor -l. Si la llamada se ejecuta con éxito entonces en r se almacena el descriptor de archivo asociado
al conector.
224
e
Ampliación de sistemas operativos
Ejemplo 5 . 15
La llamada al sistema
f d= s o c k e t ( AF_UNIX , SOCK_STREAM , O ) ;
intenta crear un conector orientado a conexión ( SOCK_STREAM) que utilizará los protocolos internos de
UNIX (AF_UNIX) . El protocolo utilizado será escogido por el núcleo ( 0 ) . Si la llamada se ejecuta con
éxito entonces almacena en fd el descriptor del archivo asociado al conector. En caso de error almacena
el valor -l.
•
Antes de poder usar un conector se le debe asociar una dirección particular dentro de la familia de
protocolos seleccionada. Para ello se debe utilizar la llamada al sistema bind.
Una vez creado un conector orientado a conexión con una dirección particular asociada en cada uno
de los dos computadores X e Y que se desean comunicar por red es posible establecer una conexión entre
los dos computadores. Un proceso A en el computador X debe realizar una llamada al sistema l i s t en
sobre su conector, la cual crea un buffer y bloquea al proceso hasta que llegan datos por la red.
Otro proceso B en el computador Y debe realizar una llamada al sistema c onnec t pasándole como
parámetros de entrada el descriptor de su conector local en Y y la dirección del conector en la compu­
tadora X. Si el proceso A acepta la conexión entonces se puede establecer una comunicación entre los
conectores.
El funcionamiento de una conexión entre conectores es similar al de una tubería. Un proceso puede
leer o escribir de su conector local de la misma forma que a cualquier otro tipo de archivo, es decir,
usando las llamadas al sistema read o wr i t e . Cuando un proceso termina de usar una conexión debe
cerrarla usando la llamada al sistema e l o s e .
Los conectores aparte d e read disponen de las siguientes llamadas al sistema adicionales para leer
datos en ellos : r eadv, re cv, recvfrom y recvms g. Asimismo disponen de las siguientes llamadas
para escribir datos: wr i t ev, s end, s endto y s endms g.
5.7.
Resumen
En los SOBUNIX se distinguen los siguientes tipos de archivos : ordinarios o regulares, directorios,
especiales (asociados a dispositivos), tuberías, conectores y enlaces simbólicos. Para que un proceso
pueda poder operar sobre un archivo, éste primero tiene que ser abierto mediante la invocación de la
llamada al sistema open. La rutina del núcleo del sistema operativo que trata esta llamada al sistema crea
en la memoria principal una estructura de datos denominada objeto de archivo abierto y asigna a dicha
estructura un número entero positivo pequeño denominado descriptor de archivo para identificarla. La
llamada al sistema open devuelve el descriptor del archivo abierto al proceso que invocó la llamada. Para
poder operar sobre un archivo abierto el proceso debe pasar el descriptor del archivo como argumento de
las llamadas al sistema asociadas a las operaciones que desee realizar sobre el archivo.
SOBUNIX: gestión de archivos y gestión de la E/S
225
En los sistemas de archivos desarrollados para SOBUNIX una entrada de una lista de un directo­
rio contiene, entre otras informaciones, el número del nodo-i asociado a un archivo y su nombre. Los
SOBUNIX implementan una estructura de directorios de gráfica acíclica.
Durante el proceso de instalación de un SOBUNIX se realiza un formateo a alto nivel de una partición
del disco duro para crear el sistema de archivos principal donde se aloja el directorio raíz 1 . Cada
SOBUNIX establece el tipo de sistema de archivos principal que crea. Aparte de este sistema de archivos
principal los SOBUNIX son capaces de reconocer y manipular otros sistemas de archivos del mismo o
distinto tipo ubicados en memoria secundaria.
'
'
Los SOBUNIX modernos para soportar distintos tipos de archivos implementan una capa de software
denominada capa nodo-v/sistema de archivos virtual. Cualquier operación sobre un archivo o sobre un
sistema de archivos completo invocada por el usuario a través de una llamada al sistema o internamente
por algún subsistema del núcleo es redireccionada por la capa nodo-v 1 sistema de archivos virtual hacía la
rutina dependiente del sistema de archivos al que pertenezca el archivo que da soporte a dicha operación.
UFS es un sistema de archivos soportado por diversos SOBUNIX. Deriva del sistema de archivos
FFS de BSD y presenta la siguiente estructura en la partición de disco donde se crea: área de arranque,
superbloque y grupos de cilindros. El área de arranque contiene el código necesario para arrancar el SO­
BUNIX si dicha partición se usa como partición activa. El superbloque contiene información estadística
y administrativa del sistema de archivo, como por ejemplo: un número mágico que identifica al sistema
como de tipo UFS , el número, el tamaño y la localización de los grupos de cilindros, el tamaño de blo­
que de datos que se utiliza, el número total de bloques de datos y de nodos-i, etc. Un grupo de cilindros
está formado por un conjunto de cilindros contiguos. El número de grupos de cilindros y el número de
cilindros que contiene un grupo son configurados cuando se crea el sistema de archivos UFS . Cada gru­
po de cilindro contiene la siguiente información: una copia del superbloque, una estructura de grupo de
cilindros que contiene información estadística y administrativa del grupo de cilindros, mapas de bits para
conocer cuales son los bloques, fragmentos y nodos-i libres en el grupo de cilindros, y nodos-i del grupo
de cilindros.
Los SOBUNIX integran los dispositivos de E/S dentro del sistema de archivos principal, general­
mente en el directorio 1 dev, para ello asignan a cada dispositivo un archivo de dispositivo modo bloque
o modo carácter. Esta integración permite operar con los dispositivos de E/ S usando las mismas llamadas
al sistema que se utilizan para operar sobre los archivos : open, read, wr i te, etc.
El contenido del nodo-i de un archivo de dispositivo, a diferencia del nodo-i de un archivo regular o
un directorio, no contiene las direcciones de los bloques de datos del archivo sino dos números enteros
positivos denominados: número de dispositivo mayor y número de dispositivo menor. El número de
dispositivo mayor permite identificar a una cierta clase de dispositivo y el número de dispositivo menor
a una instancia de dicho dispositivo.
El núcleo generalmente mantiene dos tablas denominadas tablas de conmutación. Existe una tabla
de conmutación para los drivers de los dispositivos modo bloque y otra tabla de conmutación para los
drivers de los dispositivos modo carácter. Cada entrada de una tabla de conmutación está asociada a un
determinado driver y contiene una estructura de datos con punteros a las funciones que implementan las
operaciones soportadas por dicho driver.
226
Ampliación de sistemas operativos
En relación con las conexiones en red, los conectores (sockets) son uno de los principales mecanis­
mos usados en los SOBUNIX para implementarlas. Un conector permite establecer un canal de comu­
nicación a través de una red (o localmente dentro de un mismo computador) entre un proceso emisor y
un proceso receptor. Los conectores son implementados mediante archivos que se crean y se eliminan
dinámicamente.
5.8.
Lecturas recomendadas
Si se desea obtener una explicación adicional de los contenidos tratados en este capítulo se pueden
consultar, por ejemplo: los capítulos 8 y 9 de [Vahalia, 1 995] , los capítulos 2, 3, 4 y 1 1 de [Márquez,
2004] , los capítulos 14 y 15 de [McDougall y Mauro, 2006] y el capítulo 10 de [Tanenbaum, 2009] .
5.9.
Autoevaluación
5. 1 . ¿Cómo se estructura la información contenida en un archivo en los SOBUNIX? ¿Qué tipos de
acceso a los archivos soportan? (Respuesta en sección 5 . 2 . 1)
5 .2. Explicar razonadamente si en los SOBUNIX el nombre de un archivo puede tener una extensión.
(Respuesta en sección 5 . 2 . 1)
5 .3. Enumerar y explicar brevemente los tipos de archivos soportados en los SOBUNIX.
(Respuesta en sección 5 . 2 . 1)
5 .4 . Enumerar los atributos de un archivo soportados en los SOBUNIX. ¿Qué llamadas al sistema y
comandos pueden usarse para visualizar los atributos de un archivo? (Respuesta en sección 5 . 2 . 1)
5 . 5 . ¿Qué es un descriptor de un archivo? ¿Cómo se obtiene? (Respuesta en sección 5.2.1)
5 . 6 . ¿Qué es una tabla de descriptores de archivos? ¿Qué información contiene una de sus entradas?
¿A quién están asignadas por defecto las tres primeras entradas de la tabla?
(Respuesta en sección 5 . 2 . 1)
5 .7 . ¿Qué es un objeto de archivo abierto? ¿Cuándo se crea? Enumerar y explicar la información que
contiene. (Respuesta en sección 5 . 2 . 1)
5 . 8 . Explicar la utilidad y la sintaxis de cada una de las siguientes llamadas al sistema: c r e a t , open,
e l o s e , read, wr i te, l s e ek, s t a t , f s ta t y fcnt l . (Respuesta en sección 5 . 2 . 1)
5. 9. En los sistemas de archivos desarrollados para los SOBUNIX ¿qué información suele contener una
entrada de una lista de un directorio? (Respuesta en sección 5 . 2.2)
5. 10. ¿Qué tipo de estructura de directorios suelen implementar los SOBUNIX? ¿Qué carácter se utiliza
en los SOBUNIX para representar al directorio raíz y separar los componentes de un nombre de
ruta? (Respuesta en sección 5 .2.2)
SOBUNIX: gestión de archivos y gestión de la E/ S
227
5. 1 1 . Explicar la utilidad y la sintaxis de cada una de las siguientes llamadas al sistema: chdi r, mkd i r
y rmd i r . (Respuesta e n sección 5 . 2.2)
5 . 12. ¿Qué es un enlace duro? ¿ Y un enlace simbólico?. (Respuesta en sección 5 .2.3)
5. 13. Explicar el funcionamiento del contador de enlaces duros del nodo-i de un directorio.
(Respuesta en sección 5.2.3)
5. 14. ¿Cuántos nombres puede tener un archivo en SOBUNIX? ¿Y un directorio?
(Respuesta en sección 5 .2.3)
5. 15. ¿Qué mascara de modo simbólica tiene asociada un enlace simbólico? (Respuesta en sección 5 .2.3)
5 . 16. ¿Qué llamadas al sistema y comandos pueden utilizarse para crear enlaces duros y simbólicos ? ¿ Y
para eliminarlos? (Respuesta en sección 5 .2.3)
5 . 17. ¿Qué es un punto de montaje? ¿ Y la tabla de montaje? (Respuesta en sección 5 . 2 .4)
5. 18. ¿Cómo se realiza el acceso a un directorio o a un archivo perteneciente a un sistema de archivos
montado sobre el sistema de archivos principal? (Respuesta en sección 5 . 2 .4)
5. 19. Explicar la utilidad de los siguientes comandos: moun t , umount , mk f s , f s c k y d f .
(Respuesta e n sección 5 . 2 .4)
5 .20. ¿Cuál es la utilidad de la capa nodo-v/SAV? (Respuesta en sección 5.3)
5 .21 . ¿Qué es un nodo-v? ¿Cuándo se asigna? ¿Qué función realiza? (Respuesta en sección 5 . 3 . 1)
5 .22. Explicar el funcionamiento del contador de referencias de un nodo-v y enumerar las circunstancias
en que se incrementa. (Respuesta en sección 5 . 3 . 1)
5 .23. Enumerar y explicar brevemente la información contenida en la estructura de datos que implementa
un nodo-v (Respuesta en sección 5 . 3 . 1)
5 .24. ¿Qué es un sistema de archivos virtual? ¿Cuándo se asigna? ¿Qué función realiza?
(Respuesta en sección 5 . 3 .2)
5 .25 . Enumerar y explicar brevemente la información contenida en la estructura de datos que implementa
un SAV. (Respuesta en sección 5 . 3 .2)
5 .26. Explicar cómo se realiza el análisis de nombres de rutas en los SOBUNIX que implementan la
capa nodo-v/SAV. (Respuesta en sección 5 . 3 . 3 )
5 .27. Explicar la información que contiene y cómo se utiliza la caché de búsqueda de nombres en direc­
torios en los SOBUNIX. (Respuesta en sección 5 . 3 .3)
5 .28. Enumerar las principales características de un sistema de archivos UFS . (Respuesta en sección 5.4.1)
228
Ampliación de sistemas operativos
5 .29. Dibujar un diagrama que represente la estructura en una partición de disco de un sistema de archi­
vos UFS . Explicar la información contenida en cada uno de sus componentes.
(Respuesta en sección 5 .4.2)
5 .30. Explicar cómo se implementan los directorios en un sistema de archivos UFS .
(Respuesta en sección 5 .4.3)
5 .3 1 . ¿Qué es un nodo-im? ¿Qué información contiene? (Respuesta en sección 5 .4.4)
5 .32. ¿Cuándo se coloca un nodo-im en la lista de nodos-im libres? ¿Dé que depende la posición de un
nodo-im en esta lista? (Respuesta en sección 5.4.4)
5 .33. ¿Qué sucede si el núcleo no localiza a un nodo-im en la cola hash donde le correspondería estar?
(Respuesta en sección 5 .4.4)
5 .34. Explicar cómo se realiza la asignación de espacio en un sistema de archivos UFS .
(Respuesta en sección 5 .4.5)
5 . 35 . Enumerar y explicar las dos grandes categorías en que se clasifican los dispositivos de E/S en los
S OBUNIX. (Respuesta en sección 5 . 5 . 1)
5 .36. ¿Qué son los pseudodispositivos ? (Respuesta en sección 5 . 5 . 1)
5. 37. Explicar cómo se integran los dispositivos de E/ S dentro del sistema de archivos.
(Respuesta en sección 5.5 .2)
5. 38. Explicar la utilidad del número de dispositivo mayor y del número de dispositivo menor. ¿Dónde
se aloj a esta información? (Respuesta en sección 5 . 5 .2)
5 .39. Explicar la utilidad y la sintaxis de la llamada al sistema mknod (Respuesta en sección 5 . 5 .2)
5 .40. Comentar las diferentes soluciones adoptadas en los SOBUNIX para implementar los nodos-v y
los nodos-i de los archivos de dispositivos. (Respuesta en sección 5 . 5 .2)
5 .41 . Explicar la información que contiene y cómo se utiliza la caché de buffers de bloques de disco en
los S OBUNIX. (Respuesta en sección 5 .5 .3)
5 .42. Explicar cómo se integran las operaciones de E/S sobre archivos dentro de la memoria virtual.
(Respuesta en sección 5 .5 . 3 )
5 .43. ¿Dónde se integra y en qué modo se ejecuta un driver de un dispositivo en los SOBUNIX?
(Respuesta en sección 5 .5 .4)
5 .44. Enumerar y comentar brevemente las principales causas por las que el núcleo puede invocar a un
driver de un dispositivo en los SOBUNIX. (Respuesta en sección 5 . 5 .4)
SOBUNIX: gestión de archivos y gestión de la E/S
229
5.45 . Explicar las partes que se distinguen en el diseño de un driver de un dispositivo en SOBUNIX
atendiendo a las diferentes formas de invocar sus operaciones. (Respuesta en sección 5 . 5 .4)
5 .46. ¿Qué son las tablas de conmutación mantenidas en los SOBUNIX? ¿Para que se utilizan?
(Respuesta en sección 5 . 5 .4)
5.47. ¿Quién define las operaciones que debe ser capaz de soportar un driver de un dispositivo? ¿Qué
indica el código de error ENODEV? (Respuesta en sección 5 . 5 .4)
5.48. Explicar cómo se realiza el tratamiento de las interrupciones en los SOBUNIX.
(Respuesta en sección 5 .5 .5)
5 .49. ¿Qué son los conectores? (Respuesta en sección 5 .6)
5 .50. Explicar la utilidad de las siguientes llamadas al sistema: s o cke t , bind, l i s t en y c onne c t .
(Respuesta en sección 5 .6)
5. 51 . ¿Cómo se puede leer o escribir en un conector? (Respuesta en sección 5. 6)
5.10.
Ejercicios
5. 1 Explicar el significado de las siguientes llamadas al sistema:
a) fd=open ( " da t o s . txt " O_RDWR J O_APPEND ) ;
1
b) fd=open ( " prueba " O_RDONLY J O_CREAT 0 6 0 0 )
1
1
;
5 .2 El nodo-i de un archivo tiene el valor 1 en su contador de enlaces duros. ¿Qué sucede si se aplica
sobre dicho archivo la llamada al sistema o el comando un l ink?
5 .3 Escribir un programa en C que ilustre el uso de la llamada al sistema s t a t .
5 .4 En el directorio de trabaj o actual de un usuario residen los ficheros wer t . t x t (ver Figura 5 . 1 2) y
j 1 0 (ver Figura 5 . 1 3 ) .
a) Explique detalladamente e l funcionamiento d e este programa s i s e invoca desde u n intérprete
de comandos mediante la orden: j 1 0 2 5 wer t . txt
b) Comprobar que la respuesta dada en el apartado anterior es correcta compilando y ejecutando
este programa en un SOBUNIX.
5 . 5 Ejecutar en un intérprete de comandos de un SOBUNIX la orden d f . Consultar el manual de ayuda
man para explicar la funcionalidad de este comando y el significado de la salida que muestra en la
pantalla.
5 . 6 Determinar el tamaño máximo que en teoría podría tener un archivo en un sistema de archivos
UFS si se utiliza un tamaño de bloque de 8 KiB .
230
Ampliación de sistemas operativos
El s i s t ema ope r a t ivo UNIX es un s i s t ema mu l t iusuar i o y mu l t iproc e s o \ n
e s c r i t o e n l engua j e C que d e s d e su nac imi ento a p r i n c i p i o s d e l a \ n
déc ada de l o s s e t en t a h a i do a l c a n z ando bas tan t e éxi t o y popu l a r i da d \ n
tanto en e l ámb i t o un ive r s i t ar i o c omo en e l emp r e s ar i a l . \ n
Figura 5.12 -
Primeras líneas del archivo wert . txt
# i nc l ude < s t d l ib . h>
# i n c l ude < s t d i o . h>
# in c l ude < f c n t l . h>
vo i d try ( i n t ,
ma in ( i nt np ,
{
char * ) ;
char * pe [ ] )
int x , T , h , a ;
char * L ;
if
( np = = 3 )
{
x = a t o i ( pe [ l ] ) ;
L = ( char * ) ma l l o c ( ( x& ( x - l ) ) * s i z e o f ( char ) ) ;
f o r ( h = O ; h< = ( ( x& ( x - 1 ) ) - 2 ) ; h+ + )
* ( L +h ) = ' \ 0 ' ;
a = open ( p e [ 2 ] , 0_RDWR ) ;
t ry ( a , L ) ;
l s eek ( a , x , x %2 ) ;
t ry ( a , L ) ;
exi t ( 3 ) ;
vo i d try ( i n t y ,
char * U )
read ( y , u , 1 5 ) ;
p r i nt f ( " \ n \ " %s \ " \ n " , u ) ;
Figura 5.13 -
Código C del programa j 1 0 del Ejercicio 5.4
Capítulo 6
SOBUNIX: el sistema operativo Linux
Objetivos docentes
Los objetivos docentes de este capítulo son los siguientes :
•
Conocer los orígenes y la naturaleza de Linux.
•
Saber cómo se implementa la gestión de procesos e hilos en Linux.
•
Conocer los detalles de la implementación de la planificación de tareas en Linux.
•
Conocer cómo se realiza la gestión de memoria en Linux.
•
Conocer las particularidades de la implementación de la gestión de archivos en Linux.
•
Conocer las principales características de los sistemas de archivos nativos de Linux: EXT2, EXT3
y EXT4.
6.1.
Introducción
Este capitulo está dedicado al estudio de las particularidades más reseñables de Linux, el SOBUNIX
de código abierto más conocido y utilizado. En primer lugar se incluyen una serie de consideraciones
generales sobre Linux. En concreto se comentan los orígenes y las diferencias entre versiones y distri­
buciones de Linux. En segundo lugar se describen las particularidades de la gestión de procesos e hilos
en Linux. En tercer lugar se describe la planificación de tareas en Linux, distinguiendo entre la planifi­
cación utilizada antes y después de la versión 2.6.23 . En cuarto lugar se analiza la implementación de
la gestión de memoria en Linux, describiendo tanto la gestión del espacio de direcciones virtuales como
la gestión de la memoria física. La última parte del capítulo está dedicada al estudio de las particula­
ridades de la gestión de archivos en Linux. En concreto se describe cómo se implementa en Linux la
23 1
232
Ampliación de sistemas operativos
capa nodo-v/sistema de archivos virtual. Además se estudian los sistemas de archivos nativos de Linux:
EXT2, EXT3 y EXT4.
Conviene señalar que en la exposición de los contenidos de este capítulo se presupone que el lector
ya se ha leído los cinco capítulos anteriores dedicados al estudio de los SOBUNIX. También conviene
tener presente que obviamente por motivos de espacio este capítulo no es más que un pequeño resumen
de las particularidades del núcleo de Linux. Los lectores que deseen profundizar en su estudio pueden
consultar las referencias bibliográficas reseñadas en la sección 6 . 8 .
6.2.
Consideraciones generales sobre Linux
6.2.1.
Orígenes de Linux
Linux es un SOBUNIX cuyo núcleo en su primera versión fue escrito en 199 1 por Linus Benedict
Torvalds, por aquel entonces un estudiante finlandés de veintiún años. Linus creó Linux 1 por hobby ya
que no estaba satisfecho con el rendimiento del sistema operativo MS-DOS del PC Intel 386 que se
había comprado; escribió Linux en C tomando como base el sistema operativo MINIX desarrollado por
Andrew S. Tanenbaum.
Linus deseaba compartir su trabaj o con otras personas por ello colgó en Internet el código fuente
de Linux, primero con una licencia propia de tipo freeware y posteriormente con una licencia GPL del
proyecto GNU. El acceso libre y gratuito al código fuente de Linux ha propiciado que miles de personas
en todo el mundo colaboren con Linus desinteresadamente en el desarrollo y mejora de este sistema
operativo.
En la actualidad Linux ha sido portado a diferentes arquitecturas hardware y continúa evolucionando.
Además cada vez interesa a más usuarios y empresas ya que, aparte de ser gratuito, es comparable en
potencia y flexibilidad a otros sistemas operativos comerciales.
6.2.2.
Versiones del núcleo de Linux
Cada versión del núcleo de Linux2 tiene asignada un identificador numérico. Hasta la versión 2.5 el
identificador podía constar de hasta tres número enteros positivos: v . T . R. Si T era un número par signi­
ficaba que se trataba de una versión estable del núcleo, mientras que si era un número impar significaba
que se trataba de una versión en desarrollo. En las versiones en desarrollo se pretendía añadir nuevas
funcionalidades al núcleo. Ello suponía la realización de cambios importantes sobre los algoritmos y las
estructuras del núcleo, lo que hacía que estas versiones no fueran muy estables. Por ejemplo, de acuer­
do con este criterio la versión 1 .2 es una versión estable mientras que la versión 1 .3 es una versión en
desarrollo.
Por otra parte, el número R denota el número de lanzamiento o liberación (release) de dicha versión.
Cada liberación incluye pequeñas modificaciones y corrige los errores que se hayan detectado desde la
1 El nombre de Linux surge como una contracción de las palabras Linus y UNIX.
2En la web www.kemel .org puede descargarse el código fuente de las últimas versiones aparecidas del núcleo de Linux.
SOBUNIX: el sistema operativo Linux
233
liberación anterior. Por ejemplo, la versión 1 .2.2 incluye pequeños cambios y corrección de errores en
relación con la versión 1 .2. 1 .
Desde la versión 2.6 el identificador numérico de la versión puede constar de hasta cuatro números
enteros positivos: v . T . R . x. Ahora el número T ya no denota si se trata de una versión estable o en
desarrollo. Cada nueva liberación R de una versión v . T puede incluir cambios importantes incluso en
componentes claves del núcleo por lo que es potencialmente inestable. Esto sucedía por ejemplo entre las
versiones 2.6. 1 O y 2.6. 1 1 . Para corregir los problemas que se van encontrando en una versión y conseguir
que sea estable se liberan sucesivas versiones parcheadas que se identifican con el número X.
Para conocer la versión del núcleo de Linux que se está utilizando se puede usar el comando
uname - r
Señalar que en este capítulo s e toman como base las versiones 2.6. 1 1 y 2.6.24 del núcleo de Linux.
6.2.3.
Distribuciones Linux
En Internet puede encontrarse el código fuente del núcleo de Linux, así como diversos programas
(intérpretes de comandos, compiladores, etc) y aplicaciones (escritorios, navegadores web, gestores del
correo electrónico, etc) que se ejecutan en Linux, la mayoría de ellos procedentes del proyecto GNU
y de la Free Software Foundation. La tarea de buscar, compilar e instalar un sistema Linux (núcleo +
programas + aplicaciones) en un computador partiendo desde cero es una tarea bastante laboriosa que
debe ser realizada por un usuario informático bien experimentado.
Afortunadamente, con la idea de acercar el sistema Linux a todo tipo de usuarios, surgieron las
distribuciones de Linux realizadas por diferentes organizaciones y empresas. Una distribución de Linux
recopila en uno o varios CDs todos los ficheros necesarios para montar un sistema Linux en una partición
del disco duro de un computador. Además incluye un programa instalador con una GUI amigable que
simplifica enormemente la instalación de Linux.
Entre las distribuciones más conocidas de Linux se encuentran las siguientes : Red Hat, Debian,
Slackware, Fedora, Gentoo, Ubuntu, Kubuntu, Mandriva y SuSE.
Las principales diferencias entre las distribuciones de Linux radican en los programas y aplicaciones
que instalan, así como en la facilidad que conceden al usuario para instalar y configurar el sistema.
6.3.
Gestión de procesos e hilos en Linux
A diferencia de otros SOBUNIX, como por ejemplo Solaris (ver sección 2.2.2), en Linux no existe
una distinción clara entre las abstracciones de proceso, proceso ligero (hilo de usuario) e hilo del núcleo.
De hecho en varías partes del código del núcleo se utilizan los términos procesos, hilos y tareas de forma
sinónima; debido seguramente a que en las primeras versiones del núcleo utilizaban como unidad de
planificación y ejecución al proceso y no soportaban procesos ligeros ni hilos del núcleo.
Para el núcleo de Linux un proceso monohilo, un proceso ligero o un hilo del núcleo es simplemente
un flujo de ejecución independiente o tarea (task) que debe ser planificada y ejecutada. Linux considera
234
Ampliación de sistemas operativos
a un proceso monohilo como una única tarea. Mientras que un proceso multihilo constará de un número
de tareas igual al número de procesos ligeros (hilos de usuario) en que se descomponga. También cada
hilo del núcleo asociado a un proceso del sistema o utilizado para ejecutar una determinada función del
núcleo es considerado como una única tarea.
Por otra parte, en Linux se utiliza el concepto de grupo de hilos para designar a todos los procesos
ligeros que forman parte de una misma aplicación multihilo.
6.3. 1.
Estructuras del núcleo asociadas a las tareas
El núcleo asigna a cada tarea en el momento de su creación una estructura t a s k_s t ruc t , una pila
en modo núcleo y una estructura thread_i n f o , entre otras estructuras de datos.
Estructura task_struct
La estructura task_s truc t , también denominada descriptor del proceso, contiene datos y punteros
a otras estructuras de datos que el núcleo necesita conocer para poder gestionar una tarea. Esta estructura
contiene la siguiente información:
•
Estado de la tarea. En Linux una tarea puede encontrarse en los siguientes estados:
- TASK_RUNNING (Ejecutándose) . Una tarea se encuentra en este estado si se está ejecutando
en un procesador o si está preparada para ser ejecutada cuando lo determine el planifica­
dor del núcleo. Nótese la diferencia entre Linux y otros SOBUNIX donde ejecutándose y
preparado para ejecución son considerados estados independientes.
- TASK_INTERRUPT I BL E (Interrumpible). La tarea se encuentra dormida a la espera de que
se produzca un determinado evento, pero puede ser despertada si llega alguna señal no blo­
queada que no ignore.
- TASK_UNINTERRUPT I BLE (No interrumpible). La tarea se encuentra dormida a la espera
de que se produzca un evento, pero solo será despertada si se produce el evento por el que
espera. Una tarea en este estado no puede ser despertada si llega alguna señal no bloqueada
que no ignore.
- TASK_STOPPED (Parada). La ejecución de la tarea ha sido detenida por otra tarea, por ejem­
plo un depurador de código.
- TASK_TRACED (Rastreada). Es un caso especial del estado anterior. Este estado se utiliza
exclusivamente para aquellas tareas cuya ejecución ha sido detenida porque está siendo ras­
treada mediante la llamada al sistema ptrace invocada por otra tarea.
- EXI T_ZOMB I E (Zombi). La tarea ha terminado su ejecución pero el núcleo todavía no ha
borrado el contenido de su estructura task_s tru c t ya que el padre todavía no ha invocado
una llamada al sistema wai tp i d o wai t4 para obtener el estatus de salida de su hijo. Nótese
que si el padre nunca invoca a esta llamada al sistema el núcleo no eliminará esta estructura
hasta que el sistema no sea reiniciado.
S OBUNIX : el sistema operativo Linux
235
- EXI T_DEAD (Muerta). La tarea ha terminado su ejecución y su proceso padre ya ha invocado
una llamada al sistema wa i tp i d o wa i t 4 para obtener el estatus de salida de su hijo. El
núcleo procederá a la eliminación de la estructura t a s k_s truc t si no existen más tareas
que hayan invocado una llamada al sistema del mismo tipo wai tp i d sobre la misma tarea.
En la Figura 6. 1 se muestra el diagrama de transición de estados de las tareas en Linux. Por
simplificar el diagrama se ha omitido el estado rastreada.
Terminación
Creación
Tratamiento de
una llamada
tipo wa it
invocada por
el padre
un evento
Figura 6.1
-
Diagrama de transición de estados de las tareas en Linux
•
Parámetros de planificación. Entre ellos la prioridad de la tarea, el tiempo de ejecución y el tiempo
promedio que duerme una tarea esperando por un evento. Como se explicará en la sección 6.4 el
planificador utiliza esta información para decidir que tarea será planificada para ejecución en un
determinado procesador del computador.
•
Identificadores. Cada tarea tiene asociada un identificador de tarea (task identifier, TID), también
denominado identificador del hilo (thread Identifier), que la identifica de manera única. Este iden­
tificador se almacena en un campo de la estructura t a s k_s truc t . Contrariamente a lo que se
podría pensar este campo no se denomina t i d sino p i d. Esto es así porque en sus orígenes Linux
únicamente soportaba procesos monohilos y en dicho caso el valor del TID es igual al PID del
proceso.
En el caso de procesos multihilos cada hilo constituye una tarea y tiene asociado un TID diferente.
Además cada tarea tiene asignado un identificador de grupo de tareas (Task Group IDentifier,
236
Ampliación de sistemas operativos
TGID), también denominado identificador de grupo de hilos, el cual se almacena en el campo
t g i d de la estructura ta s k_s t ruc t . Todas las tareas pertenecientes a un mismo grupo de tareas
tienen asignado el mismo TGID, el cual coincide con el TID de la tarea líder del grupo, que es la
tarea principal. El PID de un proceso multihilo en Linux coincide con el valor del TGID de sus
hilos.
•
Información genealógica. Como por ejemplo: un puntero a la estructura t a s k_s truc t de su
proceso padre, la cabecera de la lista doblemente enlazada de sus procesos hijos, y punteros para
implementar la lista doblemente enlazada de sus procesos hermanos.
•
Localización del espacio de direcciones virtuales de la tarea.
•
Credenciales. Como los identificadores de usuario (UID y EUID), los identificadores de grupo
(GID y EGID) y el identificador de sesión (SID).
•
Contexto hardware salvado. Permite continuar con la ejecución de la tarea en modo usuario tras
retornar de la ejecución en modo núcleo de una llamada al sistema o de una interrupción.
•
Puntero a la estructura thread_i n f o .
•
Información relativa a l sistema de archivos. Como u n puntero a l a tabla de descriptores d e archivos
abiertos y punteros al nodo-i del directorio de trabajo actual y al nodo-i del directorio raíz.
•
Información asociada al tratamiento de señales. Como las máscaras de señales ignoradas, blo­
queadas y pendientes. Así como las acciones establecidas para cada tipo de señal y las direcciones
de los manejadores de las señales que son capturadas.
•
Información contable sobre uso de recursos. Como el tiempo ejecutado en modo usuario o en modo
núcleo. También límites máximos a los recursos que puede utilizar: número máximo de archivos
abiertos, tiempo máximo de uso del procesador, tamaño máximo de su pila o de su segmento de
datos, número máximo de marcos de página que puede consumir, etc.
El núcleo enlaza todas las estructuras ta s k_s truc t existentes en una lista que se denomina lista
de procesos. Este nombre deriva de las primeras versiones de Linux donde únicamente se soportaban
procesos monohilos y en consecuencia las tareas eran procesos. En las versiones actuales con soporte
de procesos multihilos este nombre puede llevar a confusión ya que una tarea puede ser un proceso
monohilo, un hilo de usuario (proceso ligero) o un hilo del núcleo. Un nombre más apropiado sería lista
de tareas. Por otra parte señalar la analogía existente entre la estructura task_s truc t y la estructura
proc descrita en la sección 2.2.2.
e
Ejemplo 6. 1
Considérense el archivo ejecutable prog 6 1 cuyo código fuente en C se muestra en la Figura 6.2. Se
observa que el programa hace uso de funciones de la librería de hilos Pthreads (ver sección 2.3 .4) para
implementar dos hilos de usuario. La función de cada hilo es mostrar en pantalla el valor de su PID y
SOBUNIX: el sistema operativo Linux
237
# i nc lude < s td i o . h>
# i nc l ude <pthread . h>
# i nc lude < sys / sys c a l l . h>
vo i d * funl ( vo i d * i d ) ;
vo i d mo s t rar_i n f o ( char e ) ;
ma i n ( )
{
/ * Código de l h i l o 1
( pr i nc ipa l ) * /
p thread_t hu l ;
p thread_c r e a t e ( &hu l , NULL , * funl , NULL ) ;
mo s t rar_i n f o ( ' l ' ) ;
p thread_j o i n ( hu l , NULL ) ;
p r i n t f ( " \ nH i l o 2 t e rm i nado " ) ;
for ( ; ; ) ;
vo i d * funl ( vo i d * i d )
/ * C ó d i go del hi l o 2 * /
mo s t rar_i n f o ( ' 2 ' ) ;
for ( ; ; ) ;
vo i d mo s t rar_i n f o ( char e )
{
l ong i n t u , v ;
u = g e tp i d ( ) ;
v= ( l ong i n t ) sys c a l l ( SYS_g e t t i d ) ;
p r i n t f ( " \ nH i l o
%:::: :
P I D= % l d
Figura 6.2 -
T I D= % l d \ n " , c , u , v ) ;
Código C del programa prog 6 1 del Ejemplo 6 . 1
TID asociado. Para obtener el PID se invoca a la llamada al sistema g e t p i d . Realmente esta llamada en
Linux devuelve el TGID del hilo que la invoca, recuérdese que PID=TGID. Por otra parte para obtener el
TID se invoca indirectamente a la llamada al sistema g e t t i d a través de la llamada al sistema sys c a l l
ya que no existe definida en 1 ibc una función de envoltura para esta llamada al sistema.
Supóngase que prog 6 1 es invocado en segundo plano desde la línea de órdenes de un intérprete de
comandos en Linux. En la pantalla aparecería una salida parecida a la siguiente:
H i l o 1 : P I D= l 2 6 7 4 T I D= l 2 6 7 4
H i l o 2 : P I D= l 2 6 7 4 T I D= l 2 6 7 5
S e observa que el proceso asociado al programa tiene asignado un PID= 1 2674, luego su TGID = 1 2674.
Este proceso consta de dos hilos : el hilo principal (hilo 1) cuyo TID= 1 2674 y el hilo 2 cuyo TID = 1 2675 .
238
Ampliación de sistemas operativos
Esta información también se puede obtener usando el comando ps - L , que mostraría una salida similar
a la siguiente:
PID
10838
12674
12674
12 678
LWP
10838
12674
12675
12 678
TTY
pt s / 1
pt s / 1
pts / 1
pts / 1
T IME
00 : 00
00 : 00
00 : 00
00 : 00
:
:
:
:
00
00
00
00
CMD
bash
prog 6 1
prog 6 1
ps
El valor del TID aparece en la columna LWP.
•
Pila en modo núcleo y estructura thread_info
El núcleo en el momento de la creación de una tarea aparte de una estructura task_s truc t le asigna
también, entre otras, las siguientes estructuras de datos:
•
Pila en modo núcleo. También denominada pila del núcleo. Es una estructura que contiene los
marcos de pila de las funciones invocadas por el núcleo durante la ejecución de la tarea en modo
núcleo. Está pila está vacía cuando la tarea se ejecuta en modo usuario.
•
Estructura thread_i n f o . Contiene la dirección de la estructura task_s t ruc t de la tarea así
como otros parámetros de la misma.
Estas dos estructuras son creadas conjuntamente por el núcleo en una misma región que ocupa una
o dos páginas contiguas del espacio de direcciones virtuales del núcleo (ver Figura 6.3). La estructura
thread_in f o se localiza siempre en las direcciones virtuales más baj as de las páginas asignadas. Esta
disposición facilita al núcleo la localización de la estructura t a s k_s truc t de la tarea actualmente en
ejecución en un determinado procesador. Simplemente necesita conocer el valor del registro puntero
de pila del procesador. A partir del mismo puede determinar la página donde se ubica la estructura
thread_in f o , la cual apunta a la estructura ta s k_s t ruc t .
e
Ejemplo 6.2
En la Figura 6.3 se muestra un diagrama en el que se representa la pila del núcleo y las estructuras
t a s k_s t ruc t y thread_in f o de los hilos del proceso del Ejemplo 6. 1 . Se observa que las estructuras
t a s k_s t ruc t se encuentran enlazadas formando parte de la lista de procesos (lista de tareas) del núcleo.
Cada estructura task_s truc t tiene un puntero a su estructura thread_info asociada, la cual a su
vez también tiene un puntero recíproco. La pila del núcleo de cada hilo se implementa en una página
contigua a la página donde se localiza su estructura thread_in f o lo que facilita la localización de
dicha estructura a partir del puntero de pila.
•
SOBUNIX: el sistema operativo Linux
239
� - - - - - - - - - - - - - - - ,
1
1
1
1
1
�
1
1
1
1
1
i
Pila del núcleo
TID= l 2674
Puntero de pila ----.
t a s k- s t ru c t
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
,
1
1
1
•
1 o 2 páginas
contiguas
thread- i n f o
Pila del núcleo
TID= 1 2675
Puntero de pila ___.
t a s k s t ru c t
�
i
1
1
1
1
L---------------
1
1
1
1
1
1
1
1
•
thread- i n f o
Lista de procesos
(Lista de tareas)
Figura 6.3
6.3.2.
-
Relación existente entre las estructuras del núcleo asignadas a una tarea
Creación de procesos e hilos en Linux
La creación de procesos en Linux, al igual que en otros SOBUNIX, se puede realizar mediante las
llamadas al sistema fork y v f o rk. Además Linux dispone de la llamada al sistema c l one para crear
un nuevo proceso ligero asociado al proceso invocador de la llamada. Esta llamada es bastante potente
y flexible ya que permite especificar los recursos asociados al proceso creador que se desea que sean
accedidos por el proceso ligero que es creado. Esta llamada también permite crear un nuevo proceso de
la misma forma que las llamadas fork y vf ork.
La llamada al sistema c l one tiene la siguiente sintaxis:
r = c l one ( fun , u_p i l a , i nd , arg ) ;
Donde fun es la función que comenzará a ejecutar el proceso ligero creado cuando sea planificado
para ejecución. Dicha función recibe como argumentos los especificados en arg. El argumento u_p i l a
es l a dirección virtual de comienzo de l a región de pila en modo usuario del hijo. El argumento ind es un
mapa de bits que permite especificar los recursos del proceso padre que serán compartidos por el proceso
hijo. Cada bit de la máscara tiene asignado una constante simbólica, por ejemplo:
240
Ampliación de sistemas operativos
•
CLONE_THREAD. Si este bit está activado se crea un nuevo proceso ligero (hilo de usuario). En
caso contrario se crea un nuevo proceso monohilo.
•
CLONE_VM. Si este bit está activado entonces el proceso hijo comparte el mismo espacio de direc­
ciones virtuales del proceso invocador, excepto la región de pila.
•
CLONE_PARENT. Si este bit está activado el proceso hijo tendrá como proceso padre al mismo del
proceso invocador. En caso contrario el proceso invocador será el padre del proceso creado.
•
C LONE_F I L E S . Si este bit está activado el proceso hij o comparte los descriptores de archivos del
proceso padre. En caso contrario el proceso hijo recibe su copia independiente de los descriptores
de archivos.
•
CLONE_S I GHAND. Si este bit está activado el proceso hij o comparte los manipuladores de señales
del proceso padre. Los posibles cambios que se hagan en estos manipuladores son visualizados
tanto por el padre como por el hijo. En caso contrario el proceso hij o recibe su copia independiente
de los manipuladores de señales y los cambios que realice en ellos no son visualizados por el padre.
Si la llamada se ejecuta con éxito en r se almacena el TID del proceso (o proceso ligero) hijo creado.
En caso de error se almacena el valor - l .
e
Ejemplo 6.3
En la Figura 6.4 se muestra el código C del archivo ejecutable prog 6 2 cuya funcionalidad es parecida
a la del programa prog 6 1 del Ejemplo 6. 1 . La principal diferencia es que ahora se utiliza la llamada
al sistema c l one para crear un nuevo hilo ( CLONE_THREAD ) en vez de usar una función de la librería
Pthreads. El hilo 2 creado comparte el espacio de direcciones virtuales ( CLONE_VM) y los manipuladores
de señales ( CLONE_S I GHAND) del hilo invocador (hilo 1 ) .
•
El núcleo implementa el tratamiento de las llamadas c l one, f o r k y v f ork a través de la función del
núcleo do_fork ( ) . La cual utiliza a su vez a la función c opy_pro c e s s ( ) para configurar el descriptor
del proceso (estructura task_s t ruc t ) y otras estructuras de datos del núcleo asociadas al nuevo proceso
creado.
6.3.3.
Hilos del núcleo en Linux
En Linux los hilos del núcleo son asociados a la ejecución de procesos del sistema, que son procesos
iniciados por el propio núcleo que se encargan de realizar diferentes tareas administrativas como por
ejemplo: búsqueda de marcos de página libres, intercambio de procesos, copia de buffers modificados a
memoria secundaria, etc.
A diferencia de otras tareas los hilos del núcleo únicamente se ejecutan en modo núcleo y se crean
con la función del núcleo kerne l_ thread ( ) . Esta función para implementar la creación del hilo del
núcleo también invoca a la función do_fork ( ) .
Dependiendo del proceso del sistema al que esté asociado, un hilo del núcleo puede ser ejecutado
cuando se produce un determinado evento o periódicamente.
SOBUNIX: el sistema operativo Linux
241
# i ne lude < s t d i o . h>
# i n e l ude <pthread . h>
# i ne l ude < sys / sys e a l l . h>
# i ne l ude <ma l l o e . h>
# i ne lude < s ehed . h>
vo i d funl ( ) ;
v o i d mo s t rar_i n f o ( ehar e ) ;
vo i d ma i n ( )
{
int r ;
uns i gned ehar p i l a_h i j o [ 4 0 9 6 ] ;
r = e l one ( funl , p i l a_h i j o + 2 0 4 8 , CLONE_THREAD [ CLONE _VM [ CLONE_S I GHAND , NULL ) ;
if
( r= = - 1 ) {
p r i n t f ( " \ nError en la l l amada e l on e \ n " ) ;
mo s t rar_i n f o ( ' l ' ) ;
for ( ; ; ) ;
v o i d funl ( )
mo s t rar_i n f o ( ' 2 ' ) ;
for ( ; ; ) ;
vo i d mo s t rar_i n f o ( ehar e )
l ong i n t u , v ;
u=getpid ( ) ;
v= ( l ong int ) sys e a l l ( SYS _ge t t i d ) ;
p r i n t f ( " \ nH i l o
�:
P I D= % l d
Figura 6.4 -
6.4.
T I D= % l d \ n " , e , u , v ) ;
Código C del programa prog 6 2 del Ejemplo 6.3
Planificación en Linux
Linux es un sistema operativo de núcleo expropiable que utiliza como unidad de planificación a las
tareas. El núcleo asigna a cada tarea una prioridad que es un número entero positivo p comprendido
dentro del rango de valores [0, 1 39], siendo O la prioridad más alta posible y 1 39 la más baj a (ver Figura
6.5). El núcleo siempre planifica a la tarea en el estado ejecutándose de mayor prioridad (menor valor de
p ) . Dicha tarea será expropiada si entra en el estado ejecutándose una tarea de mayor prioridad.
A las tareas con prioridad p comprendida en el rango [ 1 00, 1 39] se les considera tareas convencio­
nales o tareas de tiempo compartido. A las tareas con prioridad p comprendida en el rango [0, 99] se
242
Ampliación de sistemas operativos
Prioridad más alta
o
,_
-
99
1 00
1-
1
1
1
1
1
Prioridad más baj a
Figura 6.5 -
1 39
Tareas de tiempo real
r-
Tareas convencionales
-
Escala de prioridades de ejecución de las tareas considerada por el núcleo de Linux
les considera tareas de tiempo real. Conviene señalar que el término tarea de tiempo real no debe ser
entendido en el sentido usual, es decir, una tarea que debe ser ejecutada en unos plazos determinados,
sino que se refiere al significado dado en las especificaciones POSIX 1 003 .4, es decir, una tarea con una
prioridad más alta que las tareas convencionales.
En el momento de su creación, la prioridad de una tarea es configurada al mismo valor que la priori­
dad de su padre. Posteriormente, si se trata de una tarea convencional, la prioridad de la tarea puede ser
cambiada utilizando las llamadas al sistema ni ce o s e tpr i or i ty. En el caso de una tarea de tiempo
real se pueden usar las llamadas s ched_se tparam o s ched_s e t s chedu l e r .
6.4.1.
Planificador usado en las versiones del núcleo de Linux anteriores a la 2.6.23
El planificador implementado en las primeras versiones de Linux no estaba bien escalado ya que el
tiempo empleado en seleccionar la tarea de mayor prioridad dependía del número de tareas en el estado
ejecutándose y del número de procesadores existentes en el computador.
Durante el desarrollo de la versión 2.5 de Linux el planificador fue rediseñado por completo con
objeto de asegurar que el tiempo de selección de la tarea de mayor prioridad fuese independiente del
número de tareas en el estado ejecutándose y del número de procesadores. A dicho planificador se le
3
conoce con el nombre de planificador 0 ( 1 ) .
3 La notación 0( ) se utiliza para designar la complejidad de un algoritmo matemático [Cormen et al. , 2009] .
SOBUNIX: el sistema operativo Linux
243
Estructuras de datos utilizadas en su implementación
El núcleo asigna a cada procesador existente en un computador una estructura de datos runqueue
(ver Figura 6.6). Esta estructura contiene, en otros, los siguientes campos:
•
arrays . Este campo contiene un array de dos estructuras p r i o_array_t . Cada una de estas
estructuras contiene las cabeceras de 140 colas PIFO de tareas en el estado ejecutándose, una por
cada posible valor de la prioridad. También contiene un mapa de bits, con un bit asociado a cada
cola, para saber si una cola está vacía o contiene alguna tarea. Además contiene un contador del
número total de tareas existentes en las 140 colas.
•
a c t ive. Puntero a la estructura pri o_array_t que contiene las colas de tareas activas que son
aquellas que consulta el planificador para seleccionar la próxima tarea que será planificada para
ejecución en el procesador al que esté asociada la estructura runqueue. El planificador siempre
selecciona para ejecutar a la primera tarea de la cola activa de mayor prioridad.
•
expi red. Puntero a la estructura pri o_array_t que contiene las colas de tareas expiradas que
son aquellas en las que ingresan las tareas (excepto si son de tiempo real) cuyo cuanto de ejecución
ha expirado en el procesador al que esté asociada la estructura runqueue.
Cuando no queda ninguna tarea en las colas de tareas activas entonces el núcleo intercambia los
valores de los campos ac t ive y exp i red, de tal forma que las colas de tareas expiradas pasan a ser las
colas de tareas activas, y viceversa.
Nótese que en un instante de tiempo determinado una tarea en el estado ejecutándose está asociada
a una determinada estructura runqueue y solo puede pertenecer a una única cola de tareas activas o
expiradas de entre las múltiples colas existentes en la estructura runqueue.
Una cola de tareas en el estado ejecutándose asociada a una determinada prioridad se implementa
como una lista doblemente enlazada de estructuras t a s k_s t ruc t . En la estructura t a s k_s truc t se
almacenan, entre otros, los siguientes parámetros de planificación de la tarea: prioridad, política de
planificación, tiempo de uso del procesador y tiempo promedio de espera en el estado dormido.
Políticas de planificación
Cada tarea tiene asignada una política de planificación que establece el algoritmo de planificación y
las reglas para colocar una tarea dentro de una determinada cola de prioridad. Se distinguen tres posibles
políticas de planificación4 :
•
SCHED_F IFO. Esta política utiliza un algoritmo PIFO para planificar a las tareas que tienen la mis­
ma prioridad. Luego las tareas son planificadas por orden de llegada y reciben un cuanto infinito.
Esta política de planificación solo puede ser utilizada por las tareas de tiempo real.
Esta política sigue las siguientes reglas a la hora de colocar a una tarea de tiempo real en una cola
de prioridad:
4Se está tomando como base la versión 2.6. 1 1 del núcleo de Linux.
244
Ampliación de sistemas operativos
runqueue
(asociada a CPU l )
[A] = Colas tareas activas, seleccionables para ser planificadas.
[E] = Colas tareas expiradas, solo ingresan aquí las tareas convencionales
que han consumido su cuanto.
a c t ive
exp i red
,___,__,_..-.____..._.-.__�
Cola tareas prioridad O
Cola tareas prioridad l
arrays [ O )
} [A ]
Planificador
Cola tareas prioridad 1 3 9
Cola tareas prioridad O
Cola tareas prioridad l
a rrays [ 1 )
}E;
'
Cola tareas prioridad 1 3 9
runqueue
(asociada a CPU2)
a c t ive
exp i red
Cola tareas prioridad O
Cola tareas prioridad l
arrays [ O )
�-----�r=-:=;:,_,__r---... Cola tareas prioridad 1 3 9
Cola tareas prioridad O
Cola tareas prioridad l
a rrays [ 1 )
}
[E ]
Planificador
4
�
} [A ]
Cola tareas prioridad l 3 9
Figura 6.6
-
Estructuras runqueue de un computador con dos procesadores
- Una tarea X de prioridad p que ha sido expropiada por otra tarea Y de mayor prioridad será
colocada al principio de la cola de tareas activas asociada a p.
Si se invoca a una llamada al sistema s ched_s e t s chedu l e r o s ched_s e tparam para
configurar la prioridad p de una tarea, dicha tarea será colocada, si se encuentra en el estado
ejecutándose, al principio de la cola de tareas activas asociada a p.
Cuando una tarea de prioridad p entra en el estado ejecutándose se coloca al final de la cola
de tareas activas asociada a p.
Si una tarea cede voluntariamente el uso del procesador mediante la invocación de una llama-
SOBUNIX: el sistema operativo Linux
245
da al sistema s ched_yi e l d, la tarea es colocada al final de la cola de tareas activas asociada
a p.
Una tarea X con política SCHED_F IFO continuará ejecutándose en un procesador excepto si se
producen alguno de los siguientes eventos : la tarea X se bloquea en espera de algún evento, entra
en el estado ejecutándose una tarea Y de mayor prioridad, o la tarea X invoca a la llamada al
sistema s ched_yi e l d para ceder el uso del procesador.
•
SCHED_RR. Esta política utiliza un algoritmo de turno rotatorio (round robín, RR) para planificar
a las tareas que tienen la misma prioridad. La duración del cuanto depende de su prioridad. Esta
política de planificación solo puede ser utilizada por las tareas de tiempo real.
Las reglas que utiliza esta política para colocar a una tarea de tiempo real en una cola de prioridad
son análogas a las utilizadas en la política SCHED_F I F O . Además si una tarea consume su cuanto
ésta es colocada al final de la cola de tareas activas asociada a p. Nótese que a diferencia de lo que
podría pensarse la tarea no es colocada en la cola de tareas expiradas, el objetivo de esta estrategia
es disminuir el tiempo de espera de las tareas de tiempo real.
Una tarea X con política SCHED_RR continuará ejecutándose en un procesador excepto si se pro­
ducen alguno de los siguientes eventos: la tarea X consume su cuanto de ejecución, la tarea X se
bloquea en espera de algún evento, entra en el estado ejecutándose una tarea Y de mayor prioridad,
o la tarea X invoca a la llamada al sistema s ched_yi e l d para ceder el uso del procesador.
Si una tarea X con política SCHED_RR es expropiada por otra tarea Y de mayor prioridad, cuando
X sea planificada otra vez para ejecución lo hará durante un tiempo igual al tiempo restante de
cuanto que le quedaba por ejecutar antes de ser expropiada.
•
SCHED_NORMAL (también denominada SCHED_OTHER en otras versiones). Es la política que se
aplica para planificar a las tareas convencionales. Esta política utiliza un algoritmo de turno rota­
torio para planificar a las tareas que tienen la misma prioridad. La duración del cuanto depende de
su prioridad.
Esta política sigue reglas similares a las otras políticas a la hora de colocar a una tarea en una
cola de prioridad, la principal diferencia es que si una tarea de prioridad p1 consume su cuanto, el
núcleo recalcula su prioridad (supóngase que ahora toma el valor pz) y coloca a la tarea al final de
la cola de tareas expiradas asociada al nuevo valor de prioridad (p2 ).
Asignación de la prioridad de una tarea
En Linux cada tarea tiene asignada una prioridad estática Pe · Además las tareas convencionales
también tienen asignada una prioridad dinámica Pd · El núcleo utiliza Pe para decidir qué tarea de tiempo
real planificar y para colocar a una tarea de tiempo real en una determinada cola de prioridad. Por el
contrario en el caso de una tarea convencional para realizar estas acciones utiliza Pd · Se cumple, por lo
tanto, que p = Pe en el caso de una tarea de tiempo real y p = Pd en el caso de una tarea convencional.
246
Ampliación de sistemas operativos
Si una tarea tiene asociada una política de planificación SCHED_RR o SCHED_NORMAL el núcleo
utiliza la prioridad estática de la tarea para determinar la duración de su cuanto q (en milisegundos) de
acuerdo con la siguiente fórmula [Bovet y Cesati, 2005] :
q =
{
( 1 40 - P e) · 20
( 1 40 - P e) · 5
si P e
si P e
<
�
1 20
1 20
(6. 1 )
Se observa que e l cuanto asignado a una tarea aumenta conforme mayor e s s u prioridad estática, es
decir, más bajo es el valor de P e · Por ejemplo, para P e = 1 3 9 se obtiene q = 5 ms. Mientras que para
P e = 1 00 se obtiene q = 800 ms. El máximo valor del cuanto es q = 2800 ms y se obtiene para la
prioridad estática más alta P e = O.
En el caso de una tarea de tiempo real el valor de su prioridad estática se encuentra dentro del rango
[0, 99] y puede ser configurado, por ejemplo, mediante la llamada al sistema shed_s e tparam.
En el caso de una tarea convencional su prioridad estática se encuentra dentro del rango [ 1 00, 1 39] y
puede ser configurado mediante las llamadas al sistema ni c e o s e tp r i o r i ty. Estas llamadas trabaj an
con el valor amable NI de una tarea que es un valor comprendido en el rango [ -20, 1 9] . La relación entre
la prioridad estática y el valor amable es la siguiente:
P e = NI + 1 20
(6.2)
Por defecto NI= O. Conviene tener presente que únicamente el superusuario puede establecer valores
negativos de NI, es decir, aumentar la prioridad estática de una tarea. Para visualizar el valor amable de
una cierta tarea se puede usar el comando top.
e
Ejemplo 6.4
Supóngase el programa prog 6 1 del Ejemplo 6. 1 . Supóngase que una vez lanzado en segundo plano se
introduce la orden
t op -n4 - p 1 2 6 7 5
que muestra en pantalla diferente información sobre la tarea con TID = 1 2675 . La información se actualiza
cuatro veces (opción -n4) antes de que finalice el comando. Supóngase que la última actualización que
se muestra en la pantalla es la siguiente5 :
P I D USER
1 2 6 7 5 j o s ema
PR
20
NI
o
VIRT
10132
RES
280
SHR S % C PU %MEM
216 S 0 . 0 0 . 1
TIME+ COMMAND
0 : 0 0 . 0 0 prog 6 1
S e observa que el valor amable N I es igual a O . Sustituyendo este valor en l a ecuación (6.2) s e obtiene
que la prioridad estática de la tarea es P e = O + 1 20 = 1 20, luego se trata de una tarea convencional.
Señalar que la columna PR de la salida del comando t op también contiene información sobre la prioridad
estática P e de la tarea. Ambos valores se relaciona a través de la expresión:
P e = PR + 100
5 Por cuestiones de espacio se ha omitido parte de la información que realmente aparecería en la pantalla.
(6.3)
SOBUNIX: el sistema operativo Linux
247
Para este ejemplo se observa en la salida que PR=20, luego sustituyendo este valor en (6.3) se obtiene
nuevamente que P e = 20 + 1 00 = 1 20.
Igualando las ecuaciones (6.2) y (6.3) se puede obtener la siguiente relación entre PR y NI :
NI = PR - 20
(6.4)
Se comprueba que para PR=20 se obtiene el valor NI=O.
•
La prioridad dinámica de una tarea convencional es recalculada por el núcleo cuando la tarea con­
sume su cuanto. Para calcularla utiliza la siguiente expresión [Bovet y Cesati, 2005] :
Pd = máx { 1 00, mín { Pe - b + 5 , 1 39} }
(6.5)
En la expresión anterior b es un factor denominado bonus, que puede tomar valores enteros dentro
del rango [0, 1 0] . Si b < 5 entonces se penaliza a la tarea ya que se reduce su prioridad dinámica. Por el
contrario si b > 5 se gratifica a la tarea ya que se aumenta su prioridad dinámica.
El valor del bonus se fija en función del tiempo promedio de espera en el estado dormido a través de
un conjunto de reglas heurísticas. El tiempo promedio de espera se incrementa cuando una tarea despierta
y se reduce cuando la tarea consume su cuanto o es expropiada.
Esta forma de calcular la prioridad dinámica favorece a las tareas limitadas por E/S frente a las tareas
limitadas por CPU. Luego el planificador 0( 1 ) consigue que las aplicaciones interactivas tengan un mej or
tiempo de respuesta que el que tenían con el planificador usado en las primeras versiones del núcleo de
Linux.
Otra funcionalidad reseñable del planificador 0( 1 ) es que monitoriza la carga de trabajo existen­
te en cada procesador y si lo considera necesario distribuye las tareas entre las estructuras runqueue
existentes para equilibrar la carga de trabajo de los procesadores.
Una de las principales fuentes de crítica del planificador 0( 1 ) es la utilización de reglas heurísticas
para establecer el valor de diferentes parámetros de planificación, como por ejemplo, el valor del bonus.
6.4.2.
Planificador utilizado a partir de la versión 2.6.23 del núcleo de Linux
El planificador 0( 1 ) ha sido el planificador utilizado en Linux hasta la versión 2.6.23 donde ha vuelto
a ser rediseñado. El planificador introducido en esta versión presenta un diseño mucho más modular
basado en la existencia de un planificador central y clases de planificación.
Cada clase de planificación encapsula los detalles de las políticas de planificación que soporta y
dispone de un planificador independiente. Una clase de planificación se implementa mediante una es­
tructura de tipo s ched_c l a s s la cual contiene punteros a las funciones que implementan al planificador
de la clase. Dichas funciones deben ser invocadas por el planificador central cuando se producen even­
tos relativos a la planificación que afectan a una tarea perteneciente a dicha clase, como por ejemplo: la
selección de la próxima tarea perteneciente a la clase que puede ser planificada y la colocación o elimina­
ción de una tarea en la estructura de datos (cola o árbol) que mantiene las tareas en el estado ejecutándose
perteneciente a dicha clase.
248
Ampliación de sistemas operativos
Existen dos clases de planificación:
•
•
Clase de tiempo real (shed_rt . e ) . A esta clase pertenecen las tareas de tiempo real. El planifica­
dor de esta clase implementa las políticas de planificación SCHED_F IFO y SCHED_RR. A diferencia
del planificador 0( 1 ) la duración del cuanto de las tareas de tiempo real planificadas con política
SCHED_RR es independiente de su prioridad e igual a 1 00 ms.
Clase completamente justa (shed_f a i r . e ) . A esta clase pertenecen las tareas convencionales. El
planificador de esta clase implementa las políticas de planificación SCHED_NORMAL, SCHED_IDLE
y SCHED_BATCH.
La política SCHED_BATCH fue introducida en la versión 2.6. 1 6 para dar soporte a tareas conven­
cionales de tipo batch que hacen un uso intensivo del procesador. Una tarea perteneciente a esta
política de planificación nunca puede expropiar a otra tarea. Por lo tanto estas tareas no interfieren
con las tareas interactivas de la clase SCHED_NORMAL .
La política SCHED_IDLE, disponible desde la versión 2.6.23, se utiliza para dar soporte a tareas
que pueden ser ejecutadas con la prioridad más baja.
Cada tarea pertenece a una determinada clase planificación y será tratada por el planificador de la
clase a la que pertenece de acuerdo con la política de planificación que tenga asignada.
El planificador central (s chedu l e) se encarga de seleccionar a la próxima tarea que será ejecutada
en cada procesador. Para realizar esta operación interactúa con los planificadores de cada clase invocando
las funciones apropiadas. En primer lugar invoca al planificador de la clase de tiempo real para que
seleccione una tarea de tiempo real para ser ejecutada. Si no existe ninguna tarea de tiempo real en el
estado ejecutándose entonces invoca al planificador de la clase completamente justa para que seleccione
una tarea convencional.
De esta forma, el planificador central implementa un algoritmo de planificación basado en priorida­
des, ya que siempre selecciona para ser ejecutada en un procesador a la tarea de mayor prioridad asociada
a dicho procesador.
Aparte de su diseño modular otra de las principales novedades del planificador de la versión 2.6.23
es que el algoritmo de turno rotatorio que se utilizaba en la política SCHED_NORMAL ha sido sustituido
por el algoritmo de planificación completamente justa (Completely Fair Scheduling, CFS). El algoritmo
CFS también se utiliza para las políticas SCHED_BATCH y SCHED_IDLE. Estas tres políticas son imple­
mentadas por el planificador de la clase completamente justa, también denominado planificador CFS .
El algoritmo CFS tiene como objetivo principal el realizar un reparto justo del tiempo de uso de un
procesador entre las tareas convencionales asociadas a dicho procesador. Para ello simula la existencia
de un computador ideal.
En un computador ideal si se tuvieran que ejecutar N tareas en paralelo con idéntico tiempo de ser­
vicio cada tarea recibiría 1 /N de la potencia de calculo del computador y todas terminarían de ejecutarse
en el mismo instante. Por ejemplo, si se tuviesen que ejecutar dos tareas en paralelo con un tiempo de
servicio requerido de 5 s, en un computador ideal cada tarea recibiría el 50 % de la potencia de cálculo
del computador con lo que tardaría en completarse 1 O s. Además ambas tareas finalizarán a la vez y
nunca tendrían que esperar por el uso de un procesador.
SOBUNIX: el sistema operativo Linux
rq
249
(asociada a CPU ! )
.....----.....--.___.
Cola tareas prioridad O
Cola tareas prioridad 1
rt
Cola tareas prioridad 99
Árbol roj o-negro
de tareas
convencionales
cfs
Figura 6.7 -
Diagrama de la estructura rq asociada a un procesador
En un computador real con un único procesador en un determinado instante de tiempo solo puede es­
tar ejecutándose una única tarea. La multitarea se simula conmutando rápidamente el uso del procesador
entre todas las tareas existentes . La tarea que se ejecuta en el procesador está siendo favorecida frente
al resto de las tareas que esperan para usarlo, las cuales son tratadas injustamente. El grado de injusticia
es directamente proporcional al tiempo de espera para usar el procesador. Obviamente conforme más
procesadores tenga el computador, el grado de injusticia se reduce pero no se elimina.
El algoritmo CFS utiliza como parámetro de planificación el tiempo de ejecución virtual de una tarea
que especifica cuando debería comenzar a ejecutarse dicha tarea si se dispusiera de un computador ideal.
El tiempo de ejecución virtual se almacena en la estructura t a s k_s truc t , en concreto en el campo
vrunt ime de la estructura s e . Cuanto mayor es la prioridad de la tarea menor es su vrunt ime .
El planificador CFS utiliza un árbol rojo-negro 6 para ordenar a todas las tareas convencionales aso­
ciadas a un determinado procesador. Las tareas son ordenadas en el árbol en función de su vrunt ime . En
el extremo del árbol situado más a la izquierda siempre se sitúa la tarea con menor valor de vrunt ime ,
que será la tarea convencional que será escogida para ser planificada sino existen pendientes tareas de
tiempo real.
Conforme se va ejecutando una tarea su tiempo de ejecución se añade a su vrun t ime que de esta
forma se va incrementando. Como resultado la tarea se va moviendo en el árbol hacia la derecha. O visto
de otra forma, las tareas que esperan para ejecutarse se van desplazando en el árbol hacia la izquierda.
Una tarea X se ejecutará hasta que otra tarea Y se coloque en el extremo más a la izquierda del árbol. En
dicho caso, se expropia el uso del procesador a X y se planifica para ejecución a Y.
El planificador CFS también permite trabajar a nivel de grupos de tareas con lo que es posible distri­
buir el tiempo de uso del procesador de manera justa entre los grupos de tareas existentes.
Otra novedad del planificador de la versión 2.6.23 se encuentra en la estructura runqueue, ahora
denominada estructura rq, que el núcleo asociada a cada procesador existente. En esta estructura los
6Es un árbol binario de búsqueda equilibrado [Cormen et al. , 2009] .
250
Ampliación de sistemas operativos
campos a c t ive, expi red y arrays han sido sustituidos por (ver Figura 6.7):
•
c f s . Es una estructura de tipo c f s_rq que permite implementar el árbol rojo-negro en que se
organizan las tareas en el estado ejecutándose pertenecientes a la clase justa completamente.
•
r t . Es una estructura de tipo r t_rq que permite implementar las 100 colas FIFO, una por cada
nivel de prioridad en el rango [0, 99] , en que se organizan las tareas en el estado ejecutándose
pertenecientes a la clase de tiempo real.
6.5.
Gestión de memoria en Linux
6.5.1.
Gestión del espacio de direcciones virtuales
En Linux el espacio de direcciones virtuales de un proceso comienza en la dirección O y se extiende
hasta la dirección TASK_S I Z E - 1 . El resto de direcciones virtuales desde TASK_S I Z E hasta 232 , en má­
quinas de 32 bits, o hasta 264 , en máquinas de 64 bits, están reservadas para el núcleo. TASK_S I Z E es
una constante cuyo valor depende de cada arquitectura.
Generalmente el tamaño del espacio de direcciones virtuales de un proceso es tres veces mayor que
el tamaño del espacio de direcciones del núcleo.
e
Ejemplo 6 .5
En la arquitectura Intel x86 de 32 bits el tamaño máximo del espacio de direcciones virtuales es de 4 GiB
con páginas de 4 KiB . Los primeros 3 GiB contienen el espacio de direcciones de un proceso mientras
que el espacio de direcciones del núcleo ocupa el último GiB .
En la Figura 6.8 se muestra la distribución que realiza Linux del espacio de direcciones virtuales de un
proceso en esta arquitectura. Las direcciones virtuales comprendidas entre O y el comienzo de la región
de código se utilizan para direccionar a los punteros nulos NULL . A continuación de la región de código
se ubican la región de datos y el montículo, el cual crece hacia direcciones virtuales crecientes. Los
archivos mapeados en memoria comienzan a ubicarse desde la dirección mmap_ba s e hacía direcciones
virtuales decrecientes. A continuación existe una región de protección entre la región de pila y la región
de archivos mapeados en memoria. La región de pila se ubica en la parte alta de memoria desde la
dirección TASK_S I Z E y crece hacía direcciones virtuales decrecientes. Las restantes direcciones están
reservadas para el espacio de direcciones del núcleo.
•
Linux utiliza una estructura tipo vm_area_s t ru c t para almacenar información sobre una determi­
nada región del espacio de direcciones virtuales de un proceso. Entre la información sobre una región
almacenada en esta estructura se encuentra la siguiente: permisos de acceso (solo lectura o lectura y escri­
tura), si es compartida o privada, dirección de crecimiento de la región, ubicación de su almacenamiento
de respaldo persistente (sistemas de archivos en disco o área de intercambio), etc.
Todas las estructuras vm_area_s t ruc t asociadas a las regiones de un mismo proceso son ordenadas
de dos formas distintas :
SOBUNIX: el sistema operativo Linux
251
O xFFFFFFFF
Espacio
de
direcciones
virtuales
del núcleo
OxCO O O O O O O
TAS K S I Z E
Pila
1
1
1
mmap_base
1
1
1
1
1
J
•
1
1
Protección
Archivos
mapeados en
meq¡oria
+
t
1
1
1
1
1
Montículo
Datos
Código
Ox0 8 0 4 8 0 0 0
1
1
1
O L---------------1
Figura 6.8 - Distribución del espacio de direcciones virtuales de un proceso en Linux en una arquitectura
lntel x86 de 32 bits
•
•
Lista enlazada de estructuras vm_area_s tru c t . Las estructuras se ordenan en orden ascendente
en función de la dirección virtual de comienzo de la región.
Á rbol rojo-negro de estructuras vm_area_s t ruc t . Es creado cuando el número de regiones es
superior a 32. Las búsquedas en un árbol rojo-negro son más rápidas que en una lista enlazada si
el número de elementos de la lista es elevado.
El núcleo consulta la lista o el árbol de estructuras vm_area_s t ruc t de un proceso cuando necesita
acceder a una dirección virtual determinada, o cuando necesita asignar una nueva región de memoria
252
Ampliación de sistemas operativos
virtual de un tamaño predeterminado.
Además el núcleo mantiene una estructura tipo mm_s truc t , accesible a través del campo mm de la
estructura tas k_s truc t asociada a un proceso, para recopilar toda la información que necesita conocer
sobre el espacio de direcciones virtuales de un proceso. En esta estructura se almacena las direcciones
virtuales de inicio y final de cada región. Además contiene un puntero mmap al comienzo de la lista
de la estructuras vrn_area_s t ru c t asociadas a las regiones del proceso. También contiene un puntero
mmap_rb al nodo inicial del árbol roj o-negro de estructuras vrn_area_s truc t (ver Figura 6.9).
VM
=
vm
a r e a s t ruct
task s t ru c t
mm s t ru c t --�----�---,
mm ----
Árbol roj o-negro
Figura 6.9
6.5.2.
-
Estructuras de Linux para gestionar el espacio de direcciones virtuales de un proceso
Gestión de la memoria física
Nodos y zonas
En computadores que disponen de múltiples procesadores la memoria principal puede ser organizada
de diferentes formas. Entre las organizaciones más utilizadas se encuentran las siguientes :
•
Organización de acceso a memoria uniforme (Uniform Memory Access, UMA). En este modelo
toda la memoria principal se organiza de forma contigua y todos los procesadores del computador
tardan lo mismo en acceder a cualquier posición de memoria.
•
Organización de acceso a memoria no uniforme (Non-Uniform Memory Access, NUMA). La
memoria principal se divide entre los procesadores existentes. Un procesador accede más rápido a
las posiciones de la memoria principal que tiene asignada, denominada memoria local, que a las
posiciones de las memorias locales de los otros procesadores .
Para dar soporte, tanto a la organización UMA como a la NUMA, Linux divide la memoria principal
en nodos de memoria. El tiempo de acceso a una posición de memoria de un determinado nodo es siempre
el mismo. Obviamente en una organización UMA existirá un único nodo de memoria, mientras que en
una organización NUMA existirá un nodo de memoria por cada procesador.
SOBUNIX: el sistema operativo Linux
253
Por otra parte, Linux considera las particularidades de direccionamiento (tamaño de registros, líneas
de direccionamiento para DMA, etc) de cada arquitectura hardware descomponiendo cada nodo de me­
moria en zonas, que son regiones contiguas de memoria principal. En el caso de la arquitectura Intel x86
de 32 bits cada nodo de memoria se descompone en tres zonas:
•
ZONE_DMA. Corresponde a las direcciones de memoria física por debaj o de 1 6 MiB . Esta zona
contiene los marcos de página que son utilizados para la realización de DMA en los antiguos
buses ISA.
•
ZONE_NORMAL . Corresponde a las direcciones de memoria física comprendidas entre 16 MiB y
896 MiB . Esta zona contiene los marcos de página que almacenan las páginas normales, es decir,
aquellas asociadas a los 4 primeros GiB del espacio de direcciones virtuales.
•
ZONE_H IGHMEM. Corresponde a las direcciones de memoria física por encima de 896 MiB . Esta
zona contiene los marcos de página que utilizan para almacenar páginas correspondientes a di­
recciones virtuales superiores a los 4 GiB , las cuales en arquitecturas de 32 bits no pueden ser
direccionados directamente. Esta zona en arquitecturas de 64 bits está vacía
Estructuras de datos utilizadas para gestionar la memoria principal
El núcleo numera de forma consecutiva comenzando desde O a todos los marcos de página en que
se descompone la memoria principal independientemente del nodo y la zona a la que pertenezcan. En
consecuencia no pueden existir dos marcos de página con el mismo número j aunque residan en nodos o
zonas diferentes.
El núcleo mantiene un descriptor de página por cada marco de página j existente. Cada descriptor
de página se implementa mediante una estructura de tipo page de 32 bytes que contiene, entre otros, los
siguientes datos sobre un marco:
•
Indicadores. Es una máscara de bits que se pueden configurar independientemente y que permiten
especificar los atributos del marco: bloqueado, referenciado, activo, modificado, privado, etc.
•
Contador de referencias. Se incrementa cada vez que la página contenida en este marco es referen­
ciada por el núcleo y se decrementa cuando se elimina una referencia. La página puede ser borrada
del marco cuando el contador toma el valor O. Si el contador es mayor que O la página no debería
ser borrada ya que ello seguramente originará un fallo de página.
•
Mapeado. Permite localizar el espacio de direcciones virtuales al que pertenece la página cargada
en el marco.
•
Punteros para formar diferentes listas de marcos. En un determinado instante de tiempo un des­
criptor de página estará formando parte de una de las siguientes listas : lista de bloques de marcos
contiguos libres de tamaño 2k marcos, lista de marcos de página activos (referenciados reciente­
mente) o lista de marcos de página inactivos (no referenciados recientemente).
254
Ampliación de sistemas operativos
Todos los descriptores de página de un mismo nodo se organizan en un array de descriptores de
página denominado mem_map. En una organización UMA existe un único array mem_map mientras que
en una organización NUMA existe un array mem_map por cada nodo en que se descompone la memoria.
El núcleo mantiene también un descriptor de zona por cada zona existente en un nodo. Cada descrip­
tor de zona se implementa mediante una estructura de tipo z one que contiene, entre otros, los siguientes
datos sobre una zona:
•
Número de marcos de página libres ( f r e e_pages).
•
Array de bloques de marcos de página libres ( f r e e_area). Es utilizado por el asignador a nivel
de página del núcleo, el cual implementa el algoritmo buddy. El elemento free_area [ k ] de esta
array apunta al descriptor de página del primer marco de página que forma parte de un bloque de
marcos de página contiguos libres de tamaño 2k . A su vez este descriptor de página contiene un
puntero al descriptor de página del siguiente marco que forma parte de dicho bloque. El descriptor
de página del último marco incluido en dicho bloque contiene un puntero al siguiente bloque de
marcos de página contiguos libres de tamaño 2k . En definitiva este array implementa las cabeceras
de las listas de bloques de marcos contiguos libres de la zona.
•
Cabecera de la lista de marcos de página activos (ac t i ve_l i s t) . Apunta al descriptor de página
del primer marco activo que forma parte de la lista. Esta lista es consultada por el algoritmo de
reemplazamiento de páginas que implementa el núcleo de Linux.
•
Cabecera de lista de marcos de página inactivos (inac t ive_l i s t). Apunta al descriptor de pá­
gina del primer marco inactivo que forma parte de la lista. Esta lista es consultada por el algoritmo
de reemplazamiento de páginas que implementa el núcleo de Linux.
Finalmente, el núcleo mantiene un descriptor de nodo por cada nodo de memoria existente. Cada
descriptor de nodo se implementa mediante una estructura de tipo pg_da ta_t y contiene, entre otros,
los siguientes datos :
e
•
Identificador del nodo (node_id) . Es un número entero positivo pequeño que identifica de manera
única al nodo de memoria. Puede tomar valores entre O y N - 1 siendo N el número total de nodos
existentes.
•
A rray de los descriptores de zona (node_z one s ) . El tamaño de este array será igual al número de
zonas en que se descomponga el nodo.
•
Puntero (node_mem_map) al array mem_map que contiene los descriptores de páginas del nodo.
El tamaño de este array será igual al número de marcos de página contenidos en las zonas en que
se descompone el nodo de memoria.
Ejemplo 6. 6
En la Figura 6. 1 0 se muestra un diagrama con las estructuras de datos usadas en Linux para gestionar
la memoria principal. Se supone la existencia de un único nodo de memoria (organización UMA) con
SOBUNIX: el sistema operativo Linux
255
tres zonas de memoria definidas : ZONE_DMA, ZONE_NORMAL y Z ONE_H IGHMEM. El descriptor de nodo
contiene un puntero al comienzo del array de descriptores de página mem_map . Además posee un puntero
a cada uno de los tres descriptores de zona. Nótese que por simplificar el diagrama únicamente se ha
representado el descriptor de la zona Z ONE_NORMAL .
El campo f r e e_area [ O ] del descriptor de zona apunta al descriptor de página del primer marco de
página que forma parte de un bloque de marcos de página contiguos libres de tamaño 2° = 1 marco. En
este ejemplo sería el descriptor de página del marco j = 40. A su vez este descriptor de página contiene
un puntero al siguiente descriptor de página del marco que forma parte de esta lista, en este ejemplo el
descriptor de página del marco j = 35.
También se ha representado el comienzo de la lista de marcos de página activas. El campo a c t i ve_l i s t
del descriptor de zona apunta al descriptor de página del primer marco de página que forma parte de esta
lista, en este ejemplo el descriptor de página del marco j = 43 . A su vez este descriptor contiene un
puntero al siguiente descriptor de página del marco que forma parte de esta lista, en este ejemplo el
descriptor de página del marco j = 44.
Descriptor de nodo
(estructura pg data)
node_me m_map
-
node_zone [ O ]
r-- node_zone [ l ]
Array d e descriptores de página
estructura rnern rnap)
Estructura page
Estructura page
Estructura page
node_zone [ 2 ]
node i
:
----.
Descriptor de zona
(estructura z one)
-
f re e__pag e s
f re e_area [ O ]
Estructura page
j =3 5
Estructura page
j =4 0
Estructura page
Estructura page
j=43
j =44
f re e_are a [ l ]
fre e_are a [ 2 ]
fre e_area [ l O ]
ac t ive l i st
-
inac t ive l i st
Zona
_______----
ZONE NORMAL
-
Principales estructuras de datos usadas en Linux para gestionar la memoria principal
considerada en el Ejemplo 6.6
Figura 6.10
-
•
256
Ampliación de sistemas operativos
Traducción de direcciones virtuales
Linux soporta tablas de páginas paginadas de hasta un máximo de cuatro niveles de paginación. El
número de niveles de paginación que utiliza depende de la arquitectura del computador donde se ejecuta.
Por ejemplo en la arquitectura Intel x86 se pueden utilizar hasta dos niveles de paginación.
Para implementar los cuatro niveles de paginación, el núcleo utiliza los siguientes tipos de tablas :
•
Directorio global. Cada proceso tiene asignado un único directorio de páginas global del tamaño
de una página. Si el proceso se encuentra activo entonces su directorio de páginas global reside en
memoria principal. Cada entrada en el directorio global apunta a una página del directorio superior.
•
Directorio superior. Puede ocupar varias páginas. Cada entrada en el directorio superior apunta a
una página del directorio intermedio.
•
Directorio intermedio. Puede ocupar varias páginas. Cada entrada en el directorio intermedio apun­
ta a una página que contiene una tabla de páginas.
•
Tabla de páginas. Puede ocupar varias páginas. Cada entrada de una tabla de páginas hace refe­
rencia a una página i del espacio de direcciones virtuales del procesos.
De acuerdo con esta organización de cuatro niveles de paginación una dirección virtual se descom­
pone en cinco campos (ver Figura 6. 1 1 ) cuyos tamaños dependen de cada arquitectura:
•
•
•
•
•
Índice directorio global (IDG). Contiene el número de la entrada del directorio global donde hay
que buscar el número m del marco que contiene a la página donde se ubica al directorio superior.
Índice directorio superior (IDS). Contiene el número de la entrada del directorio superior don­
de hay que buscar el número l del marco que contiene a la página donde se ubica al directorio
intermedio.
Índice directorio intermedio (IDI). Contiene el número de la entrada del directorio intermedio
donde hay que buscar el número k del marco que contiene a la página donde se ubica la tabla de
páginas.
Índice tabla de páginas (ITP) . Contiene el número de la entrada de la tabla de páginas donde hay
que buscar el número j del marco que contiene a la página i referenciada.
Desplazamiento. Contiene el desplazamiento dentro de la página i.
Nótese que en el caso de implementar únicamente tres niveles de paginación el tamaño del campo
IDS se configura a cero.
Para implementar solo dos niveles de paginación el tamaño del directorio superior y del directorio
intermedio se fij a a uno, es decir, solo constan de una única entrada. Además las referencias a esos niveles
de indirección no utilizados se eliminan en tiempo de compilación por lo que usar un esquema de cuatro
niveles de paginación en arquitecturas que solo soportan dos niveles no afecta al rendimiento del sistema.
SOBUNIX: el sistema operativo Linux
N°
,....
D irv
�
1
IDG
1
D;,,
1
257
de página i
....,_
IDS
IDI
ITP
1
Desplazamiento
1
gistro CR3
�
l rF I
!Marco
m
JI
Figura 6.1 1
1 Marco l 1�
D1rectono supenor
D1rectono global
Marco k
Marco 1
Marco m
D irro
4
Dir F3
! Marco k
w
D1rectono mtermed10
Marco j
1 Marco}
'
$
o
Tabla de pagmas
Págma 1
- Tablas de páginas de cuatro niveles de paginación utilizadas por Linux
Asignación de memoria
El subsistema de gestión de memoria para atender las necesidades de memoria de los procesos de
usuario y de los restantes subsistemas del núcleo implementa los siguientes asignadores de memoria:
•
Asignador a nivel de página. Asigna uno o varios marcos de página contiguos utilizando el al­
goritmo budd/ . Este algoritmo agrupa los marcos de página libres en M listas. La lista k con
k = O, . . . , M - 1 contiene los grupos de 2k marcos de página contiguos libres. Por ejemplo, supues­
to un tamaño de página de 4 KiB , la lista k = O contiene los bloques libres de memoria de 4 KiB
(2° = 1 marco), la lista k = 1 contiene los bloques libres de 8 KiB (2 1 = 2 marcos contiguos), la
lista k = 2 contiene bloques libres de 16 KiB (2 2 = 4 marcos contiguos), etc.
El funcionamiento del algoritmo buddy es el siguiente: cuando llega una petición de memoria
principal contigua de H marcos de páginas contiguos lo redondea por exceso a la potencia 2k más
cercana. Si la lista k no está vacía le asigna un bloque, el cual es borrado de la lista.
Si la lista k está vacía entonces busca un bloque en la lista k + l. Si dicha lista no está vacía coge el
primer bloque de la lista, cuyo tamaño es de 2k + I marcos, y lo divide en dos bloques de 2k marcos.
U no de estos bloques se coloca al final de la lista k, el otro se asigna a la petición.
7 Buddy es una palabra inglesa que puede traducirse por amigo o compañero.
258
Ampliación de sistemas operativos
Si la lista k + 1 también esta vacía, entonces busca en la lista k + 2. Si dicha lista no está vacía coge
el primer bloque de la lista, cuyo tamaño es de 2k + 2 marcos, y lo divide en dos bloques de tamaño
2k+ l marcos. Uno de los bloques se coloca al final de la lista k + 1 , el otro lo divide en dos bloques
de tamaño 2k marcos. Uno de estos bloques se coloca en la lista k, el otro se asigna a la petición.
Si la lista k + 2 también está vacía entonces busca un bloque en la lista k + 3, repitiéndose la
operación descrita, y así sucesivamente hasta encontrar un bloque libre. Si llega a la última lista y
está vacía entonces el núcleo envía una señal de error.
Cuando se liberan marcos de página, el algoritmo realiza la operación contraria, es decir, intenta
unir bloques contiguos de tamaño 2k ubicados en la lista k en bloques de tamaño 2k+ l que coloca
en la lista k + l . Si tiene éxito entonces realiza la misma operación sobre los bloques de la lista
k + 1 , y así sucesivamente. A las parej as de bloques que consigue unir se les denomina bloques
buddies, de ahí proviene el nombre del algoritmo.
El algoritmo buddy trabaj a sobre las listas de bloques de marcos contiguos libres de una zona, cu­
yas cabeceras se encuentran en el array free_area del descriptor de zona. Dada una determinada
petición de memoria es el núcleo el que determina de que zona se debe asignar el espacio, para
ello invocará al algoritmo buddy sobre dicha zona.
e
•
Asignador de la memoria del núcleo. Asigna fragmentos de memoria principal de tamaño menor
a una página. Para realizar esta función implementa un asignador slab.
•
Asignador vma l l o c . Se utiliza para asignar grandes cantidades de espacio virtual del núcleo con­
tiguo que no requiere que esté contiguo en memoria principal, como por ejemplo cuando se cargan
dinámicamente módulos del núcleo.
Ejemplo 6.7
Supóngase que el núcleo de Linux tiene que atender una petición de memoria principal de tamaño H= 1
marco. Supóngase además que en las listas de bloques de marcos contiguos libres de la zona de donde
se realizará la asignación únicamente existe en la lista k = 3 un bloque D 1 de 8 marcos contiguos libres
(ver Figura 6 . 1 2a) . El núcleo entonces comienza a aplicar el algoritmo buddy para atender la petición de
memoria. En primer lugar el algoritmo determina que la petición de memoria se puede atender con un
bloque de tamaño 2° = 1 marco y busca en la lista k = O un marco libre. Como no existe ninguno busca
entonces en la lista k = 1 un bloque libre de 2 marcos contiguos, pero esta lista también está vacía. Pasa
entonces a buscar en la lista k = 2 un bloque libre de 4 marcos contiguos pero tampoco existe ninguno.
A continuación busca en la lista k = 3 un bloque libre de 8 marcos contiguos. Selecciona entonces el
bloque D l .
Una vez seleccionado el bloque D l lo elimina de la lista k = 3 y lo divide en dos bloques C l y C2 de
4 marcos cada uno (ver Figura 6. 1 2b). A continuación coloca al bloque C2 en la lista k = 2 y al bloque
C l lo divide en dos bloques B l y B2 de 2 marcos cada uno (ver Figura 6. 1 2c). Posteriormente coloca al
bloque B2 en la lista k = 1 y al bloque B l lo divide en dos bloques A l y A2 de 1 marco cada uno (ver
SOBUNIX: el sistema operativo Linux
C2 (4)
C2 (4)
C2 (4)
C2 (4)
B2 (2)
B2 (2)
B2 (2)
A2 ( l )
Al (l)
A2 ( l )
Al (l)
(d)
(e)
259
D l (8)
C l (4)
B l (2)
(a)
(b)
(e)
Estado del conjunto de 8 marcos contiguos de memoria principal del Ejemplo 6.7 al ir
aplicando el algoritmo buddy
Figura 6.12 -
Figura 6. 1 2d). Finalmente, coloca al marco A2 en la lista k
Figura 6. 1 2e).
=
O, y asigna el marco A 1 a la petición (ver
•
Reemplazamiento de páginas
En Linux el reemplazamiento de páginas es realizado por kswapd, un proceso del sistema. Existe
una instancia de este proceso por cada nodo de memoria definido. kswapd se despierta periódicamente
y comprueba si el número de marcos de página libres en cada zona de memoria se encuentra dentro
de un determinado rango de valores. En caso afirmativo kswapd se vuelve a dormir. En caso negativo
selecciona un determinado número de marcos de página para ser incorporados en la lista de marcos
libres. El número de páginas que se seleccionan es un parámetro configurable, cuyo valor por defecto es
32. kswapd también puede ser despertado si el núcleo detecta una disminución drástica de memoria.
Para seleccionar los marcos de página cuyo contenido puede ser reemplazado Linux utiliza el algo­
ritmo para reclamar marcos de página (Page Frame Reclaiming Algorithm, PFRA) que es una variante
del algoritmo del reloj y una aproximación del algoritmo LRU.
El algoritmo PFRA trabaj a con la lista de marcos de página activos y con la lista de marcos de
página inactivos de cada zona. La lista de marcos de página activos contiene los descriptores de página
de los marcos que almacenan páginas que han sido referenciadas recientemente. Por su parte, la lista de
marcos de página inactivos contiene los descriptores de página de los marcos que almacenan páginas
que llevan algún tiempo sin ser referenciadas. Dentro de cada lista los descriptores de página de los
marcos son ordenados mediante una aproximación de la política LRU. Por ello a estas listas también se
las denomina de forma global como listas LRU.
Para decidir en que lista debe colocar un marco de página el algoritmo PFRA utiliza los indicadores
PG_r e f erenced y PG_ac t ive existentes en el campo f l ags de la estructura page asociado a un
descriptor de página. Por simplificar la notación se va a denotar a los indicadores PG_r e f erenced y
PG_a c t i ve con las letras r y a, respectivamente.
260
Ampliación de sistemas operativos
Cada vez que una página i cargada en un marco j es referenciada, el núcleo activa el indicador r
del marco, es decir, r = l. Por otra parte, si un marco pertenece a la lista de marcos de página activos
entonces a = 1 , mientras que si pertenece a la lista de marcos de página inactivos entonces a = O.
Cuando se ejecuta el algoritmo PFRA éste examina el indicador r de los descriptores de página de
los marcos de una determina zona. Si r estaba activado (r = 1) entonces lo desactiva (r = 0). Cuando
termina de examinarlos, comienza a realizar una segunda ronda. Nótese que durante el tiempo entre la
primera y la segunda comprobación de un mismo marco éste ha podido volver a ser referenciado y su
indicador r estar activado. Si durante la segunda ronda el algoritmo encuentra un marco j con r = 1
y cuyo bit r hubiera sido desactivado en la primera ronda entonces el algoritmo vuelve a desactivarlo,
activa a y coloca al marco en la lista de marcos de página activos . Luego para que un marco j ingrese en
la lista de marcos de página activos debe encontrarse con el bit r activado en dos rondas del algoritmo
PFRA.
Nótese que en función del par de valores (r, a) un marco de página puede encontrarse en alguno de
los siguientes estados:
•
Estado So: (r = O, a = 0). Un marco en este estado no ha sido referenciado recientemente y se
encuentra en la lista de marcos de página inactivos. Son los mej ores candidatos para ser seleccio­
nados para reemplazar su contenido, es decir, para ingresar en la lista de marcos libres.
•
Estado S 1 : (r = 1, a = 0). Un marco en este estado ha sido referenciado recientemente y se
encuentra en la lista de marcos de página inactivos . Puede llamar la atención que un marco que
contiene una página que ha sido recientemente referenciada se incluya en la lista de marcos de
página inactivos, esto se hace para tener en cuenta situaciones en las que un proceso referencia a
una página y no vuelve a hacerlo hasta mucho tiempo después . Obviamente dicha página no debe
figurar en la lista de marcos de página activos y puede ser sustituida.
•
Estado S 2 : (r = O, a = 1 ) . Un marco en este estado acaba de ingresar en la lista de marcos de página
activos, o ya estaba en la lista de marcos de página activos y no ha sido referenciado recientemente.
•
Estado S 3 : (r = 1 , a = 1 ) . Un marco en este estado se encuentra en la lista de marcos de página
activos y ha sido referenciado recientemente. Los marcos en este estado son los peores candidatos
para reemplazar su contenido ya que producirán fallos de página.
En definitiva si una página i es frecuentemente referenciada el estado del marco j que la contiene irá
pasando por los estados S 0 , S 1 , S 2 y S 3 . Por el contrario si una página dej a de ser referenciada, entonces
pasará del estado S 3 al estado S 2 , si se encontraba en la lista de marcos de página activos, o del estado
S 1 al estado So, si se encontraba en la lista de marcos de página activos.
También en situaciones de memoria libre muy escasa, marcos de la lista de marcos de página activos
pueden ser transferidos a la lista de marcos de página inactivos . O visto en términos de estados un marco
en el estado S 3 o S 2 puede pasar a los estados S 1 o S 0 , respectivamente. En la Figura 6. 1 3 se muestra el
diagrama de estados de un marco de página al aplicar el algoritmo PFRA 8 .
8Conviene señalar que existen otras posibles transiciones que n o han sido comentadas en e l texto ni incluidas en este
diagrama con objeto de simplificar su comprensión.
SOBUNIX: el sistema operativo Linux
261
Probabilidad de ser reemplazado
Alta
Baj a
r---------------------------------1
Memoria libre muy escasa
1
Memoria libre muy escasa
Lista de marcos inactivos
Figura 6.13 -
Lista de marcos activos
Diagrama de estados de un marco de página al aplicar el algoritmo PFRA
El algoritmo PFRA selecciona de la lista de marcos de página inactivos de una zona las páginas que
pueden ser reemplazadas. Primero escoge a los marcos en el estado So, ya que son los mej ores candidatos
para reemplazar su contenido. Cuando éstos se acaban entonces selecciona a los marcos en el estado S 1 .
6.6.
Gestión de archivos en Linux
La gestión de archivos en Linux es similar a la gestión de archivos de otros SOBUNIX descrita en
el capítulo 5 . En las siguientes secciones se describen las particularidades de Linux en relación con la
gestión de archivos. En concreto se describe la implementación que realiza Linux de la capa nodo virtual/
sistema de archivos virtual. Además se describen las características de tres de los sistemas de archivos
más conocidos desarrollados para Linux: EXT2, EXT3 y EXT4.
6.6.1.
Implementación de la capa nodo virtual/sistema de archivos virtual en Linux
Linux puede trabaj ar con diferentes tipos de sistemas de archivos : sistemas de archivos desarrollados
para Linux (EXT2, EXT3 , EXT4, ReiserFS , . . . ), sistemas de archivos desarrollados para otros SOBUNIX
(S5FS , UFS , VERITAS VxFS , . . . ), sistemas de archivos desarrollados para otros sistemas operativos no
basados en UNIX (FAT, NTFS , HPFS, HFS , . . . ), sistemas de archivos desarrollados para discos ópticos
(IS09660, UDF, . . . ), sistemas de archivos en red (NFS , Coda, AFS , CIFS , NCP, . . . ), y sistemas de archivos
especiales, que son aquellos que no consumen espacio de disco, sino que se implementan en la memoria
principal, como por ejemplo procfs ubicado en / p r o c .
262
Ampliación de sistemas operativos
Para soportar todos estos tipos de sistemas de archivos Linux utiliza la capa nodo virtual/ sistema de
archivos virtual. En Linux a esta capa se le denomina capa VFS y se implementa mediante las siguientes
estructuras de datos:
•
Objeto superbloque. Es la implementación que realiza Linux de un sistema de archivos virtual.
Es una estructura tipo sup e r_b l o c k que representa a un sistema de archivos activo. El núcleo
mantiene una lista enlazada de todos los superbloques existentes en memoria. En el caso de los
sistemas de archivos ubicados en disco, un superbloque contiene una copia del bloque de control
(superbloque) del sistema de archivos al que está asociado. Además contiene otros datos adiciona­
les, entre ellos, un puntero s_op a un array de punteros a funciones dependientes del sistema de
archivos que implementan todas las posibles operaciones sobre un superbloque: leer el superbloque
del disco, escribir el superbloque del disco, leer un nodo-i, borrar un nodo-i, etc.
•
Objeto nodo-i. Es la implementación que realiza Linux de un nodo virtual. Es una estructura tipo
inode que representa a un archivo activo. El núcleo mantiene una tabla de nodos-i con todos
los nodos-i cargados en memoria. En el caso de los sistemas de archivos ubicados en disco, un
nodo-i contiene una copia del nodo-i asociado al archivo en el disco. Además contiene otros datos
adicionales, como por ejemplo: un puntero al objeto superbloque asociado al sistema de archivos
al que pertenece el nodo-i, un contador de referencias, y un puntero i_op a un array de punteros
a funciones dependientes del sistema de archivos que implementan todas las posibles operaciones
sobre un nodo-i : crear, buscar, crear un enlace, etc.
•
Objeto entrada de directorio. Es una estructura tipo dent ry que representa a una entrada de un
directorio, es decir, a un componente de un nombre de ruta. Contiene, entre otros, los siguientes
datos: contador de referencias, puntero al objeto nodo-i asociado con el componente del nombre
de ruta, nombre del archivo, puntero al objeto entrada de directorio del directorio padre, puntero al
objeto superbloque asociado al sistema de archivos al que pertenece el archivo, y un puntero d_op
a un array de punteros a funciones dependientes del sistema de archivos que implementan todas
las posibles operaciones sobre un objeto entrada de directorios: comparar, borrar, liberar, etc.
El núcleo utiliza las estructuras dentry para implementar la caché de búsqueda de nombres en
directorios ( dent ry_c ache ) . Cada vez que tiene que analizar un nombre de ruta, comprueba si
el objeto entrada de directorio del componente que analiza se encuentra en la caché. En caso de
acierto se evita tener que acceder al disco para leer el nodo-i correspondiente. En caso de fallo
tras leer el nodo-i del disco crea un objeto entrada de directorio asociada a dicho componente
que incluye en la caché. Por ejemplo, si el núcleo ha tenido que analizar recientemente el nombre
de ruta 1 d i r l 1 archi vo l , entonces existirán en la caché un objeto entrada de directorio para el
directorio raíz 1 , otro para el directorio d i r l y otro para el archivo archi vo l .
•
Objeto archivo abierto. E s una estructura tipo f i l e que contiene l a información necesaria para
poder operar con un archivo abierto por un proceso, como por ejemplo: un contador de referencias,
el modo de apertura del archivo, el puntero de lectura/escritura, un puntero al obj eto entrada de
directorio asociados al archivo, y un puntero f_op a un array de punteros a funciones dependientes
SOBUNIX: el sistema operativo Linux
263
del sistema de archivos que implementan todas las posibles operaciones sobre un archivo: leer,
escribir, etc.
e
Ejemplo 6. 8
Supóngase que en un sistema Linux dos procesos A y B abren el mismo archivo. El núcleo crea un
objeto de archivo abierto para cada proceso (ver Figura 6. 14). Cada objeto de archivo abierto, contiene
un puntero al objeto de entrada de directorio asociada a la entrada del directorio del archivo. Dicho objeto
contiene un puntero al objeto nodo-i asociado al archivo y al objeto superbloque asociado al sistema de
archivos al que pertenece el archivo. El objeto nodo-i contiene una copia del nodo-i asociado al archivo
en el disco, el cual contiene la información necesaria para poder localizar en el disco los bloques de datos
del archivo.
s t ru c t
Objeto nodo-i
file
s t ru c t
s t ru c t
dent ry
s t ru c t
file
,' Obj etos archivos
abiertos
!
Objeto
entrada
directorio
\
:
l'
,
!'
i node
,....----l�--,
s t ru c t
!
l
B loques
O O de datos
O del archivo
sup e r_b l o c k
:,
l
l
:'
Partición de disco duro
sistema de archivos
Objeto superbloque
¡
•---------------------------------------------------------------------------------------------·
Estructuras en memoria principal
Figura 6.14 -
Estructuras de datos del Ejemplo 6.8 que implementan la capa VFS
•
6.6.2.
El sistema de archivos EXT2
La primera versión del núcleo de Linux utilizaba como sistema de archivos principal una adaptación
directa del sistema de archivos usado en MINIX. Este sistema de archivos tenía serias limitaciones en
relación al tamaño máximo de un archivo y al número de caracteres que podía tener un nombre. Por este
motivo en 1 992 se desarrolló otro sistema de archivos para sustituirlo: el sistema de archivos extendido
(EXTended filesystem, EXT). Sin embargo, el rendimiento y la funcionalidad del sistema EXT todavía
estaba lejos de las de otros sistemas de archivos comerciales. Por ello no tardó en ser mej orado y al año
siguiente se presentó el segundo sistema de archivos extendido (Second EXTended filesystem, EXT2)
que estaba basado en el sistema de archivos FFS de BSD.
264
Ampliación de sistemas operativos
Estructura de un sistema de archivos EXT2
Un sistema de archivos EXT2 cuando se crea en una partición de disco presenta una estructura
similar a la que se muestra en la Figura 6 . 1 5 . El primer bloque de la partición es el bloque de arranque
que contiene el código necesario para arrancar Linux si dicha partición se utiliza como partición activa.
El resto de la partición se divide en NG grupos de bloques. El tamaño máximo de un grupo es igual
a 8 · SB bloques, donde SB = 1 , 2 o 4 KiB es el tamaño de bloque, el cual se fija en el momento de la
creación del sistema. En cada grupo de bloques se distinguen los siguientes componentes :
•
Copia del superbloque. El superbloque ocupa un bloque y contiene información estadística y ad­
ministrativa del sistema de archivos: número mágico que identifica al sistema como de tipo EXT2,
tamaño de un bloque de datos, número total de bloques y de nodos-i, número de bloques y de
nodos-i libres, fecha y hora de la última modificación del sistema de archivos, hora y fecha del
montaje del sistema, etc.
Puesto que la información contenida en el superbloque es crítica para el funcionamiento del sis­
tema el superbloque se duplica en cada grupo de bloques en previsión de posibles errores o de
la corrupción del sistema. El núcleo normalmente trabaj a con el superbloque del primer grupo de
bloques.
•
Copia de la tabla de descriptores de grupo. Un descriptor de grupo es una estructura que datos
que describe a un grupo de bloques. Contiene la siguiente información sobre un grupo: la dirección
del bloque que contiene el mapa de bits de bloques de datos del grupo, la dirección del bloque que
contiene el mapa de bits de nodos-i del grupo, la dirección del bloque que contiene la tabla de
nodos-i del grupo, contador de bloques libres, contador de nodos-i libres y contador de directorios
existentes.
Todos los descriptores de grupos se organizan en una tabla de descriptores de grupo, la cual ocupa
varios bloques consecutivos . Al igual que sucede con el superbloque, la tabla de descriptores es
una estructura fundamental para el funcionamiento del sistema por lo que es duplicada en todos
los grupos de bloques, a continuación de la copia de superbloque. El núcleo normalmente trabaj a
con l a tabla de descriptores d e grupo ubicada e n el primer grupo d e bloques.
•
Mapa de bits de bloques de datos existentes en el grupo. Ocupa un bloque. Cada bloque de datos
existente en el grupo de bloques tiene asignado un bit en el mapa. Si el bit está desactivado significa
que el bloque está libre. Cuando el núcleo tiene que asignar bloques de datos para un archivo
consulta este mapa.
•
Mapa de bits de nodos-i existentes en el grupo. Ocupa un bloque. Su estructura y utilidad es similar
a la descrita para el mapa de bits de bloques de datos pero aplicada a los nodos-i.
•
Tabla de nodos-i existentes en el grupo. Ocupa varios bloques consecutivos. En EXT2 un nodo-i
tiene un tamaño de 1 28 bytes, luego en un bloque de la tabla se pueden almacenar SB / 1 28 nodos-i.
•
Á rea de datos. Contienen los bloques de datos de los archivos y directorios.
265
SOBUNIX : el sistema operativo Linux
Partición de disco
Grupo de bloques
o
Grupo de bloques
NG- 1
Grupo de bloques
1
���
�------�--�
- - - - - - - - - - - -
- - - - - - - - - - - - -
Mapa de bits de
nodos-i
Figura 6.15 -
Tabla
de nodos-i
� ��
Á rea de datos
Estructura en disco de un sistema de archivos EXT2
Implementación de directorios en EXT2
En un sistema de archivos EXT2 la lista de archivos y subdirectorios de un directorio se implementa
con entradas de tamaño variable. Cada entrada presenta la siguiente estructura:
•
Número de nodo-i. Es un campo de 4 bytes que contiene el número del nodo-i del archivo o
subdirectorio al que está asociada esta entrada del directorio.
•
Longitud en bytes de la entrada. Es un campo de 2 bytes que contiene la suma del tamaño de todos
los campos existentes en la entrada.
•
Longitud en bytes del nombre. Es un campo de 1 byte que contiene el tamaño en bytes de la cadena
de caracteres del nombre del archivo al que está asociada la entrada.
•
Tipo del archivo. Es un campo de 1 byte en el que se almacena un número entero positivo pequeño
que identifica el tipo del archivo: archivo regular ( 1 ), directorio (2), dispositivo modo carácter (3),
dispositivo modo bloque (4), FIFO (5), conector (6) y enlace simbólico (7).
•
Nombre del archivo. Este campo es de longitud variable y su tamaño máximo queda limitado a
256 bytes, luego la longitud máxima del nombre de un archivo es de 255 caracteres. Después del
nombre del archivo se incluye un carácter nulo \ 0 para marcar el final del nombre. Además se
incluyen tantos caracteres nulos como sea necesario hasta alcanzar una frontera de 4 bytes.
1
11
•
•
1
Las dos primeras entradas de la lista de un directorio siempre están asignadas a las entradas
que hacen referencia al propio directorio y al directorio padre, respectivamente.
11
,
1
•
1
y
266
e
Ampliación de sistemas operativos
Ejemplo 6 . 9
En la Figura 6. 1 6 se muestra un ejemplo de la implementación de un directorio en un sistema EXT2.
El directorio consta de 4 entradas : la primera asignada a la entrada
la segunda a la entrada
la
tercera asignada al archivo ordinario prueba y la cuarta asignada al directorio f o t o s . Las dos primeras
entradas tienen un tamaño de 1 2 bytes, mientras que las dos últimas tienen un tamaño de 1 6 bytes. Se
observa como el nombre de una entrada siempre termina con un carácter nulo \ O seguido de otros tantos
caracteres nulos como sea necesario hasta completar una frontera de 4 bytes.
1 • 1,
1 •
1
• 1,
1
o
Long1tud entrad a (2 b ytes
-
Longitud nombre ( 1 byte)
- Tipo de archivo ( 1 byte)
Nombre + carafteres de relleno
N° nodo-i ( 4 bytes)
•
35
12
1
2
\0 \0 \0
36
12
2
2
\0
\0
51
16
6
1
p
r
u
e
b
15
16
5
2
f
o
t
o
S
Figura 6.16 -
a \0
1
\0
\0 \0 \0
Implementación de un directorio en EXT2
•
Localización de los bloques de datos de un archivo en EXT2
Un nodo-i de un sistema EXT2, como suele ser habitual en los SOBUNIX, se asocia a un determinado
archivo y contiene, entre otros, los siguientes datos sobre el mismo: máscara de modo, UID, GID, tamaño
en bytes, fecha y hora del último acceso, fecha y hora de la última modificación de un campo del nodo-i
(excluidos los de fecha y hora), fecha y hora de la última modificación del archivo, contador de enlaces
duros, contador de bloques y localización de los bloques de datos del archivo.
Para localizar los bloques de datos del archivo su nodo-i mantiene las direcciones de los 1 2 primeros
bloques de datos del archivo, así como las direcciones de un bloque de indirección simple, un bloque de
indirección doble y un bloque de indirección triple.
Asignación de espacio en EXT2
En un sistema de archivos EXT2 el núcleo consulta los mapas de bits de los grupos de bloques para
decidir que espacio asignar. Con el objetivo de aprovechar mej or el espacio de la partición e intentar
reducir los tiempos de búsqueda en el disco el núcleo realiza la asignación de espacio siguiendo las
siguientes directrices [Tanenbaum, 2009] :
S OBUNIX: el sistema operativo Linux
267
•
Los bloques de datos de un mismo archivo se intentan alojar, siempre que sea posible, en bloques
de datos contiguos en el disco. Además cada vez que se necesita asignar un bloque para un archivo
se le preasignan por adelantado 8 bloques adicionales contiguos en previsión de que los vaya a
necesitar. Con estas medidas se pretende reducir la fragmentación externa del disco.
•
Los nodos-i de los directorios se dispersan entre los grupos de bloques existentes.
•
Un archivo se intenta aloj ar, si existe espacio, en el mismo grupo de bloques que su directorio
padre.
•
Los bloques de datos de un archivo se intentan aloj ar en el mismo grupo donde se encuentre su
nodo-i.
Otras características
Un sistema de archivos EXT2 proporciona soporte para enlaces simbólicos rápidos, los cuales se
implementan de la siguiente forma: si el nombre de ruta al que va hacer referencia el enlace simbólico
es mayor de 60 bytes entonces se almacena en los bloques de datos del archivo del enlace simbólico, en
caso contrario se almacena directamente en el nodo-i del enlace simbólico con lo que se ahorra espacio
en disco y el acceso es más rápido.
Por otra parte, EXT2 soporta archivos inmutables, que nunca pueden ser modificados (ni siquiera por
el superusuario), y archivos de solo-añadir, a los que solo se les puede ir añadiendo datos al final.
La consistencia de un sistema de archivos EXT2 suele verificarse si Linux no se ha cerrado correcta­
mente, por ejemplo debido a una falta de suministro eléctrico, o tras un número prefijados de montajes.
El programa 1 sbin/ e 2 f se k permite realizar esta verificación.
6.6.3.
El sistema de archivos EXT3
El tercer sistema de archivos extendido (Third EXTended filesystem, EXT3) es una versión mejorada
de EXT2 que fue introducida en la versión 2.4. 1 5 del núcleo de Linux liberada a finales de 200 1 . Cual­
quier sistema EXT2 puede ser convertido en un sistema EXT3 de forma fácil y sencilla sin necesidad de
formatear la partición de disco, ya que EXT3 fue diseñado pensando en ser totalmente compatible con
EXT2, de hecho utiliza la misma estructura en disco.
La principal diferencia entre EXT3 y EXT2 es que EXT3 implementa la técnica de registro por
diario (journaling), que consiste en que el sistema operativo genera un informe con las operaciones que
tiene que realizar sobre el sistema de archivos antes de realizarlas. Dicho informe se almacena en un
área reservada de la partición de disco denominada diario (joumal). Una vez que el informe ha sido
escrito en el diario se comienzan a realizar las operaciones planificadas. Cuando dichas operaciones han
sido completadas el informe se borra. Si se produce algún fallo antes de que se puedan completar todas
las operaciones planificadas, cuando se reinicia el sistema operativo éste lee el diario para comprobar si
existe un informe. En caso afirmativo se repiten una a una todas las operaciones para que el sistema de
archivos quede de nuevo en un estado consistente.
268
Ampliación de sistemas operativos
El tiempo para recuperar un sistema EXT3 , a diferencia de un sistema EXT2, ya no depende del
tamaño del sistema de archivos ni del número de archivos que contiene sino del tamaño del diario.
Otra característica importante de un sistema EXT3 , no disponible en EXT2, es que EXT3 puede
trabaj ar con fragmentos de archivos, es decir, datos de un archivo que no completan un bloque. Los
fragmentos de diferentes archivos se pueden almacenar en un mismo bloque, reduciéndose así la frag­
mentación interna.
6.6.4.
El sistema de archivos EXT4
El cuarto sistema de archivos extendido (Fourth EXTended filesystem, EXT4) es una versión me­
jorada de EXT3 cuya implementación estable fue introducida en la versión 2.6.28 del núcleo de Linux
liberada a finales de 2008. Entre las principales características de un sistema EXT4 destacan las siguien­
tes [Mathur et al. , 2007] :
•
Es plenamente compatible con EXT3 . Cualquier sistema EXT3 puede ser montado como sistema
EXT4 sin necesidad de formatear la partición de disco.
•
Incorpora el uso de extends para mejorar el rendimiento y reducir la fragmentación al trabaj ar
con archivos de gran tamaño. Un extend es un conjunto de bloques físicos contiguos. El tamaño
máximo que puede tener un extend depende del tamaño de bloque, por ejemplo con un tamaño de
bloque de 4 KiB un extend puede tener un tamaño máximo de 128 MiB .
•
Implementa comprobaciones adicionales en la técnica de registro por diario para mejorar su fiabi­
lidad.
•
Soporta la asignación de múltiples bloques para un mismo archivo en un sola operación lo que
reduce la fragmentación.
•
Implementa la técnica de reserva retrasada de espacio (Allocate-on-flush o delayed allocation) que
consiste en retrasar la asignación de espacio en el disco para realizar una operación de escritura
hasta justo el momento en que la información va a ser escrita. Nótese la diferencia con otros
sistemas de archivos donde la reserva de espacio se realiza previamente a realizar la operación de
escritura. Esta técnica se implementa de la siguiente forma: cuando se deben asignar bloques del
disco para realizar una operación de escritura el espacio necesario se resta del contador de espacio
libre del superbloque, pero no se asigna en el mapa de bits. En su lugar los datos que hay que
escribir son almacenados en buffers en la memoria principal hasta que el núcleo decide escribir
los buffers modificados en el disco. Usando esta técnica se consigue mejorar el rendimiento del
sistema y disminuir la fragmentación.
•
La comprobación del estado de un sistema EXT4 con el programa ext 2 f s c k se realiza mucho
más rápidamente ya que en EXT4 los grupos de bloques y las secciones de la tabla de nodos-i que
no están asignadas son marcadas como tales lo que permite a ext 2 f s c k saltárselas.
En general el soporte por parte del núcleo de un sistema EXT4 requiere de un menor uso del proce­
sador. Además su implementación y gestión mejora la velocidad de lectura y escritura en el disco.
SOBUNIX: el sistema operativo Linux
6. 7.
269
Resumen
El sistema operativo Linux es un SOBUNIX de código libre escrito en su primera versión por Linus
Benedict Torvalds. El acceso libre y gratuito al código fuente de Linux ha propiciado que miles de
personas en todo el mundo colaboren con Linus desinteresadamente en el desarrollo y mejora de Linux.
En Linux un proceso monohilo, un proceso ligero o un hilo del núcleo es considerado simplemente un
flujo de ejecución independiente o tarea que debe ser planificada y ejecutada. La creación de procesos
en Linux, al igual que en otros SOBUNIX, se puede realizar mediante la llamada al sistema f ork.
Además Linux dispone de la llamada al sistema e l one para crear un nuevo proceso ligero asociado al
proceso invocador de la llamada. Esta llamada es bastante potente y flexible ya que permite especificar
los recursos asociados al proceso creador que se desean que sean accedidos por el proceso ligero que es
creado. Esta llamada también permite crear un nuevo proceso de la misma forma que la llamada f o rk.
Linux es un sistema operativo de núcleo expropiable que utiliza como unidad de planificación a las
tareas. Cada tarea tiene asignada una prioridad, que desde el punto de vista del núcleo es un número
entero positivo comprendido dentro del rango de valores [0, 1 39], siendo O la prioridad más alta posible
y 1 39 la más baja. El núcleo siempre planifica a la tarea en el estado ejecutándose de mayor prioridad.
Dicha tarea será expropiada si entra en el estado ejecutándose una tarea de mayor prioridad. A las tareas
con prioridad comprendida en el rango [ 1 00, 1 39] se les considera tareas convencionales o tareas de
tiempo compartido. A las tareas con prioridad comprendida en el rango [0, 99] se les considera tareas de
tiempo real.
En Linux el tamaño del espacio de direcciones virtuales de un proceso es tres veces mayor que el
tamaño del espacio de direcciones del núcleo. Linux divide la memoria principal en nodos de memoria. El
tiempo de acceso a una posición de memoria de un determinado nodo es siempre el mismo. Obviamente
en una organización UMA existirá un único nodo de memoria, mientras que en una organización NUMA
existirá un nodo de memoria por cada memoria local de un procesador. Por otra parte, Linux considera
las particularidades de direccionamiento (tamaño de registros, líneas de direccionamiento para DMA,
etc) de cada arquitectura hardware, descomponiendo cada nodo de memoria en zonas, que son regiones
contiguas de memoria principal.
Linux soporta tablas de páginas paginadas de hasta un máximo de cuatro niveles de paginación. El
número de niveles de paginación que utiliza depende de la arquitectura del computador donde se ejecuta.
Por ejemplo en la arquitectura Intel x86 se pueden utilizar hasta dos niveles de paginación.
En Linux el asignador a nivel de página del subsistema de gestión del núcleo utiliza el algoritmo
buddy para asignar uno o varios marcos de página contiguos. Por otra parte, en Linux el asignador de la
memoria del núcleo implementa un asignador slab.
Para seleccionar los marcos de página cuyo contenido puede ser reemplazado Linux utiliza el algo­
ritmo para reclamar marcos de página o algoritmo PFRA que es una variante del algoritmo del reloj y
una aproximación del algoritmo LRU.
Los sistemas de archivos nativos de Linux más conocidos son: EXT2, EXT3 o EXT4. Además Linux
puede trabaj ar con otros tipos de sistemas de archivos . Para poder soportar diferentes tipos de sistemas
de archivos Linux utiliza la capa nodo virtual/ sistema de archivos virtual. En Linux a esta capa se le
denomina capa VFS y se implementa mediante las siguientes estructuras de datos : objeto superbloque
270
Ampliación de sistemas operativos
(implementa un sistema de archivos virtual), objeto nodo-i (implementa un nodo virtual), objeto entrada
de directorio y objeto archivo abierto.
6.8.
Lecturas recomendadas
Si se desea obtener una explicación adicional y ampliar los contenidos tratados en este capítulo se
pueden consultar, por ejemplo: [Bovet y Cesati, 2005], [Mauerer, 2008] , [Love, 20 1 0] y el capítulo 1 0
de [Tanenbaum, 2009] .
6.9.
Autoevaluación
6. 1 . ¿Qué se entiende por tarea en Linux? ¿ Y por grupo de hilos? (Respuesta en sección 6.3)
6.2. Enumerar y explicar brevemente la información contenida en una estructura task_s t ruc t de
Linux. (Respuesta en sección 6 . 3 . 1 )
6.3 . Dibujar e l diagrama de transición d e estados de las tareas e n Linux adecuadamente rotulado. Ex­
plicar brevemente el diagrama dibuj ado. (Respuesta en sección 6.3 . 1 )
6.4. Dibuj ar un diagrama, adecuadamente rotulado, donde s e representa la relación existente entre las
estructuras del núcleo de Linux asignadas a una tarea. Explicar brevemente el diagrama dibuj ado.
(Respuesta en sección 6.3 . 1 )
6. 5 . Explicar el uso y l a sintaxis de l a llamada al sistema c l on e . (Respuesta en sección 6.3 .2)
6. 6. ¿Qué función tienen los hilos del núcleo en Linux? (Respuesta en sección 6.3.3)
6.7. Dibujar un diagrama, adecuadamente rotulado, de la escala de prioridades de ejecución considera­
da por el núcleo de Linux. (Respuesta en sección 6.4)
6. 8. ¿Qué inconveniente presentaba el planificador implementado en las primeras versiones de Linux?
(Respuesta en sección 6.4. 1 )
6. 9. ¿Por qué s e caracteriza e l planificador 0( 1 ) de Linux? ¿En que versión de Linux s e introdujo?
(Respuesta en sección 6.4. 1 )
6. 10. ¿Para que s e utiliza l a estructura runqueue? ¿Qué información contiene?
(Respuesta en sección 6.4. 1 )
6. 1 1 . Explicar las políticas de planificación qué se distinguen en el planificador 0( 1 ) de Linux.
(Respuesta en sección 6.4. 1 )
6. 12. Explicar l a asignación de l a prioridad de una tarea en Linux. (Respuesta en sección 6.4. 1 )
SOBUNIX: el sistema operativo Linux
271
6. 13. Explicar las principales características del planificador utilizado a partir de la versión 2.6.23 del
núcleo de Linux. (Respuesta en sección 6.4.2)
6. 14. Explicar el funcionamiento del algoritmo CFS . (Respuesta en sección 6.4.2)
6. 15. ¿Para qué se utiliza la estructura rq? ¿Qué información contiene? (Respuesta en sección 6.4.2)
6. 16. Explicar la gestión del espacio de direcciones virtuales en Linux (Respuesta en sección 6.5 . 1 )
6. 17. Dibuj ar un diagrama, adecuadamente rotulado, de las estructuras de datos que utiliza Linux para
gestionar el espacio de direcciones virtuales de un proceso. (Respuesta en sección 6 .5 . 1 )
6. 18. Explicar l a distinción entre nodos y zonas que realiza Linux al gestionar l a memoria principal
(Respuesta en sección 6.5 .2)
6. 19. Enumerar y explicar brevemente las estructuras de datos que utiliza Linux para gestionar la me­
moria principal. (Respuesta en sección 6.5 .2)
6.20. Enumerar los tipos de tablas que el núcleo de Linux utiliza para implementar los niveles de pagi­
nación. Dibujar los campos en que se descompone una dirección virtual en Linux.
(Respuesta en sección 6.5 .2)
6. 21 . Enumerar los asignadores de memoria implementados en Linux. (Respuesta en sección 6.5 .2)
6. 22. Explicar el funcionamiento del algoritmo buddy (Respuesta en sección 6.5 .2)
6.23. ¿Qué proceso se utiliza en Linux para realizar el reemplazamiento de páginas? ¿Cuándo se ejecuta?
(Respuesta en sección 6.5 .2)
6.24. Explicar el funcionamiento del algoritmo PFRA. (Respuesta en sección 6.5 .2)
6.25 . Dibujar el diagrama de estados de un marco de página al aplicar el algoritmo PFRA.
(Respuesta en sección 6.5 .2)
6. 26. Explicar la implementación de la capa nodo virtual/sistema de archivos virtual en Linux.
(Respuesta en sección 6.6. 1 )
6. 27. Explicar la estructura de un sistema de archivos EXT2 (Respuesta en sección 6.6 .2)
6.28. Explicar la implementación de directorios en EXT2 (Respuesta en sección 6.6.2)
6. 29. ¿Qué directrices se siguen en EXT2 para asignar espacio en el disco? (Respuesta en sección 6.6.2)
6. 30. Enumerar las principales características de un sistema de archivos EXT3 .
(Respuesta en sección 6.6.3)
6. 31 . Enumerar las principales características de un sistema de archivos EXT4.
(Respuesta en sección 6.6.4)
272
Ampliación de sistemas operativos
6.10.
Ejercicios
6 . 1 Considérese el programa prog 6 1 (ver Figura 6.2) del Ejemplo 6. 1 . Contestar a los siguientes
apartados :
a ) ¿Es posible haciendo uso del comando ki l l enviar una señal a u n determinado hilo del
proceso asociado al programa prog 6 1 ?
b) Consultar el manual de ayuda, o l a bibliografía que considere necesaria, para determinar las
llamadas al sistema, las funciones de librerías o los comandos que se pueden utilizar en Linux
para enviar una señal a un determinado hilo de un proceso.
6.2 Considérese el programa prog 6 2 (ver Figura 6.4) del Ejemplo 6.3. Contestar a los siguientes
apartados :
a) ¿Qué sucede s i la llamada a l sistema c l one e s invocada únicamente con l a constante simbólica CLONE_THREAD?
b) ¿Y si se invocara con las constantes CLONE_THREAD 1 CLONE_VM?
e) ¿Y si se invocara con las constantes CLONE_THREAD 1 CLONE_S IGHAND?
d) ¿Qué conclusión se deduce del resultado de los apartados anteriores?
6 .3 Ejecutar en un sistema Linux el comando ps ax y explicar brevemente la información que muestra
en pantalla.
6.4 Ejecutar en un sistema Linux el comando t op y explicar brevemente la información que muestra
en pantalla.
6. 5 En una partición de 32 GiB se ha creado un sistema de archivos EXT2 que utiliza un tamaño de
bloque de 4 KiB . Determinar:
a) Tamaño máximo de un grupo de bloques.
b) Número de grupos de bloques en que se dividirá la partición.
e) Número de nodos-i que se pueden almacenar en un bloque.
d) Tamaño máximo que en teoría podría tener un archivo si la partición pudiera ser mayor de 32
GiB .
Capítulo 7
El sistema operativo MS -DOS
Objetivos docentes
Los objetivos docentes de este capítulo son los siguientes :
•
Conocer los orígenes del sistema operativo MS-DOS .
•
S aber cuáles son las características principales de MS-DOS .
•
Conocer la estructura de MS-DOS .
•
Saber cómo se invocan e implementan las llamadas al sistema en MS-DOS .
•
Conocer la interfaz con el usuario disponible en MS-DOS : el intérprete c omrnand . c orn.
•
Conocer los comandos básicos disponibles en c omrnand . c orn.
•
Saber cómo se implementan y controlan los procesos en MS-DOS .
•
Saber cómo se gestiona la memoria en MS-DOS .
•
Conocer la principales características de la gestión de archivos en MS-DOS .
•
Conocer la estructura y la gestión del sistema de archivos PAT.
•
Conocer la gestión de la E/ S en MS-DOS .
273
274
Ampliación de sistemas operativos
7 .l.
Introducción
MS-DOS (MicroSoft Disk Operating System, sistema operativo de disco de Microsoft) fue uno de los
sistemas operativos más utilizados en los computadores personales durante la década de los ochenta. En
la actualidad prácticamente ya no se utiliza, salvo en algunos sistemas empotrados. Pese a ello todavía
merece la pena estudiarlo ya que su diseño e implementación son relativamente simples. Además las
primeras versiones de Windows, que será objeto de estudio en el próximo capítulo, se ejecutaban sobre
este sistema operativo.
Este capítulo está dedicado al estudio del sistema operativo MS-DOS . En primer lugar se realizan
una serie de consideraciones generales acerca de MS-DOS : su cronología histórica, sus características
principales, su estructura, las llamadas al sistema, su secuencia de arranque y la interfaz con el usuario.
En segundo lugar se describe la implementación y control de procesos. En tercer lugar se estudia la
gestión de memoria. En cuarto lugar se estudia la gestión de archivos y el sistema de archivos PAT.
Finalmente se estudia la gestión de la E/ S .
Consideraciones generales sobre MS-DOS
7 .2.
721
.
.
.
Cronología histórica
A principios de los años 70 se desarrolló la tecnología de integración a gran escala (Large S cale Inte­
gration, LSI) que permitía almacenar cientos de miles de componentes electrónicos en un chip cuadrado
de silicio de aproximadamente un centímetro cuadrado. Usando esta tecnología se logró implementar el
primer microprocesador, es decir, un chip que integraba todos los componentes de un procesador. Con
la aparición del microprocesador nacieron los primeros computadores personales (Personal Computers,
PCs) que inicialmente recibieron el nombre de microcomputadores.
Desde el punto de vista de su arquitectura y tamaño los primeros microcomputadores eran pareci­
dos a los minicomputadores. Sin embargo, eran mucho más baratos, lo que hizo accesible su compra a
cualquier persona.
Uno de los primeros sistemas operativos para microcomputadores fue CP/M que se diseñó en 1 974
para ejecutarse con el microprocesador Intel 8080 de 8 bits. Este sistema operativo fue el dominante
durante cerca de cinco años.
A principios de los 80, IBM estaba buscando un sistema operativo para su línea de computadores
personales con procesadores Intel x86 de 1 6 bits. Digital Research le propuso utilizar su nuevo sistema
CP /M-86. Por su parte, Microsoft ofreció a IBM utilizar MS-DOS l. O. Este sistema operativo había
sido desarrollado por Tim Paterson con el nombre de 86-DOS para Seattle Computer Products, pero
Microsoft, que se dio cuenta de las posibilidades del mismo, se lo compró a Seattle Computer.
IBM finalmente se decantó en 1 9 8 1 por utilizar MS-DOS en sus computadores personales, baj o el
nombre de PC-DOS . Conviene señalar que aunque en sus primeras versiones PC-DOS y MS-DOS eran
idénticos, posteriormente comenzaron a existir diferencias entre ellos.
La incorporación de MS-DOS en los computadores personales de IBM hizo que este sistema ope­
rativo fuera utilizado por una multitud de usuarios y desarrolladores de software. Otros fabricantes de
El sistema operativo MS-DOS
275
computadores personales pronto se dieron cuenta que los sistemas operativos que incluían en sus compu­
tadores no podían competir, en cuanto a nivel de aceptación de los usuarios, con MS-DOS . Por ello
decidieron desarrollar sus propios sistemas operativos compatibles con MS-DOS . Así por ejemplo, Di­
gital Research en 1 988 desarrolló DR-DOS 3 . 4 1 que era compatible con MS-DOS 3 .30. Cuando Novell
compró Digital DR-DOS pasó a denominarse Novell DOS . Posteriormente Novell vendió DR-DOS a
Caldera, que durante un corto periodo de tiempo lo distribuyó, incluido su código fuente, con licencia
freeware con el nombre de OpenDOS . Otra variante de MS-DOS de código abierto es FreeDOS que
puede ser ejecutado en SOBUNIX.
Existe toda una familia de sistemas DOS : MS-DOS , PC-DOS, DR-DOS, OpenDO S , FreeDOS , etc.
Todos ellos presentan obviamente una serie de características comunes, pero también tienen sus propias
características particulares que les diferencian.
En relación con MS-DOS , miembro fundador de la familia DOS , a lo largo de la década de los
ochenta y principio de los noventa fueron apareciendo nuevas versiones compatibles con las anteriores
que fueron mej orando el sistema y añadiéndole características adicionales. La versión 6.22 lanzada en
1 994 fue la última que distribuía a MS-DOS separado del sistema operativo Windows. La última versión
de MS-DOS fue la 8.0 y se incluía con Windows Me lanzado en el año 2000.
En la actualidad MS-DOS y los restantes miembros de la familia DOS prácticamente ya no se utili­
zan, salvo en algunos sistemas empotrados. Por otra parte, conviene señalar que las versiones modernas
del sistema operativo Windows disponen del intérprete de comandos cmd . exe 1 que es una mejora del
intérprete de comandos c ommand . c om de MS-DOS .
7.2.2.
Características principales de MS-DOS
Las características principales del sistema operativo MS-DOS son:
•
Es un sistema monousuario, es decir, solo puede atender a un único usuario simultáneamente.
•
Es un sistema monotarea, es decir, solo se puede ejecutar un proceso y hasta que no termina
su ejecución no se puede ejecutar otro. Contrariamente a la creencia general MS-DOS no es un
sistema monoprogramado ya que en la memoria principal pueden estar cargados varios procesos.
•
El núcleo está escrito en lenguaje ensamblador.
•
El núcleo posee una estructura de tipo monolítica o simple.
•
No implementa un planificador de procesos. Los procesos son ejecutados en orden de creación y
hasta que no termina un proceso no se puede ejecutar otro.
•
Administra la memoria principal mediante la técnica de particionamiento dinámico.
•
Considera a los archivos como una secuencia de bits y delegan en las aplicaciones la interpretación
de los mismos.
1 A este intérprete se puede acceder, por ejemplo, a través del accesorio
Símbolo del sistema
de Windows.
276
Ampliación de sistemas operativos
•
Soporta tanto el acceso secuencial como el acceso aleatorio a los archivos .
•
E n los nombres d e archivos n o distingue entre minúsculas y mayúsculas.
•
Cada sistema de archivos presente en memoria secundaria es tratado como una unidad o volumen
lógico independiente, cada una de los cuales posee su propia estructura de directorios. MS-DOS
asigna una letra (C, D, E, . . . ) a cada unidad.
•
Dentro de cada volumen soporta una estructura de directorios de árbol de directorios. El directorio
raíz de un volumen se denota por el carácter ' \ ', que además se usa para separar los componentes
del nombre de ruta de un archivo. Para acceder al sistema de archivos de otra unidad se debe
especificar al comienzo de la ruta la letra de la unidad seguido de dos puntos, por ejemplo: e : \ .
•
En sus primeras versiones únicamente soportaba sistemas de archivos FAT. Aunque en sus últimas
versiones también pasó a soportar sistemas de archivos de discos ópticos (CD-ROM) como el ISO
9660.
•
La interfaz con el usuario es del tipo línea de comandos .
7.2.3.
Estructura del sistema operativo MS-DOS
El sistema operativo MS-DOS se descompone en las siguientes capas lógicas (ver Figura 7 . 1 ) :
•
Módulo B IOS . E s l a capa del sistema operativo encargada de comunicarse con el hardware. Contie­
ne los drivers residentes de los dispositivos de E/S (disco de arranque, pantalla, teclado, puerto de
impresión, reloj , etc) que son suministrados por defecto por el fabricante del computador. A estos
drivers se les denomina drivers residentes porque se encuentran almacenados permanentemente
en una memoria ROM. Durante el proceso de arranque del sistema estos drivers son copiados en
la memoria RAM formando parte del archivo i o . sys .
Q
Usuario
Intérprete de comandos
(COMMAND.COM)
Núcleo de DOS
MS-DOS
Módulo BIOS
Hardware
Figura 7.1 -
Estructura del sistema operativo MS-DOS
El sistema operativo MS-DOS
•
Núcleo de MS-DOS . Es una capa independiente del hardware propiedad de Microsoft Corporation
que se encarga de implementar los servicios o funciones del sistema: control de procesos, gestión
de memoria, gestión de archivos y gestión del reloj (fecha y hora). El código del núcleo de MS­
DOS se encuentra en el archivo msdo s . sys y es cargado en la memoria principal durante el
arranque del sistema.
•
Intérprete de comandos. Implementa una interfaz de línea de comandos que permite al usuario
invocar los servicios del núcleo y ejecutar programas mediante la introducción de órdenes. El
intérprete de comandos incluido en MS-DOS por defecto es c ommand . c om. Aunque un usuario
puede elegir otro intérprete compatible con MS-DOS de su elección, simplemente debe cambiar el
valor de la variable SHELL del archivo de configuración c o n f i g . sys .
724
.
277
.
.
Llamadas al sistema
En MS-DOS las llamadas al sistema son denominadas funciones del sistema y son invocadas direc­
tamente en lenguaj e ensamblador. Un programa para invocar a una función del sistema primero debe
cargar el número que identifica a la función del sistema (ver Tabla 7 . 1 ) y los parámetros de la misma
en diferentes registros. A continuación debe invocar la interrupción software int 2 lh que transfiere el
control al sistema operativo, el cual se encarga de invocar al manipulador de la interrupción.
Función del sistema
3 1H
3 9H
3 AH
3 BH
3 CH
3 DH
3 EH
3 FH
4 0H
4 1H
42H
43H
43H
4 7H
4 BH
4CH
4 DH
Tabla 7 . 1 -
Utilidad
Terminar un programa y permanecer residente en memoria
Crear directorio
Quitar directorio
Establecer directorio actual
Crear archivo
Abrir archivo
Cerrar archivo
Leer archivo
Escribir archivo
Eliminar archivo
Mover puntero d e archivo
Obtener atributos de archivo
Establecer atributos de archivo
Obtener directorio actual
Cargar y ejecutar programa (EXEC)
Terminar un programa
Obtener el código de retomo
Algunas ejemplos de funciones del sistema de MS-DOS
278
Ampliación de sistemas operativos
El manipulador de la interrupción realiza, entre otras, las siguientes acciones: salva el contenido
de los registros hardware en la pila de usuario del programa, cambia a una pila del sistema, usa el
identificador de la función para localizarla en la tabla de funciones del sistema e invoca a la función del
sistema apropiada.
Cuando termina de ejecutarse la función del sistema se devuelve el control al manipulador de la
interrupción que cambia a la pila del usuario, restaura el contenido hardware del programa que se estaba
ejecutando y le transfiere el control para que continúe su ejecución.
e
Ejemplo 7 . 1
En la Figura 7.2 se muestra a modo de ejemplo un fragmento de un programa en ensamblador [Duncan,
1988b] que permite ilustrar la invocación de llamadas al sistema en MS-DOS . En este ejemplo, se invoca
a la función del sistema 3 CH para crear y abrir el archivo prueba . txt dentro del directorio traba j o .
S i l a función del sistema s e ejecuta con éxito devuelve el manipulador (handle) del archivo, que e s el
equivalente al descriptor de archivo en los SOBUNIX.
fname db
' C : \ t raba j o \ prueba . tx t ' , O
fhand l e dw ?
man ipu l ador de l a r c h ivo
número de la func i ón
mov ah , 3 ch
xor
CX , CX
a t r i bu t o no rma l
mov dx , s eg fname
d i r e c c i ón de l nomb r e d e l archivo
mov ds , dx
mov dx , o f f s e t f name
i n t 2 lh
tran s f e r enc i a del c o n t r o l a l núc l e o de MS - DO S
jc
s a l tar en c a s o de e r r o r en l a creac i ón
error
mov fhandl e , ax
Figura 7.2 -
a lmac enar e l man i p u l ador del arch ivo
Ejemplo de invocación de una llamada al sistema en MS-DOS
•
7.2.5.
Arranque de MS-DOS
El programa de arranque de MS-DOS contenido en el primer sector de la partición del disco de
arranque de un sistema FAT en primer lugar comprueba si en dicha partición se encuentran los archivos
i o . sys y msdo s . sys . En caso negativo, muestra un mensaj e en pantalla para que el usuario cambie
el disco de arranque. En caso afirmativo, copia en la memoria principal los dos archivos 2 y transfiere el
2Dependiendo de la implementación el programa de arranque puede que solo copie en memoria el archivo i o . sys y éste
cuando comienza a ejecutarse se encarga de copiar en memoria a msdos . sys .
El sistema operativo MS-DOS
279
control a i o . sys .
El archivo i o . sys que se carga en la memoria principal queda formado por dos módulos. El primer
módulo es una copia de la BIOS . El segundo módulo es sys i n i t que es enlazado junto i o . sys y que es
invocado por el código de inicialización de la BIOS . sys i n i t es un programa propiedad de Microsoft
que se encarga de determinar la cantidad de memoria principal contigua disponible, transferirse a si
mismo a la parte alta de la memoria, e invocar a la rutina de inicialización del núcleo de MS-DOS
msdos . sys .
El núcleo de MS-DOS al inicializarse configura sus estructuras de datos y los manipuladores de las
interrupciones. A continuación invoca a cada uno de los drivers residentes existentes en la BIOS para
que determinen el estado del computador e inicialicen a los dispositivos de E/S . Finalmente devuelve
el control a sys ini t que invoca a diferentes funciones del sistema para abrir el archivo c o n f i g . sys .
Este archivo de texto, que puede ser configurado por el usuario, contiene diferentes parámetros y órdenes
de configuración del sistema, como por ejemplo la instalación de drivers instalables (ver sección 7.7.2).
Si sys ini t detecta la existencia del archivo c o n f i g . sys lo carga en memoria para procesarlo
línea a línea. Además asigna memoria para la caché de buffers de bloques de disco y para los bloques
de control de archivos. Asimismo carga en memoria los drivers instalables. Finalmente invoca a una
función del sistema para cargar en memoria y comenzar a ejecutar el intérprete de comandos, por defecto
c ommand . c om. Una vez finalizada su tarea el módulo sys i n i t se elimina de la memoria.
726
.
.
.
Interfaz con el usuario
La interfaz con el usuario que soporta MS-DOS es una interfaz de línea de comandos implementada
a través de un intérprete de comandos muy similar a los usados en los SOBUNIX. Por defecto dicho
intérprete es el programa c ommand . c om, aunque se puede utilizar cualquier otro intérprete compatible
con MS-DOS , como por ejemplo el intérprete 4DOS de JP Software. B asta con cambiar el nombre del
intérprete en la variable SHELL del archivo con f i g . sys .
Estructura de los comandos
Una orden o comando de un intérprete de MS-DOS es una cadena de caracteres que, de forma
general, tiene la siguiente estructura:
nombre_c omando arg_l arg_2 . . . arg_N / op_l / op_2 . . . / op_M
nombre_ c omando es el nombre del programa ejecutable que se desea ejecutar, arg_i i = 1 , 2, . . . , N
son los argumentos que acepta el programa y 1 op_j j = 1 , 2, . . . , M son opciones, también denomina­
dos modificadores, que permiten configurar el comportamiento del programa. Conviene señalar que los
intérpretes de MS-DOS al interpretar una orden no diferencian entre mayúsculas y minúsculas.
Si se desea obtener información sobre el significado, los argumentos y las opciones de un determi­
nado comando, se puede usar la orden:
help nombre_c omando
280
Ampliación de sistemas operativos
Comando
cd o chdi r
c opy
de l o eras e
dir
f ind
f o rma t
md o mkdir
ren o rename
type
Tabla 7.2 -
Utilidad
Cambiar el directorio de trabajo
Copiar uno o más archivos en otra ubicación
B orrar uno o más archivos
Mostrar el contenido (archivos y subdirectorios) de un directorio
B uscar una cadena de texto en uno o más archivos
Formatear partición de disco
Crear un directorio
Cambiar el nombre de uno o más archivo
Mostrar el contenido de uno o más archivos de texto
Algunos comandos básicos disponibles en el intérprete de comandos
c ommand . c om
El listado de comandos soportados por c ommand . c om es extenso. En la Tabla 7.2 se recopilan, a modo
de ejemplo, solamente algunos comandos básicos.
El intérprete c ommand . c om al igual que los intérpretes de comandos de los SOBUNIX soporta el
uso de comodines, el redireccionamiento de la E/S y el uso de tuberías.
e
Ejemplo 7 . 2
Supóngase que el directorio de trabajo actual de un usuario en MS-DOS es e : \ t rabaj o y que en dicho
directorio se encuentra alojado únicamente el archivo dat o s . txt. Si se escribe la orden
dir
en la pantalla se mostraría información sobre el contenido del directorio de trabajo:
E l vo l umen de l a un i dad e no t i ene e t i queta .
E l número de s e r i e de l vo lumen e s : 9 0 e e - E l BD
D i r e c t o r i o de e : \ trabaj o
2 0 / 04/2 012
2 0 / 04/2 012
2 0 / 04/2 012
< D I R>
11 : 47
< D I R>
11 : 47
11 : 37
4 0 0 da t o s . txt
4 0 0 byt e s
1 archivo s
2 dirs 5 7 6 . 7 1 6 . 8 0 0 bytes l i bre s
Para crear u n subdirectorio d e nombre borrador dentro del directorio d e trabajo actual s e puede usar,
por ejemplo, la orden
md borrador
Nótese que se ha utilizado el nombre de ruta relativa del subdirectorio, aunque por supuesto también se
podría haber utilizado el nombre de ruta absoluta. En dicho caso la orden hubiera sido la siguiente:
El sistema operativo MS-DOS
281
md c : \ trabaj o \ bo rrador
También se podría haber omitido la letra que designa la unidad:
md \ t rabaj o \ borrador
Se puede comprobar que dicho directorio ha sido creado usando la orden dir.
Si se desea que el directorio creado pase a ser el directorio de trabajo se puede usar la orden
cd borrador
Para copiar el archivo da t o s . txt dentro de este directorio se debe usar el comando c opy, cuya sintaxis
se puede conocer usando la orden
he lp c opy
De acuerdo con la información mostrada se deben proporcionar como argumentos de entrada del coman­
do c opy las nombres de ruta absolutas o relativas del elemento que se desea copiar y del directorio donde
se desea realizar la copia. Para este ejemplo, la orden a utilizar sería:
c opy \ t rabaj o \ dat o s . txt \ t rabaj o \ borrador
En este caso se han utilizado nombres de rutas absolutas. Obviamente para este ejemplo esta orden puede
escribirse mucho más abreviadamente teniendo en cuenta que el directorio origen es el directorio padre
del directorio destino y que el directorio destino es el directorio de trabajo actual, es decir, usando las
entradas
y ' . ':
11 •
• 11
c opy . . \ da t o s . txt .
•
Tipos de comandos
El intérprete c ommand . c om soporta tres tipos de comandos :
•
Comandos internos. S o n aquellos cuyo código d e ejecución s e incluye dentro del código del intér­
prete. Ejemplos de comandos internos son: c opy, d i r y de l .
•
Comandos externos. También denominados programas transitorios. Son aquellos cuyo código de
ejecución se encuentra en un archivo ejecutable en disco que debe ser buscado por el intérprete
y cargado en la memoria principal en una región denominada área de programas transitorios.
Ejemplos de comandos externos son: chkds k y backup .
•
Archivo de procesamiento por lotes (archivos batch) . Son archivos de texto con extensión . ba t
que contienen un listado de comandos (internos o/y externos) u otros archivos batch. También pue­
den contener sentencias propias de los lenguaj es de programación como i f o g o t o . El intérprete
va leyendo y ejecutando secuencialmente cada línea del archivo. Señalar la gran analogía existente
entre los archivos batch y los shell scripts de los intérpretes de los SOBUNIX.
282
Ampliación de sistemas operativos
Funcionamiento
El intérprete de comandos c orrunand . c om es cargado en la memoria principal durante el arranque del
sistema. El código del intérprete c orrunand . c om se estructura en dos partes:
•
Parte residente. Se carga en las direcciones bajas de memoria principal a continuación del núcleo
de MS-DOS y sus estructuras de datos y buffers. Contiene las rutinas que se encargan, entre otras,
de las siguientes tareas : atender diferentes combinaciones de teclas 3 , atender los errores críticos,
gestionar la terminación de los programas que se invocan desde el intérprete, y cargar la parte tran­
sitoria del intérprete. También en esta parte se almacena el código de los comandos internos. Esta
parte se denomina parte residente porque siempre permanece cargada en la memoria principal.
•
Parte transitoria. Se carga en las direcciones altas de la memoria principal. Contiene las rutinas
que se encargan de mostrar el apuntador en pantalla, leer las ordenes desde el teclado o desde un
archivo batch, y ejecutarlas. Esta parte se denomina parte transitoria porque puede ser eliminada
de la memoria si el programa que se va ejecutar desde el intérprete necesita usar más memoria de
la inicialmente asignada. Cuando un programa termina la parte residente del intérprete comprueba
si la parte transitoria está cargada en memoria, en caso negativo procede a cargarla.
Cuando c orrunand . com comienza a ejecutarse en primer lugar comprueba si existe en el directorio
de arranque el archivo aut o exec . bat . Este archivo contiene un conjunto de órdenes configurables por
el usuario para establecer las variables de entorno del intérprete de comandos y lanzar otros programas,
como por ejemplo, un antivirus.
Si el archivo aut o exec . bat existe entonces c orrunand . c om comienza a ejecutarlo. Una vez fina­
lizada su ejecución c orrunand . c om muestra en pantalla el apuntador y se queda a la espera de que el
usuario escriba una orden. El apuntador, por defecto es el nombre de ruta absoluta del directorio de tra­
baj o actual seguido del carácter ' > ' . Así por ejemplo si el directorio de trabajo es el directorio raíz ' \ ' de
la unidad " e : " entonces el apuntador sería "e : \ > " .
Cuando u n usuario escribe una orden, c orrunand . c om comprueba en primer lugar s i s e trata de una
orden interna. En caso afirmativo procede a ejecutarla puesto que su código ya se encuentra cargado
en memoria dentro del código del propio intérprete. En caso negativo, comprueba si se trata de una
orden externa o de un archivo batch. Para ello busca la existencia de un archivo homónimo a la orden
con extensión . c om, . exe o . ba t . Primero busca el archivo en el directorio de trabajo actual y si no
lo encuentra lo busca en los directorios especificados en la variable de entorno PATH. Si tampoco lo
encuentra en estas ubicaciones entonces muestra en la pantalla un mensaje de error. Si lo encuentra
invoca a la función del sistema 4BH (función EXEC) para que cargue el archivo en memoria y comenzar
su ejecución. Cuando el programa termine de ejecutarse el control regresa al intérprete de comandos que
vuelve a mostrar el apuntador en la pantalla.
3 Como por ejemplo [ c ontro l ] + [ e ] y [ c o n t ro l ] + [ break ] .
El sistema operativo MS-DOS
73
.
.
283
Implementación y control de procesos en MS-DOS
MS-DOS es un sistema operativo monotarea, hasta que no termina de ejecutarse un proceso no
puede comenzar a ejecutarse otro. El proceso que se ejecuta tiene un control total de los recursos de la
máquina. Su ejecución solo puede ser interrumpida por el sistema operativo para realizar el tratamiento
de las interrupciones. Esta característica simplifica enormemente el control de los procesos y elimina la
necesidad de implementar un planificador de procesos.
En MS-DOS el control de procesos es muy simple, el proceso que se está ejecutando (proceso padre)
puede crear otro proceso (proceso hijo) invocando a la función del sistema 4BH también conocida como
función EXEC. Esta función carga en memoria al proceso hijo y le transfiere el control. Mientras el pro­
ceso hijo se ejecuta el proceso padre permanece bloqueado en la memoria principal. Cuando el proceso
hijo va a terminar su ejecución invoca a una función del sistema para transferir el control de nuevo a su
proceso padre.
Cuando se crea un proceso, el sistema operativo crea las siguientes estructuras de datos asociadas al
proceso:
•
Bloque de entorno. Contiene las variables de entorno del proceso. El bloque de entorno de un pro­
ceso es inicialmente una copia del bloque de entorno de su proceso padre. Las variables de entorno
se pueden cambiar usando el comando s e t , bien directamente a través del teclado o mediante un
archivo batch.
•
Prefijo del segmento del programa (Program Segment Prefix, PSP). Contiene la información que
necesita conocer el sistema operativo para controlar la ejecución del proceso, como por ejemplo:
puntero al bloque de entorno, puntero al PSP del proceso padre, punteros a diferentes funciones
del sistema, y la tabla de manipuladores de archivos abiertos que son heredados del proceso padre.
En el PSP también se almacenan los argumentos del programa.
7.3.1.
Creación y ejecución de un proceso
La función del sistema 4 BH o función EXEC es el mecanismo existente en MS-DOS para crear y co­
menzar a ejecutar un proceso. EXEC en primer lugar intenta localizar el archivo ejecutable y comprueba
el tipo de programa que se desea ejecutar inspeccionando la cabecera del archivo ejecutable. MS-DOS
soporta dos formatos de archivos ejecutables :
•
Programas c om. Se caracterizan porque su tamaño está limitado a 64 KiB . Las regiones (código,
datos y pila) de un programa c om comparten un mismo segmento de memoria principal .
.
.
•
Programas exe. Su tamaño está limitado a la memoria principal disponible. Las regiones de un
programa exe pueden ocupar múltiples segmentos de memoria principal.
.
.
En segundo lugar EXEC asigna al nuevo proceso un bloque de entorno. A continuación asigna al
proceso un bloque de memoria en el área de programas transitorios de memoria principal (ver sección
7 .4). En este bloque carga la región de código y de datos del proceso, y crea su pila. Además crea e
284
Ampliación de sistemas operativos
inicializa el PSP del proceso. Finalmente EXEC transfiere el control al nuevo proceso para que comience
a ejecutarse.
Durante el tratamiento de la interrupción software int 2 1 H asociada a la invocación de la función
del sistema EXEC, el contexto a nivel de registros del proceso padre es almacenado en su pila. Además
la dirección de la pila es almacenada en su PSP. Cuando el proceso hijo termina, se busca la dirección del
PSP del proceso padre en el PSP del proceso hijo. Una vez encontrada se accede al PSP del padre para
localizar la dirección de su pila, restaurar su contexto hardware y continuar con la ejecución del proceso
padre.
La función del sistema EXEC dispone de un parámetro que permite especificar su comportamiento:
cargar y ejecutar, solo cargar o solo ejecutar.
732
.
.
.
Terminación de un proceso
En MS-DOS existen dos funciones del sistema que producen la terminación de un proceso: la función
4CH y la función 3 1H. La función 4CH libera la memoria principal asignada al proceso que invoca a la
función, cierra los archivos abiertos, escribe en el disco los buffers de la caché que han sido modificados
por el proceso, almacena el código de finalización o retomo en un registro, y transfiere el control al
proceso padre.
El código de finalización o retorno de un proceso de MS-DOS es similar al estatus de salida de los
procesos en los SOBUNIX. El proceso padre puede recuperar el código de finalización de su proceso
hijo invocando a la función del sistema 4 DH.
Por su parte, la función del sistema 3 1 H se limita a transferir el control al proceso padre. A un proceso
que termina mediante la invocación de esta función se le denomina proceso TSR (Termínate and Stay
Resident, terminar y permanecer residente) ya que todos sus recursos, salvo quizás el bloque asignado
en el área de programas transitorios, siguen estando asignados al proceso aunque éste haya terminado.
De forma general los procesos TSR se utilizan en MS-DOS para ejecutar drivers o manej adores de
interrupciones escritos por el usuario. Los procesos TSR se activan mediante interrupciones hardware
o software. Cuando terminan de realizar su tarea invocan a la función 3 1 H para terminar y permanecer
residentes a la espera de volver a ser invocados por otra interrupción.
7.4.
Gestión de memoria en MS-DOS
Cuando se desarrolló el sistema operativo MS-DOS los computadores personales disponían general­
mente de 64 KiB de memoria principal. Por otra parte, los procesadores 8088 y 8086 de Intel usados en
los primeros PCs de IBM en los que se iba a ejecutar MS-DOS podían direccionar hasta 1 MiB , lo cual
era un gran avance para la época. Este es el motivo por el que las primeras versiones de MS-DOS traba­
j aban considerando la existencia de 1 MiB de memoria, de los cuales solo 640 MiB podían ser utilizados
por el sistema operativo y las programas.
Posteriormente la aparición de computadores personales con mayor capacidad de memoria y de apli­
caciones software que requerían de más memoria, hizo que MS-DOS incluyera diferentes mecanismos
El sistema operativo MS-DOS
285
para poder superar el límite de los 640 MiB , entre ellos: el uso de la memoria alta (high memory), el
soporte de las especificaciones de memoria expandida (Expanded Memory Specifications, EMS) y el
soporte de las especificaciones de memoria extendida (Extended Memory Specifications, XMS) . Los
lectores interesados en conocer las características de estos mecanismos pueden consultar la referencias
que se indican en la sección 7 . 9 .
Una vez arrancado e l sistema operativo MS-DOS la memoria principal queda distribuida general­
mente de la forma que se muestra en la Figura 7 . 3 . En la parte más baj a de la memoria se almacena la
tabla de vectores de interrupción. A continuación se almacenan la tabla de las funciones de la BIOS y
la tabla de las funciones del sistema MS-DOS . En la siguiente zona de memoria se almacena el núcleo
de MS-DOS . Luego existe un área reservada para la memoria caché de buffers de disco. Por encima de
la caché se alojan los drivers instalables y la parte residente del intérprete c ommand . c oro. Justo a con­
tinuación comienza el área de programas transitorios reservada para la carga de programas invocados
1 MiB
BIOS
Libre
Tarj eta de video
640 KiB
Command.com
(transitorio)
Á rea de programas
transitorios
Command. com
(residente)
Drivers instalables
Caché de buffers
Núcleo de DOS
Tablas de funciones
DOS y BIOS
o
Figura 7.3 -
Tabla de vectores
de interrupción
Distribución de la memoria principal que realiza MS-DOS
286
Ampliación de sistemas operativos
por el usuario. A continuación se aloj a la parte transitoria del intérprete c ommand . c om hasta alcanzar
el límite de 640 KiB . Esta zona puede ser utilizada por el programa en ejecución si requiere de más
memoria. El área de memoria comprendida entre 640 KiB y 1 MiB es utilizada por la tarj eta de vídeo y
para almacenar una copia de la B IOS .
Cuando MS-DOS tiene que asignar memoria principal a un programa utiliza el espacio del área de
programas transitorios. Este área de memoria es gestionada por el sistema operativo mediante la técnica
de particionamiento dinámico. La memoria se asigna en bloques o particiones4 . El tamaño mínimo que
puede tener un bloque es 1 6 bytes, unidad denominada párrafo en MS-DOS . El tamaño máximo de una
partición queda limitado por el tamaño del área de programas transitorios.
Para implementar la técnica del particionamiento dinámico el núcleo enlaza todos los bloques de
memoria existentes formando una lista (ver Figura 7 .4). Para ello reserva los primeros cinco bytes de un
bloque, a modo de cabecera del bloque, para almacenar la siguiente información: puntero al siguiente
bloque de la lista, tamaño del bloque en párrafos, estado del bloque (libre u ocupado) y puntero al PSP
del programa al que está asignado el bloque (si éste no está libre).
Cabecera
Cabecera
Bloque 2
1
1
l1
Cabecera
Ocupado
Libre
Cabecera
B loque 3
Bloque 4
Ocupado
Libre
11
Figura 7.4 -
Lista enlazada de bloques de memoria principal mantenida en MS-DOS
MS-DOS se encarga de realizar la gestión de la memoria únicamente cuando se le solicita a través
de alguna de las siguientes funciones del sistema:
•
Función 4 8 H. Asigna un bloque de memoria. Cuando MS-DOS tiene que asignar un bloque de
memoria de tamaño S busca en la lista de bloques un bloque de tamaño igual o mayor a S . Por
defecto utiliza el algoritmo del primer ajuste (first fit) para realizar la búsqueda. Este algoritmo
comienza a buscar desde el principio de la lista y asigna el primer bloque que encuentra con un
tamaño igual o mayor a S . Este algoritmo es sencillo de implementar además mínimiza el tiempo
de búsqueda. MS-DOS también soporta el algoritmo del mejor ajuste (best fist), que busca en toda
la lista un bloque cuyo tamaño sea igual o exceda lo menos posible del tamaño S requerido, y el
algoritmo del último ajuste (last fist), busca en la lista el bloque ubicado en la direcciones más
altas de tamaño igual o mayor al tamaño S requerido. El algoritmo a utilizar se especifica como un
parámetro de la función.
4En MS-DOS un bloque o partición también recibe el nombre de arena.
287
El sistema operativo MS-DOS
•
Función 4 9 H. Libera un bloque de memoria. Cuando MS-DOS tiene que liberar un bloque intenta
fusionarlo con otros bloques libres contiguos para formar un bloque libre de mayor tamaño.
•
Función 4AH. Redimensionar un bloque de memoria. Por defecto, MS-DOS a un programa c om
le asigna el bloque de memoria libre de mayor tamaño que encuentre, aunque no lo necesite.
En el caso de un programa exe busca en la cabecera del archivo ejecutable el espacio mínimo
y máximo de memoria que el programa necesita. MS-DOS en primer lugar intenta asignarle un
bloque de tamaño igual o mayor a la máxima memoria que va a utilizar el programa. Si no existe
ninguno disponible le intenta asignar un bloque de tamaño igual o mayor a la mínima memoria.
Si tampoco existe ninguno disponible el programa no puede ejecutarse. Señalar que cuando un
programa está bien diseñado debe devolver al sistema la memoria principal que no vaya a utilizar,
para ello debe invocar a esta función del sistema.
.
.
Estas funciones pueden ser invocadas tanto por un programa de usuario como por otras funciones del
sistema. Por ejemplo la rutina que implementa la función EXEC invoca a la función 4 8 H para asignar un
bloque de memoria al proceso que se va a cargar en memoria.
7.5.
Gestión de archivos en MS-DOS
7.5.1.
Archivos
En MS-DOS la información contenida en un archivo se estructura como una secuencia lineal de
bytes. MS-DOS no interpreta dicha información, simplemente se limita a operar (leer o escribir) con ella
a nivel de byte. Es el proceso en ejecución el encargado de interpretar la información contenida en el
archivo sobre el que ha solicitado operar al sistema operativo. En MS-DOS el acceso al contenido de
un archivo se puede realizar de forma secuencial o de forma directa. MS-DOS distingue dos tipos de
archivos : archivos regulares (archivos binarios y archivos ASCII) y directorios.
El nombre de un archivo es una cadena de caracteres ASCII. La longitud máxima del nombre de
un archivo es de ocho caracteres más una extensión de tres caracteres. Por ejemplo, prueba . txt sería
un nombre de archivo válido en MS-DOS . Señalar que estos límites están impuestos por el sistema de
archivos FAT (ver sección 7.6), que es el sistema de archivos principal utilizado por MS-DOS .
La implementación de la gestión de archivos utilizada en la primera versión de MS-DOS estaba ins­
pirada en la del sistema operativo CP /M, que se basaba en el uso de una estructura de datos denominada
bloque de control del archivo (File Control Block, FCB). Un FCB es una estructura que se crea en el
espacio de direcciones del proceso y que se asocia a un archivo abierto. Cuando un proceso desea abrir o
crear una archivo, primero debe inicializar un FCB con la unidad, el nombre y la extensión del archivo.
A continuación debe invocar a una función del sistema para abrir o crear el archivo, pasándole como ar­
gumento la dirección del FCB . Si el archivo es abierto o creado con éxito, entonces MS-DOS almacena
en el FCB una copia de la información existente en la entrada del directorio asociada al archivo. En el
FCB también se almacena el puntero de lectura/ escritura. Cada vez que un proceso desea leer o escribir
un archivo debe invocar a la función del sistema apropiada pasándole como argumento la dirección del
FCB .
288
Ampliación de sistemas operativos
A partir de su versión 2.0 MS-DOS implementó un modelo de gestión de archivos similar al utilizado
en los SOBUNIX: cuando un proceso desea abrir o crear un archivo debe invocar a la función del sistema
3 DH pasándole como argumento el nombre de ruta del archivo. Si el archivo se abre o se crea con éxito
MS-DOS devuelve al proceso un manejador de archivo (file handle) de 16 bits, similar al descriptor de
archivo de los SOBUNIX. El proceso cuando invoca a una función del sistema para leer o escribir un
archivo debe pasarle como argumento su manej ador de archivo.
MS-DOS dentro del PSP de un proceso (ver Figura 7.5) mantiene una tabla de manejadores de
archivos (job handle table) 5 , similar a la tabla de descriptores de archivos de los SOBUNIX. Cada entrada
de tabla contiene la dirección de la tabla de archivo del sistema (System File Table, SFT), similar al
objeto de archivo abierto de los S OBUNIX. Una SFT es una estructura de datos que se crea en el espacio
del núcleo y que contiene toda la información que necesita conocer el sistema operativo para trabajar con
un archivo abierto, como por ejemplo: la unidad lógica donde se ubica, la dirección de su primer clusters
de datos. el tamaño del archivo, sus atributos, el modo de acceso, el puntero de lectura/escritura, etc.
MS-DOS enlaza todas las SFTs existentes en una estructura denominada tabla de archivos.
El modelo de gestión de archivos implementado en MS-DOS 2.0 para mantener la compatibilidad
con la versión anterior también soportaba el uso de FCBs. Para unificar el tratamiento de los archivos,
MS-DOS también asigna una SFT a un archivo abierto con un FCB .
Tabla de archivos
PSP de un proceso A
�
Manejador
de archivo
'l"'"�
''
'''
!
:
''
:
'''
:'
''
'
1------------------J
!
Tabla de manej adores
de archivos de un proceso A
SFT
0
+
SFT
�
SFT
•
Figura 7.5 -
Estructura de datos utilizadas en MS-DOS para gestionar los archivos
5 La traducción real al español de este término inglés sería tabla
para evitar confusiones.
tabla de manejadores de archivos
de manejadores de tareas
pero he preferido traducirla por
El sistema operativo MS-DOS
7.5.2.
289
Directorios
En su primera versión MS-DOS implementaba una estructura de directorios de un único nivel, es
decir, todos los archivos estaban contenidos en un único directorio. A partir de su versión 2.0 comenzó a
implementar una estructura de árbol de directorios, la cual posibilita la existencia de múltiples directorios
y subdirectorios. El directorio raíz se denota por el carácter \ que además se usa para separar los
componentes del nombre de ruta de un archivo.
Los bloques de datos de un directorio contienen una lista con los archivos y subdirectorios alojados
en el directorio. En dicha lista existen también dos entradas especiales : la entrada
que hace referencia
que hace referencia al directorio padre.
al propio directorio y la entrada
En cada entrada de la lista contenida en un directorio se almacena la siguiente información: el nombre
y la extensión del archivo, los atributos del archivo, el tamaño del archivo en bytes, la fecha y hora de la
última modificación, y la dirección del primer bloque de datos. El formato de una entrada de la lista de
un directorio viene impuesto por el sistema de archivos FAT.
Los atributos del archivo son una máscara de 8 bits que permiten especificar el tratamiento que
debe dar MS-DOS al archivo al que está asociada la entrada. Cada atributo tiene asignado un bit que
puede ser activado o desactivado mediante el uso del comando a t tr ib. Entre los atributos soportados
se encuentran los siguientes :
1
1,
1
11
•
•
•
1
11
•
Solo lectura. Si está activado (0000 000 1 ) significa que el archivo o subdirectorio al que está
asociada la entrada no puede ser modificado.
•
Oculto. Si está activado (0000 00 1 0) significa que la entrada no debe mostrarse en los listados del
directorio.
•
Sistema. Si está activado (0000 0 1 00) significa que la entrada está asociada a un archivo del siste­
ma, como por ejemplo i o . sys .
•
Etiqueta del volumen. Si está activado (0000 1 000) significa que la entrada no está asociada a
ningún archivo sino que contiene el nombre o etiqueta del volumen o unidad lógica.
•
Subdirectorio. Si está activado (000 1 0000) significa que la entrada está asociada a un subdirecto­
rio.
•
Archivo. Si está activado (00 1 0 0000) significa que la entrada está asociada a un archivo ordinario.
7 .5.3.
Sistemas de archivos
Cada sistema de archivos presente en memoria secundaria es tratado por MS-DOS como una unidad
o volumen lógico independiente, cada una de los cuales posee su propia estructura de directorios. MS­
DOS asigna una letra (C, D, E, . . . ) a cada unidad. El nombre de ruta de un archivo comienza por tanto
con el nombre del volumen lógico en el que está almacenado.
En sus primeras versiones MS-DOS soportaba únicamente sistemas de archivos FAT. Aunque poste­
riormente implementó la interfaz de sistemas de archivos instalables (lnstallable File System, IFS) que
290
Ampliación de sistemas operativos
le permitía soportar algunos otros sistemas de archivos, como por ejemplo, el sistema de archivos ISO
9660 de los CD-ROM.
La interfaz IFS traduce las operaciones independientes del sistema de archivos que invoca un proceso
a las funciones dependientes del sistema de archivos que las implementan. Las funciones dependientes
del sistema de archivos se implementan en un archivo ejecutable que debe ser cargado cuando se arranca
el computador. Por ejemplo, ms c dex . exe en el caso de los sistema de archivos ISO 9660 de los CD­
ROM.
7.6.
El sistema de archivos FAT
El sistema de archivos FAT, también conocido como sistema FAT- 12, fue creado por Bill Gates y
Marc McDonald en 1 977. El sistema FAT- 1 2 utiliza como unidad de asignación de espacio al cluster, el
cual está formado por varios sectores de disco contiguos. El tamaño de un cluster se fija en el momento
de la creación del sistema de archivos. Asimismo se utilizan 12 bits para direccionar un cluster, de ahí el
nombre de FAT- 12. En un sistema FAT- 1 2 el tamaño máximo de un volumen está limitado a 32 MiB .
Posteriormente a finales de los ochenta se desarrolló el sistema FAT- 1 6, el cual utilizaba 1 6 bits para
direccionar un cluster. Además soportaba un tamaño máximo de volumen de 2 GiB . El sistema FAT- 1 6
fue introducido como sistema d e archivos principal en l a versión 4 . 0 d e MS-DOS aparecida e n 1988.
La última versión aparecida de un sistema FAT, es el sistema FAT-32, el cual utiliza 32 bits para
direccionar a un cluster (realmente solo se utilizan 28 bits). Además soporta un tamaño máximo de
volumen de 4 GiB . El sistema FAT-32 fue introducido como sistema de archivos principal en la versión
OSR2 de Windows 95 aparecida en 1 996.
En las siguientes secciones se describe la estructura y gestión del sistema de archivos FAT- 12, que
fue el sistema de archivos principal de las primeras versiones de MS-DOS .
7.6.1.
Estructura de un sistema FAT
Un sistema de archivos FAT presenta la siguiente estructura en la partición de disco donde se crea
(ver Figura 7.6):
•
A rea de arranque. Se sitúa al principio de la partición. Contiene información sobre la partición de
disco sobre la que se ha creado el sistema de archivos, como por ejemplo: los bytes que ocupa un
sector, los sectores que hay en una pista, el número de sectores y los sectores que tiene un cluster.
El área de arranque también contiene información sobre la estructura del sistema de archivos:
número de tablas de asignación de archivos existentes (original y copias), los sectores que ocupa
una tabla de asignación de archivos y el número máximo de entradas del directorio raíz.
Además si se trata de la partición activa el área de arranque contiene el código necesario para
iniciar el arranque del sistema operativo.
•
Tabla de asignación de archivos. Cada entrada de esta tabla tiene un tamaño de 12 bits y contiene
información sobre el estado de un cluster del disco:
El sistema operativo MS-DOS
- ooo.
291
Indica que el cluster está libre.
- FF O - FF 6 . Indica que el cluster está reservado. Este es el caso de los clusters que se utilizan
para almacenar la lista de archivos y subdirectorios del directorio raíz.
- FF 7 . Indica que el cluster está defectuoso.
- F F 8 - FF F . Indican que se trata del último cluster de un archivo.
- Resto de valores. Indican que el cluster está asignado. En este caso el valor almacenado en
la entrada es la dirección física del siguiente cluster de datos del archivo. Recuérdese que
la entrada del directorio asociada a un archivo contiene la dirección del primer cluster del
archivo.
Señalar que las dos primeras entradas de la tabla están reservadas para codificar el tipo de disposi­
tivo donde se ha creado el sistema de archivos : disco duro o disquete.
•
Copias de la tabla de asignación de archivos. Puesto que la tabla de asignación de archivos es una
estructura crítica para el funcionamiento del sistema por motivos de seguridad se mantienen varias
copias de la misma en la partición del disco.
•
Directorio raíz. Contiene una lista de los subdirectorios y archivos existentes en dicho directorio.
Su tamaño máximo es fijo y queda establecido en el momento de la creación del sistema de archivos
en función del tamaño del disco.
•
Área de datos. Contiene los clusters de datos libres y los clusters de datos asignados a archivos y a
directorios.
Partición de disco
Á rea de datos
Figura 7.6 - Estructura
7.6.2.
de un sistema de archivos FAT
Implementación de directorios en un sistema FAT
En un sistema de archivos FAT la lista de archivos y subdirectorios de un directorio se implementa
con entradas de tamaño fijo igual a 32 bytes. En cada entrada se almacena la siguiente información (ver
Figura 7.7): nombre, extensión, atributos, hora y fecha de la última modificación, dirección del primer
cluster y tamaño.
En la lista contenida en un directorio, excepto si se trata del directorio raíz, existen dos entradas
especiales: la entrada que contiene la dirección del cluster del directorio y la entrada " . . " que contiene
la dirección del primer cluster del directorio padre. Si el directorio padre es el directorio raíz entonces
contiene la dirección O.
1 • 1
292
Ampliación de sistemas operativos
32 bytes
Nombre
Atributos
3 bytes
8 bytes
1 byte
Figura 7.7 - Estructura
7.6.3.
Tamaño
1 O bytes
2 bytes
2 bytes
2 bytes
4 bytes
de una entrada de un directorio en un sistema de archivos FAT
Localización de los clusters de datos de un archivo en un sistema FAT
En un sistema FAT la entrada asociada a un archivo en un directorio contiene, entre otros datos, la
dirección del primer cluster de datos del archivo. Para obtener la dirección del segundo cluster de datos
del archivo hay que acceder a la entrada de la tabla de asignación de archivos asociada al primer cluster,
la cual contiene la dirección del segundo cluster. Los restantes clusters del archivo se localizan de forma
semej ante ya que la entrada de la tabla de asignación de archivos asociada a un determinado cluster i de
datos de un archivo contiene la dirección de siguiente cluster i + l . En el caso de que el cluster i sea el
último del archivo entonces su entrada de la tabla de asignación de archivos contiene el valor - 1 (FFF en
hexadecimal).
e
Ejemplo 7 . 3
En la parte izquierda de la Figura 7 . 8 se ha representado la tabla de asignación de archivos de un cierto
sistema PAT. Recuérdese que la tabla tiene una entrada por cada cluster existente en la partición de disco.
Supóngase la dirección física del primer cluster (i = O) de un cierto archivo es Bp = 1 0 1 , esta información
se encuentra en la entrada del directorio que contiene al archivo. La entrada 1 0 1 de la tabla de asignación
de archivos contiene la dirección física Bp = 9 1 del segundo cluster (i = 1) del archivo. La entrada 9 1
de l a tabla de asignación de archivos contiene l a dirección física B p = 97 del tercer cluster ( i = 2 ) del
archivo. La entrada 97 de la tabla de asignación de archivos contiene la dirección física Bp = 93 del
cuarto cluster (i = 3) del archivo. Finalmente la entrada 93 de la tabla de asignación de archivos contiene
el valor - 1 que indica que este cluster es el último del archivo.
•
7.7.
Gestión de la E/S en MS-DOS
7.7. 1.
Subsistema de E/S
El subsistema de E/S de MS-DOS es muy simple debido a que se trata de un sistema operativo
monotarea. Cuando el proceso que se está ejecutando realiza una petición de E/ S ésta es inmediatamente
procesada. Hasta que no se atiende una petición el proceso no puede realizar otra.
MS-DOS no implementa ningún tipo de planificación de la E/ S ya que por su diseño no tenía nece­
sidad de ello. Si bien a partir de su versión 3 .0 empezó a implementar spooling en el uso de la impresora,
El sistema operativo MS-DOS
Tabla de asignación
de archivos
o
Clusters
o
1 1 1 1 1 1 1 1 1 1 1 1 1 1
B F- 90
1
1
1
1
2
3
) =
91
92
93
94
95
96
97
98
99 1 00 1 0 1 1 02
90
91
97
92
93
-1
94
95
96
97
93
98
99
1 00
101
91
1
1 02
1
1
1
1
Nombre archivo
1
_L
Dirección 1 cr cluster
1
Entrada asociada
al archivo en el
directorio al que
pertenece
..
1 2 bits
Figura 7.8 -
Localización del cluster de un archivo en un sistema FAT
293
294
Ampliación de sistemas operativos
el cual permitía mantener una cola de archivos a ser imprimidos.
MS-DOS también implementa la técnica de bu.ffering con el objetivo de mejorar el rendimiento de la
E/S, para ello mantiene en la memoria principal una caché de bu.ffers de bloques de disco. La caché suele
tener un tamaño de entre 30 y 40 buffers, con un tamaño de buffer de 532 bytes. Cada buffer contiene una
cabecera con información de control del buffer y los datos propiamente dichos, los cuales pueden ser de
tres tipos : datos de la tabla de asignación de archivos, datos de un directorio o datos de un archivo.
Todos los buffers existentes son organizados en una lista doblemente enlazada que es gestionada
mediante un algoritmo LRU. Cuando un buffer es utilizado es colocado al principio de la lista. De esta
forma al final de la lista están los buffers menos utilizados. Cuando hay que asignar un buffer siempre
se escoge al último de la lista. Si dicho buffer contiene un bloque de datos cuyo contenido ha sido
modificado entonces es escrito en el disco antes de reemplazar su contenido. Si el buffer contiene un
bloque de datos de la tabla de asignación de archivos que ha sido modificado entonces se actualizan
todas las copias de la tabla de asignación de archivos existentes en el disco.
7.7.2.
Drivers de dispositivos E/S
En MS-DOS se distinguen dos tipos de drivers de dispositivos de E/S : drivers residentes y drivers
instalables. Los drivers residentes se organizan en una capa de software denominada BIOS cuya parte
más primitiva es almacenada por el fabricante del computador en una memoria ROM. Durante el proceso
de arranque del sistema la BIOS es cargada en la memoria RAM j unto con el archivo i o . s y s , el cual
contiene rutinas de E/S que extienden la funcionalidad de la BIOS .
Los drivers residentes permiten al sistema operativo comunicarse con el hardware básico de la
computadora (disco de arranque, pantalla, teclado, puerto de impresión, reloj , etc). Para poder utilizar
otros dispositivos de E/ S distintos a los soportados en la B IOS , sus drivers deben ser instalados durante
el arranque del sistema. A estos drivers se les denomina drivers instalables, y son cargados en la memo­
ria principal en un área distinta de la B IOS . Señalar que un driver instalable también puede sustituir en
la memoria principal a un driver residente. De esta forma es posible utilizar versiones más actualizadas
de un determinado driver residente.
7.7.3.
Manejadores de interrupciones
MS-DOS implementa 256 manej adores de interrupción uno por cada una de las interrupciones dis­
ponibles en los procesadores de la familia Intel 80x86. Las 256 interrupciones disponibles se pueden
agrupar en tres categorías :
•
Interrupciones hardware externas. Son generadas por los controladores de E/S de los dispositivos
de E/S
•
Interrupciones hardware internas. También denominadas excepciones. Son generadas durante la
ejecución de un programa, debido a alguna condición de error, como por ejemplo, una división por
cero.
El sistema operativo MS-DOS
•
295
Interrupciones software. Son generadas por el sistema operativo y por los programas, para acceder
a las funciones del sistema y de la BIOS .
Esta arquitectura implementa interrupciones vectorizadas. La tabla de vectores de interrupción se
almacena en las direcciones más baj as de la memoria principal. Cada entrada de esta tabla está asociada
a una determinada interrupción y contiene la dirección de comienzo del manej ador de la interrupción
asociada a dicha interrupción. S eñalar que en MS-DOS algunos manej adores de interrupciones pueden
implementarse mediante procesos TSR.
78
.
.
Resumen
MS-DOS es un sistema operativo monousuario y monotarea escrito en lenguaj e ensamblador. Se
descompone en las siguientes capas lógicas : módulo BIOS , núcleo de MS-DOS e intérprete de comandos.
El módulo BIOS es la capa del sistema operativo encargada de comunicarse con el hardware. Contiene los
drivers residentes de los dispositivos de E/S (disco de arranque, pantalla, teclado, puerto de impresión,
reloj , etc) que son suministrados por defecto por el fabricante del computador. El núcleo de MS-DOS es
una capa independiente del hardware que se encarga de implementar los servicios ofunciones del sistema.
El intérprete de comandos implementa una interfaz de línea de comandos que permite al usuario invocar
los servicios del núcleo y ejecutar programas mediante la introducción de órdenes . Por defecto dicho
intérprete es el programa c ommand . c om.
MS-DOS es un sistema operativo monotarea, hasta que no termina de ejecutarse un proceso no
puede comenzar a ejecutarse otro. El proceso que se ejecuta tiene un control total de los recursos de la
máquina. Su ejecución solo puede ser interrumpida por el sistema operativo para realizar el tratamiento
de las interrupciones. Esta característica simplifica enormemente el control de los procesos y elimina la
necesidad de implementar un planificador de procesos.
En MS-DOS el control de procesos es muy simple, el proceso que se está ejecutando (proceso padre)
puede crear otro proceso (proceso hijo) invocando a la función del sistema 4 BH también conocida como
función EXEC. Esta función carga en memoria al proceso hijo y le transfiere el control. Mientras el pro­
ceso hijo se ejecuta el proceso padre permanece bloqueado en la memoria principal. Cuando el proceso
hijo va a terminar su ejecución invoca a una función del sistema para transferir el control de nuevo a su
proceso padre.
Las primeras versiones de MS-DOS trabaj an considerando la existencia de 1 MiB de memoria prin­
cipal, de los cuales solo 640 MiB podían ser utilizados por el sistema operativo y las programas. Cuando
MS-DOS tiene que asignar memoria principal a un programa utiliza el espacio del área de programas
transitorios. Este área de memoria es gestionada por el sistema operativo mediante la técnica de parti­
cionamiento dinámico.
A partir de su versión 2.0 MS-DOS implementó un modelo de gestión de archivos similar al utilizado
en los SOBUNIX: cuando un proceso desea abrir o crear un archivo debe invocar a la función del sistema
3 DH pasándole como argumento el nombre de ruta del archivo. Si el archivo se abre o se crea con éxito
MS-DOS devuelve al proceso un manejador de archivo de 1 6 bits, similar al descriptor de archivo de
296
Ampliación de sistemas operativos
los SOBUNIX. El proceso, cuando invoca a una función del sistema para leer o escribir un archivo, debe
pasarle como argumento su manej ador de archivo.
Cada sistema de archivos presente en memoria secundaria es tratado por MS-DOS como una unidad
o volumen lógico independiente, cada una de los cuales posee su propia estructura de directorios. MS­
DOS asigna una letra (C, D, E, . . . ) a cada unidad. El nombre de ruta de un archivo comienza por tanto
con el nombre del volumen lógico en el que está almacenado.
En sus primeras versiones MS-DOS soportaba únicamente sistemas de archivos PAT. Aunque poste­
riormente implementó la inteifaz IFS que le permitía soportar algunos otros sistemas de archivos, como
por ejemplo, el sistema de archivos ISO 9660 de los CD-ROM.
El sistema FAT utiliza como unidad de asignación de espacio al cluster, el cual está formado por
varios sectores de disco contiguos. Un sistema de archivos FAT presenta la siguiente estructura en la
partición de disco donde se crea: área de arranque, tabla de asignación de archivos, copias de la tabla de
asignación de archivos, directorio raíz y área de datos.
El subsistema de E/S de MS-DOS es muy simple debido a que se trata de un sistema operativo
monotarea. Cuando el proceso que se está ejecutando realiza una petición de E/ S ésta es inmediatamente
procesada. Hasta que no se atiende una petición el proceso no puede realizar otra.
7.9.
Lecturas recomendadas
Si se desea obtener una explicación adicional y ampliar los contenidos tratados en este capítulo se
pueden consultar, por ejemplo: [Duncan, 1 988b] , [Podanoffsky, 1 994] y el capítulo 14 de [McHoes y
Flynn, 20 1 0] .
7.10.
Autoevaluación
7 . 1 . Enumerar las características principales del sistema operativo MS-DOS . (Respuesta en sección 7 .2.2)
7 . 2 . Explicar la estructura del sistema operativo MS-DOS. (Respuesta en sección 7.2.3)
7 . 3 . Explicar cómo se implementan las llamadas al sistema en MS-DOS . (Respuesta en sección 7.2.4)
7 . 4 . Describir el proceso de arranque del sistema operativo MS-DOS . (Respuesta en sección 7.2.5)
7 . 5 . ¿Qué tipos de comandos soporta el intérprete c ommand . c om de MS-DOS ?
(Respuesta en sección 7.2.6)
7 . 6 . Enumerar y describir las partes en que se estructura el intérprete c ommand . c om.
(Respuesta en sección 7.2.6)
7 . 7 . Explicar el funcionamiento del intérprete c ommand . c om. (Respuesta en sección 7.2.6)
7 . 8 . Explicar la implementación y el control de procesos en MS-DOS . (Respuesta en sección 7 . 3 )
El sistema operativo MS-DOS
297
7 . 9 . Describir la creación y ejecución de procesos en MS-DOS . (Respuesta en sección 7 .3 . 1 )
7 . 10 . Describir l a terminación d e procesos en MS-DOS . (Respuesta en sección 7.3 .2)
7 . 1 1 . Dibujar un diagrama adecuadamente rotulado de la distribución de la memoria principal en MS­
DOS . Suponer que el tamaño de memoria es de 1 MiB . (Respuesta en sección 7.4)
7 . 12 . ¿Qué técnica utiliza MS-DOS para gestionar la memoria principal? Explicar su implementación.
(Respuesta en sección 7 .4)
7 . 13 . Explicar la implementación de la gestión de archivos utilizada en la primera versión de MS-DOS.
(Respuesta en sección 7 . 5 . 1 )
7 . 14 . Explicar la implementación de la gestión de archivos utilizada a partir de la versión 2.0 de MS­
DOS . (Respuesta en sección 7 .5 . 1 )
7 . 15 . Describir los posibles atributos de un archivo en MS-DOS . ¿Qué comando permite configurar los
atributos? (Respuesta en sección 7.5 .2)
7 . 16 . ¿Cuál es la utilidad de la interfaz IFS de MS-DOS ? (Respuesta en sección 7 . 5 . 3 )
7 . 17 . Describir la estructura de un sistema de archivos FAT. (Respuesta e n sección 7.6. 1 )
7 . 18 . Describir l a implementación de directorios en u n sistema de archivos FAT.
(Respuesta en sección 7 .6.2)
7 . 19 . Explicar cómo se localizan los clusters de datos de un archivo en un sistema FAT.
(Respuesta en sección 7 . 6 . 3 )
7 . 20 . Explicar cómo se implementa el buffering en MS-DOS . (Respuesta e n sección 7 . 7 . 1 )
7 . 21 . Describir los tipos de drivers que s e distinguen en MS-DOS . (Respuesta en sección 7.7 .2)
7.11.
Ejercicios
7 . 1 . Explique razonadamente cuál sería el resultado de la ejecución de las siguientes órdenes en el
intérprete de comandos c ommand . c om de MS-DOS o cmd . exe de Windows :
a ) d i r > l i s t ado . txt
b) dir
e) de l
f ind / I " l i s tado "
* .
txt
7 . 2 . Supóngase que en el directorio de trabajo actual existe el archivo tabl a . txt . ¿Qué orden se debe
escribir en el intérprete de comandos c ommand . c om de MS-DOS o cmd . exe de Windows para
conseguir que el archivo sea un archivo oculto de solo lectura?
298
Ampliación de sistemas operativos
7 . 3 En MS-DOS la cabecera de un bloque de memoria principal ocupa 5 bytes y tiene el siguiente
formato:
•
Byte O. Contiene el valor 9 O h del código ASCII si es el último bloque de la cadena de bloques
o el valor 7 7h en caso contrario.
•
B ytes 1 -2. De estos 16 bits el bit más significativo determina si el bloque está libre ( 1 ) u
ocupado (0). Los 1 5 bits restantes especifican el puntero al PSP del programa al que pertenece
el bloque.
•
B ytes 3-4. Contienen el número de parágrafos contenidos en el bloque.
Determinar toda la información posible que proporciona la siguiente cabecera de un bloque de
memoria: 7 7 0 0 0 0 0 0 0 3 h.
7 . 4 En un disco duro que utiliza un tamaño de sector de 5 1 2 bytes se desea crear un sistema de archivos
FAT- 1 2 con un tamaño de cluster de 1 6 sectores:
a) ¿Cuál sería el tamaño máximo del volumen?
b) ¿Qué tamaño tendría la tabla de asignación de archivos ?
7 . 5 Considérese u n sistema d e archivos FAT- 1 2 con u n tamaño d e cluster d e 2 KiB . Se pide:
a) Determinar el tamaño máximo de un archivo.
b) Determinar el número de entradas de directorio que caben en un cluster
e) Determinar la precisión de la hora de creación o modificación de un archivo almacenada en
una entrada de un directorio.
Capítulo 8
El s istema operativo Windows
Objetivos docentes
Los objetivos docentes de este capítulo son los siguientes :
•
Conocer el origen y la evolución del sistema operativo Windows.
•
Conocer las características principales y la estructura de Windows.
•
Conocer de forma general el funcionamiento y la implementación de la interfaz gráfica de usuario
proporcionada por Windows.
•
S aber cómo se implementan y atienden las llamadas al sistema en Windows.
•
Conocer las principales llamadas al sistema disponibles en Windows.
•
S aber cómo se implementa la seguridad y la protección de los datos de los usuarios en Windows.
•
Conocer la implementación, el control y la planificación de procesos multihilos en Windows.
•
Conocer los principales mecanismos de sincronización y de comunicación entre procesos disponi­
bles en Windows.
•
Saber cómo se realiza la administración de memoria en Windows.
•
Conocer cómo se realiza la gestión de archivos en Windows.
•
Conocer las características principales y la estructura de un sistema de archivos NTFS .
•
Saber cómo se realiza la gestión de la E/ S en Windows.
299
300
8. 1.
Ampliación de sistemas operativos
Introducción
Desde principios de los noventa hasta la actualidad Windows de Microsoft es el sistema operativo
preferido por la mayoría de los usuarios de computadores personales en todo el mundo. Sus detracto­
res cargan contra su carácter comercial, su código cerrado y sus problemas de estabilidad y seguridad.
Sin embargo, es indudable que su sencilla interfaz gráfica y el precio razonable de las máquinas que
traen instalado Windows han facilitado el acercamiento al mundo de los computadores personales de los
usuarios sin conocimientos previos de informática o programación.
Este capítulo está dedicado al estudio del sistema operativo Windows 1 • En primer lugar se realizan
una serie de consideraciones generales sobre Windows. En concreto se comenta su cronología histórica,
sus características principales, su estructura, la implementación de la API Win32, su interfaz con el
usuario, la implementación de las llamadas al sistema, el registro de Windows, su secuencia de arranque y
la seguridad en Windows. En segundo lugar se describe la implementación, el control y la planificación de
procesos multihilos en Windows. En tercer lugar se estudian los mecanismos de sincronización del núcleo
y los mecanismos de comunicación entre procesos. En cuarto lugar se estudia la gestión de memoria. En
quinto lugar se describe la gestión de archivos y el sistema de archivos NTFS , que es el sistema de
archivos principal utilizado en Windows. En sexto lugar se estudia la gestión de la E/S .
Señalar que obviamente, por motivos de espacio, este capítulo no es más que un pequeño resumen
de las características de Windows. Los lectores que deseen profundizar en su estudio pueden consultar
las referencias bibliográficas reseñadas en la sección 8. 1 O. También conviene tener presente que algunos
puntos del funcionamiento de este sistema operativo no se pueden explicar con el detalle deseado porque
Microsoft no los ha hecho públicos.
Finalmente comentar que algunos lectores echarán en falta en este capitulo la inclusión de programas
que ilustren el funcionamiento de las llamadas al sistema disponibles en Windows, tal y como se hizo al
describir los S OBUNIX en los capítulos anteriores. Esta decisión se fundamenta en el gran número de
parámetros de las funciones de la API Win32 a partir de las cuales se invocan a las llamadas al sistema
en Windows, lo que lleva a que los programas sean mucho más extensos y relativamente más difíciles de
comprender que los utilizados en los SOBUNIX.
8.2.
Consideraciones generales sobre Windows
8.2.1.
Cronología histórica
A mediados de los ochenta el sistema operativo más popular que disponía de una interfaz gráfica de
usuario basada en ventanas era el sistema Mac OS utilizado en los computadores personales Macintosh de
Apple. Influenciado por este sistema operativo Microsoft decidió dotar a su sistema operativo MS-DOS
de una GUI similar a la que bautizó con el nombre de Windows. La primera versión de Windows apareció
en el mercado en 1 985 y la segunda versión en 1 987. Estas dos primeras versiones no tuvieron mucho
1 En concreto las explicaciones de este capítulo toman como base a Windows Vista, que es el nombre comercial de Windows
NT 6.0.
El sistema operativo Windows
301
éxito. No fue hasta su versión 3 . 0 aparecida en 1 990 cuando Windows comenzó a hacerse realmente
popular.
La versión 3 . 1 de Windows aparecida en 1 992 fue la última versión de Windows que puede con­
siderarse como únicamente una GUI. Fue en 1 995 con la aparición de Windows 95, cuando Windows
adquirió la categoría de sistema operativo como tal, implementando gestión de procesos, multiprogra­
mación y gestión de la memoria virtual. Aunque si bien usaba MS-DOS para arrancar.
Uno de los principales problemas de Windows 95 era su inadecuado aislamiento entre los procesos
de usuario y el núcleo, lo que producía serios problemas de estabilidad. Las siguientes versiones de
Windows: Windows 98 aparecida en 1 998 y Windows Millennium (Windows Me) aparecida en 2000,
tampoco resolvieron el problema de la estabilidad. Además también usaban MS-DOS para arrancar.
A finales de los ochenta, en paralelo al desarrollo de Windows, Microsoft comenzó a desarrollar otro
sistema operativo nuevo basándose en los siguientes principios de diseño [Russinovich et al. , 2009] :
•
Extensibilidad. El código del sistema operativo debe poder ser modificado y extendido de forma
sencilla para poder adaptarse a las nuevas necesidades del mercado.
•
Portabilidad. El sistema operativo debe poder ser ejecutado en diferentes arquitecturas hardware.
•
Fiabilidad y robustez. Una aplicación de usuario no debe poder acceder al espacio de direcciones
del sistema operativo ni al de otras aplicaciones.
•
Compatibilidad. El sistema operativo debe de ser capaz de soportar las aplicaciones que se desarro­
llen para otros sistemas operativos como MS-DOS , OS/2 o aquellas que sigan las especificaciones
POS IX.
La primera versión de este nuevo sistema operativo apareció en 1 993 y se denominó Windows NT
2
3 . 1 . Señalar que Microsoft usó para la primera versión de NT el mismo número de versión que el de la
versión de Windows existente por aquella fecha.
Inicialmente Windows NT no tuvo mucho éxito pero a partir de su versión 4.0 aparecida en 1 996 que
incluía una GUI similar a la de Windows 95 comenzó a ganar cuota de mercado como sistema operativo
de servidores y estaciones de trabajo.
El éxito tanto técnico como comercial de la versión 5 . 0 de Windows NT aparecida en el mercado
en el 2000 bajo el nombre de Windows 2000 hizo que Microsoft dej ara de utilizar MS-DOS como base
de su sistema operativo Windows . A partir de entonces todos los sistemas operativos de Microsoft están
basados en alguna versión de Windows NT.
Con respecto a las versiones cliente de Windows, es decir, aquellas destinadas a computadores perso­
nales, en 200 1 Microsoft sacó al mercado Windows NT 5 . 1 con el nombre de Windows XP. Este sistema
es uno de los sistemas operativos de Microsoft que más tiempo ha perdurado. No sería hasta 2007 cuan­
do Microsoft sacó una nueva versión: Windows Vista, que era el nombre comercial de Windows NT 6.0
(Build 6000). Este sistema operativo recibió bastantes críticas ya que presentaba bastantes problemas.
2NT es el acrónimo del término inglés New Technology (nueva tecnología).
302
Ampliación de sistemas operativos
En cuanto a las versiones servidor de Windows, es decir, aquellas destinadas a servidores y estaciones
de trabajo, en 2003 Microsoft sacó al mercado Windows NT 5 . 2 con el nombre de Windows Server 2003 .
Cinco años más tarde, en 2008, lanzó Windows Server 2008 que era el nombre comercial de Windows
NT 6.0 (Build 600 1 ) .
E n e l momento d e escribir estas líneas las últimas versiones aparecidas de Windows son Windows 7
y Windows Server 2008 R2, aparecidas en 2009, que son los nombres comerciales de la versión cliente
y de la versión servidor, respectivamente, de Windows NT 6. 1 .
8.2.2.
Características principales de Windows
Las características principales del sistema operativo Windows son:
•
Es un sistema operativo multiprogramado y multitarea, con soporte para multiprocesamiento.
•
El núcleo está escrito en su mayor parte en lenguaj e C.
•
El núcleo posee una estructura de tipo monolítica o simple.
•
La planificación se realiza a nivel de hilos del núcleo usando un algoritmo de planificación basada
en múltiples colas de planificación y realimentación.
•
Dispone de mecanismos de sincronización y comunicación entre procesos o hilos: semáforos,
eventos, tuberías, conectores, objetos compartidos, mailslots, etc.
•
No suelen utilizar ninguna estrategia de tratamiento de interbloqueos. Dichas estrategias si se
quieren implementar deben hacerse a nivel de los programas de aplicación.
•
Administra la memoria principal e implementa la memoria virtual usando la técnica de demanda
de página.
•
Considera a los archivos como una secuencia de bits y delegan en las aplicaciones la interpretación
de los mismos.
•
Soporta tanto el acceso secuencial como el acceso aleatorio a los archivos.
•
En los nombres de archivos no distingue entre minúsculas y mayúsculas.
•
Cada sistema de archivos presente en memoria secundaria es tratado como una unidad o volumen
lógico independiente, cada una de los cuales posee su propia estructura de directorios. Windows
asigna una letra (C, D, E, . . . ) a cada unidad.
•
Dentro de cada volumen soporta una estructura de directorios de gráfica acíclica. El directorio raíz
de un volumen se denota por el carácter \ , que además se usa para separar los componentes
del nombre de ruta de un archivo. Para acceder al sistema de archivos de otra unidad se debe
especificar al comienzo de la ruta la letra de la unidad seguido de dos puntos, por ejemplo: e : \ .
'
•
'
La interfaz con el usuario es del tipo interfaz de usuario gráfica (GUI).
El sistema operativo Windows
8.2.3.
303
Estructura del sistema operativo Windows
El sistema operativo Windows consta de diversos componentes software (ver Figura 8. 1 ), unos se
ejecutan en modo usuario y otros en modo núcleo. Los componentes de Windows que se ejecutan en
modo usuario son los siguientes :
•
Procesos del sistema. Son procesos creados por el sistema operativo que se encargan de realizar
tareas que dependen del usuario interactivo que haya iniciado una sesión de trabajo en el sistema.
Ejemplos de procesos del sistema son el gestor de sesión de usuario (sms s . exe) y el proceso de
inicio de sesión (wi n l o gon . exe).
•
Procesos de servicios. También denominados servicios. Son procesos creados por el sistema ope­
rativo que se encargan de realizar diferentes tareas administrativas en modo usuario independien­
temente del usuario interactivo que haya iniciado una sesión de trabajo en el sistema. Los procesos
de servicios de Windows son similares a los procesos demonio de los SOBUNIX. Todos los proce­
sos de servicios existentes son controlados por el gestor de control de servicios ( s ervi c e s . exe)
que se encarga de iniciar, parar e interactuar con los procesos de servicio. Un ejemplo de proceso
de servicio de Windows es el spooler de impresión.
•
Aplicaciones. Son procesos asociados a archivo ejecutables de algunos de los siguientes tipos:
Windows 32 o 64 bits, Windows 3 . 1 1 6 bits, MS-DOS 16 bit o POSIX 32 bits. Algunas aplicacio­
nes son iniciadas por el propio sistema operativo cuando un usuario inicia una sesión en el sistema.
Este es el caso por ejemplo del explorador de Windows (exp l orer . exe) que implementa el escri­
torio de Windows. Otras aplicaciones, como navegadores web, gestores de correos y procesadores
Procesos
del
sistema
1
Procesos
de
servicios
Aplicaciones
1
1
Subsistemas
de
entorno
1
Modo usuario
Librerías de enlace dinámico (DLLs)
Interfaz de llamadas al sistema (ntdl l . dl l )
-----------------------------------�------------------------------
Núcleo de --Windows N T
�
Drivers
dispositivos
1
Ej ecutivo
Kernel
1
Implementación
de la GUI
Capa de abstracción del hardware (HAL)
Hardware
Figura 8.1
1
- Estructura del sistema operativo Windows
Modo núcleo
304
Ampliación de sistemas operativos
de texto, son invocadas por el propio usuario interactuando con los iconos o los menús de la GUI
de Windows.
•
Librerías de enlace dinámico. Una librería de enlace dinámico o librería DLL (Dynamic Link
Library) es un conjunto de rutinas enlazadas juntas en un archivo binario que puede ser cargado en
tiempo de ejecución dentro del espacio de direcciones de los procesos que invocan a dichas rutinas.
Las librerías DLL permiten ahorrar espacio en memoria ya que solo es necesario cargar una única
copia del código de la librería en la memoria principal. Todos los procesos que tienen enlazada la
misma librería DLL en su espacio de direcciones comparten el mismo código de la librería. Luego
las librerías DLL son el mecanismo utilizado en Windows para implementar librerías compartidas.
Una de las librerías DLL más importante es ntdl l . dl l ya que es usada por las restantes librerías
DLL. La librería ntdl l . dl l contiene todas las funciones de envoltura de las llamadas al sistema
de Windows (ver sección 8.2.6). También contiene otras funciones de apoyo, como por ejemplo:
funciones para comunicarse con el subsistema de entorno de Windows, funciones para gestionar
el montículo, etc.
Las librerías DLL no solo se ejecutan en modo usuario, algunas DLLs también pueden ser utiliza­
das en modo núcleo por el propio sistema operativo.
•
Subsistemas de entorno. En sus orígenes Windows NT soportaba tres interfaces de programación
de aplicaciones o APis : la API de Windows (API Win323 ), la API POSIX, y la API OS/2. A partir
de Windows XP la API OS/2 dejó de soportarse. Por otra parte, la API POSIX ha sido extendida
y mejorada desde Windows Vista.
El sistema operativo para implementar la funcionalidad de cada API utiliza un proceso de usuario
denominado subsistema de entorno y un conjunto de librerías DLL. El subsistema de entorno
Windows siempre se ejecuta ya que se utiliza, como se verá en la sección 8.2.5, para implementar
la GUI de Windows. Por su parte el subsistema de entorno POSIX, conocido desde Windows Vista
como subsistema para aplicaciones basadas en UNIX (Subsystem for Unix-based Applications,
SUA), solo se ejecuta si se ejecuta una aplicación que utiliza la API POSIX.
Por otra parte los componentes de Windows que se ejecutan en modo núcleo son los siguientes:
•
Capa de abstracción del hardware (Hardware Abstraction Layer, HAL). Esta capa oculta los de­
talles del hardware al resto de componentes del sistema operativo lo que facilita la portabilidad
del sistema operativo a diferentes plataformas. La capa HAL se implementa en la forma de una li­
brería DLL (ha l . dl l ) . Cada plataforma tiene asociado su librería DLL correspondiente. Cuando
un componente del sistema operativo necesita realizar una operación sobre el hardware invoca a
una función de la capa HAL la cual se encarga de traducirla a la función adecuada dependiente del
hardware.
3 Aunque denominada como API Win32 esta interfaz es válida tanto para las versiones de Windows de 32 bits como para las
versiones de 64 bits.
El sistema operativo Windows
305
•
Drivers de dispositivos. En Windows los drivers de dispositivos se implementan como módulos
que pueden ser cargados dinámicamente y que se ejecutan en modo núcleo en el contexto de un
hilo asociado a un proceso de usuario que ha iniciado una operación de E/S, en el contexto de un
hilo del sistema, o como resultado de una interrupción. Generalmente el código de un driver se en­
cuentra en un archivo con extensión . sys . A diferencia de otros sistemas operativos la mayoría de
los drivers en Windows no interaccionan directamente con el hardware sino que utilizan funciones
de la capa HAL.
•
Implementación de la GUI. La GUI de Windows (ver sección 8.2.5) es un componente tan utilizado
que para mejorar el rendimiento del sistema se ejecuta en modo núcleo.
•
Núcleo de Windows NT. Se implementa en el archivo ejecutable n t o skrnl . exe y se descompone
en dos capas :
- Ejecutivo (executive). Es la capa superior del núcleo de Windows NT. Atiende las llamadas al
sistema e implementa los servicios4 del sistema operativo: administrador de memoria, admi­
nistrador de la caché5 , administrador de E/ S , administrador de PnP (Plug-and-Play, conectar
y usar), monitor de seguridad, administrador de procesos, administrador de objetos, admi­
nistrador de configuración. El ejecutivo también se encarga de implementar las llamadas a
procedimientos locales avanzados (Advanced Local Procedure Calls, ALPCs) (ver sección
8.4.3).
- Núcleo (kernel). Es la capa inferior del núcleo de Windows NT. Se encarga del encamina­
miento de las interrupciones, excepciones y trampas, También se ocupa de la planificación y
sincronización de hilos. Además contiene las rutinas para la manipulación de objetos.
8.2.4.
Implementación de la API Win32
La API Wln32 es la interfaz de programación de aplicaciones más utilizada por las aplicaciones
de Windows. Para implementar su funcionalidad Windows utiliza el subsistema de entorno Windows
{c s r s s . exe) y centenares de librerías DLL, ubicadas en su mayoría en e : \wi ndows \ sys t em3 2 . Entre
las librerías DLL más importantes que implementan la funcionalidad de la API Win 32 se encuentran las
siguientes :
•
kerne l 3 2 . dl l . Contiene funciones que permiten acceder a la mayoría de llamadas al sistema
básicas excepto las que implementan la GUI.
•
gdi 3 2 . dl l . Contiene funciones que permiten acceder a llamadas al sistema asociadas con la GUI
para el manejo de elementos tales como fuentes, textos, colores, mapas de bits, etc.
4 Aquí la palabra servicio se refiere a las tareas que realiza el núcleo. No debe confundirse con Jos servicios de Windows que
son procesos que se ejecutan en modo usuario.
5Se trata de la caché software, denominada caché del sistema, que implementa Windows para almacenar las regiones de los
archivos usadas más recientemente.
306
Ampliación de sistemas operativos
•
u s e r 3 2 . dl l . También contiene funciones que permiten acceder a llamadas al sistema asociadas
con la GUI para el manejo de elementos como ventanas, iconos, menús, cursor, etc.
•
advap i 3 2 . dl l . Contiene funciones que permiten acceder a llamadas al sistema asociadas a tareas
de administración, registro y seguridad, entre otras.
Cuando se invoca a una función de una librería DLL pueden producirse las siguientes acciones :
•
La función realiza una cierta tarea y retorna sin necesidad de invocar ninguna llamada al sistema.
•
La función invoca a una función de la librería n tdl l . dl l para invocar a una llamada al sistema.
La librería ntdl l . dl l contiene las funciones de envoltura de las llamadas al sistema de Windows.
•
La función envía un mensaj e al subsistema de entorno al que pertenece, el cual realiza ciertas
tareas. En algunos casos el subsistema es capaz de realizar todo el trabajo en modo usuario sin ne­
cesidad de realizar una llamada al sistema. En otros debe realizar una llamada al sistema invocando
a una función de la librería n tdl l . dl l .
Finalmente comentar que las funciones de la API Win32 se caracterizan por tener nombres largos
que suelen resumir bastante bien la tarea que implementan. Por ejemplo, la función CreateProc e s s
permite crear u n proceso.
También las funciones de la API Win32 se caracterizan por tener bastantes argumentos de entrada.
Ello las dota de una mayor flexibilidad pero también complica su uso a los programadores.
8.2.5.
Interfaz con el usuario de Windows
Windows desde su concepción se caracteriza por proporcionar al usuario una interfaz gráfica. Si bien
también es posible trabajar con una interfaz de línea de comandos usando el intérprete de comandos
cmd . exe, una versión mej orada del c ommand . c om de MS-DOS .
En sus orígenes la GUI de Windows se ejecutaba en modo usuario como parte del subsistema de
Windows, pero ello afectaba bastante al rendimiento del sistema debido a los constantes cambios de
hilos y de procesos que había que realizar. A partir de Windows NT 4.0 la mayor parte de la GUI se
implementa como un conjunto de rutinas ejecutables en modo núcleo dentro del driver win3 2 k . sys .
Estas rutinas pueden ser invocadas mediante funciones de las librerías DLL que implementan la API
Win32, como por ejemplo: u s e r 3 2 . dl l y gdi 3 2 . dl l .
El driver win3 2 k . sys implementa los siguientes componentes de la GUI de Windows :
•
Sistema de ventanas. Se encarga d e controlar como s e muestran las ventanas e n l a pantalla. Además
gestiona la entrada de datos a través del teclado y el ratón, u otros dispositivos de interfaz humana,
y envía mensajes a las aplicaciones que esperan dichas entradas. También gestiona la salida en
pantalla de acuerdo con los mandatos de las aplicaciones.
•
Inteifaz de dispositivos gráficos (Graphics Device Interface, GDI). Es una librería de funciones
para creación y manipulación de gráficos (líneas, textos, figuras, etc) en dispositivos gráficos.
El sistema operativo Windows
•
307
Funciones de envoltura a DirectX. DirectX es una API que proporciona funciones para aplicacio­
nes multimedia (juegos, reproducción de video, etc). Esta API se implementa a través del driver
dxgkrn l . sys
Para interactuar con los dispositivos gráficos las rutinas del driver win3 2 k . sys utilizan a su vez
diferentes drivers, algunos de los cuales para mej orar el rendimiento interaccionan directamente con el
hardware sin necesidad de invocar funciones de la capa HAL.
8.2.6.
Llamadas al sistema en Windows
En Windows a las llamadas al sistema se les denomina servicios del sistema, para evitar confusiones
con los procesos de servicio a los que también se les denomina servicios, en todo el capítulo se utiliza el
término llamada al sistema en lugar de servicio del sistema.
Las funciones de envoltura de las llamadas al sistema de Windows se encuentran en la librería
n tdl l . dl l . Microsoft ha publicado muy poca información sobre las funciones de esta librería, por
lo que es difícil trabaj ar con ellas directamente. El acceso a las funciones de la librería ntdl l . dl l , es
decir, la invocación de llamadas al sistema, se realiza de forma indirecta a través de las funciones de las
librerías DLL que implementan las APis soportadas por Windows, las cuales están bien documentadas 6 .
En la Tabla 8. 1 se muestran algunos ejemplos de funciones de la librería kerne l 3 2 . dl l de la API
Win32 y se especifican las funciones de la librería ntdl l . dl l que son invocadas durante su ejecución.
Función de kerne l 3 2 . dl l
Función d e ntd l l . dl l
CreateF i l e
ReadF i l e
Wr i t eF i l e
C l o s eHandl e
Creat e Pro c e s s
Creat eThread
NTCreateF i l e
NTReadF i l e
NTWr i te Fi l e
NTC l o s e
NTCreateUs erPro c e s s
NTCreat eThread
Tabla 8.1
-
Tarea que realiza
Crear o abrir u n archivo y a existente
Leer archivo
Escribir archivo
Cerrar e l descriptor de u n objeto abierto
Crear u n proceso
Crear un hilo
Algunos ejemplos de funciones de la API Win32 y de sus funciones asociadas en la librería
n t dl l . dl l
El programador de aplicaciones únicamente debe conocer cuál es la función F l de l a API que necesita
invocar para realizar una cierta tarea. Si la realización de dicha tarea requiere invocar a una llamada
al sistema entonces la función Fl invocará a la función F2 apropiada de la librería ntdl l . dl l . La
función Fl antes de invocar a la función F2 quizás tenga que realizar algún procesamiento sobre los
argumentos que va a pasar a F2. Por ejemplo, si hay algún argumento de tipo carácter o cadena de
caracteres codificados en ANSI la función F2 deberá pasarlos a codificación Unicode, que es el estándar
de codificación utilizado por las llamadas al sistema de Windows.
La función de envoltura F2 de la librería n tdl l . dl l es la que se encarga de pasarle al sistema
operativo toda la información que necesita conocer para tratar la llamada al sistema: el identificador de
6www.msdn.microsoft.com
308
Ampliación de sistemas operativos
la llamada, que es un número entero positivo que la identifica de forma univoca, y los argumentos de la
llamada. Cuando ya tiene lista esta información invoca una instrucción hardware especial denominada
trampa que transfiere el control al sistema operativo.
Cuando tiene lugar una trampa asociada a una llamada al sistema se produce una conmutación de
modo usuario a modo núcleo y se guarda el contexto hardware del hilo en ejecución. A continuación se
invoca a una rutina general de tratamiento de llamadas al sistema denominada despachador de llamadas
al sistema que guarda los argumentos de la llamada al sistema en la pila del núcleo asociada al hilo en
ejecución y obtiene de un registro de la máquina el identificador de la llamada al sistema.
El despachador utiliza el identificador de la llamada para buscar en la tabla de despacho de llamadas
al sistema la dirección de inicio de la rutina de tratamiento especifica de la llamada al sistema que ha
sido invocada. Esta tabla contiene una entrada por cada llamada al sistema soportada. Cada entrada
contiene la dirección de inicio de la rutina de tratamiento asociada a dicha llamada. Una vez localizada.
el manej ador invoca a la rutina específica de tratamiento de la llamada. Dicha rutina se implementa en el
ejecutivo del núcleo (nt o s krnl . exe ) si se trata de una llamada no asociada con la GUI, o en el driver
que implementa la GUI en modo núcleo (win3 2 k . sys ) si se trata de una llamada asociada con la GUI.
Cuando finaliza la rutina de tratamiento de la rutina se devuelve el control al despachador que restaura
el contexto hardware del hilo y le transfiere el control para que continúe su ejecución en modo usuario
en el punto de retomo de la llamada al sistema.
8.2. 7.
El registro de Windows
El registro de Windows (registry) es una base de datos que recopila toda la información fundamental
relativa al hardware, al software y a los usuarios necesaria para arrancar y configurar el sistema de
acuerdo con el usuario que ha iniciado una sesión. La mayor parte del registro se almacena en el sistema
de archivos de la partición de arranque de Windows en el directorio e : \ windows \ sys t ern3 2 \ c o n f i g
en diferentes archivos denominados subárboles (hives).
El registro de Windows se implementa mediante dos tipos de elementos: las llaves y los valores. Una
llave es similar a un directorio. Mientras que un valor es similar a un archivo. Cada llave tiene asignado
un nombre y puede contener valores y otras llaves. Señalar que a una llave contenida dentro de otra llave
también se le denomina subllave. Luego una subllave es similar a un subdirectorio.
Por su parte cada valor tiene asignado un nombre, un tipo de datos y los datos propiamente dichos.
El nombre de un valor es una cadena de caracteres codificados en código Unicode. El tipo de un valor
especifica el tipo de datos que contiene el valor. Existen definidos hasta catorce tipos distintos de valo­
res, entre ellos: REG_s z cadena de caracteres codificados en Unicode, REG_B INARY número binario de
longitud arbitraria, REG_L INK enlace simbólico en Unicode y REG_DWORD entero de 32 bits.
En el nivel raíz del registro existen creadas, por defecto, seis claves raíz:
•
HKEY_USERS . Contiene los perfiles de todos los usuarios. Existe una clave por cada perfil de
usuario definido Windows. El perfil contiene las preferencias del usuario relativas al escritorio,
teclado, sonidos, software, etc.
El sistema operativo Windows
•
309
HKEY_CURRENT_USER. Enlace simbólico a la parte del registro donde se encuentran las preferen­
cias del usuario actual.
•
HKEY_CLAS SES_ROOT. Enlace simbólico a la parte del registro que mantiene la información sobre
las aplicaciones que hay que invocar en función de las extensiones de los archivos . Por ejemplo,
cuando se hace doble clic sobre un archivo con extensión . pdf el programa que gestiona la entrada
del ratón lee esta clave del registro para determinar que aplicación debe iniciar, normalmente
Adobe Reader.
•
HKEY_LOCAL_MACHINE. Contiene información sobre el hardware y el sistema operativo. Esta
información se distribuye en cinco subclaves :
- HARDWARE . Describe el hardware de la máquina especificando que controlador debe utilizarse
para cada dispositivo. Señalar que esta información no se almacena en el disco sino que es
recopilada cuando se arranca el sistema por un componente del ejecutivo, el administrador
de PnP.
SAM (Security Account Manager, administrador de cuentas de seguridad) . Contiene informa­
ción sobre las cuentas de los usuarios, como por ejemplo, sus nombres de usuario y contra­
señas.
SECURITY. Contienen información sobre la implementación de la política de seguridad: nú­
mero de veces que un usuario ha introducido una contraseña no válida, la longitud mínima
que debe tener una contraseña para considerarse como válida, etc.
SOFTWARE. Contiene información almacenada por las aplicaciones. Por ejemplo, si se tiene
instalado el navegador Firefox entonces existirá creada una subclave de nombre Mo z i l l a
donde la aplicación puede guardar toda la información que considere necesaria, por ejemplo,
su número de versión o información para desinstalar la aplicación.
SYSTEM. Contiene información necesaria para arrancar el sistema, como por ejemplo, un
listado con los drivers que hay instalar y un listado con los procesos de servicios que hay que
iniciar.
•
HKEY_CURRENT_CONF I G . Enlace simbólico a la parte del registro donde se encuentra la configu­
ración actual del hardware.
•
HKEY_PERFORMANCE_DATA. Permite acceder al estado del hardware y a los contadores que man­
tiene el sistema operativo. Esta información resulta de gran utilidad para monitorizar el rendimien­
to del sistema.
El registro de Windows puede ser accedido y manipulado por el sistema operativo, por las aplicacio­
nes y por los usuarios. Estos últimos pueden acceder al registro haciendo uso de alguno de los programas
distribuidos por Microsoft como por ejemplo: el editor del registro (regedi t . exe) 7 y el monitor de
7Conviene señalar que este programa no muestra la clave HKEY_PERFORMANCE_DATA.
310
Ampliación de sistemas operativos
procesos (pro cmon . exe ) . Es importante señalar que la manipulación del registro debe ser realizada por
usuarios y administradores expertos. Una manipulación inapropiada del registro puede provocar que el
sistema no sea capaz de arrancar y haya que instalar de nuevo todo el sistema operativo.
Por otra parte, existen varias funciones en la API Win32 que permiten a las aplicaciones acceder
y manipular el registro. Por ejemplo, la función RegQueryVa l u e Ex busca los datos de un valor den­
tro de una clave, la función RegCrea t eKeyEx crea una nueva clave dentro del registro, y la función
RegDe l e t eKey borra una clave del registro.
8.2.8.
Arranque de Windows
El arranque de Windows se implementa mediante el programa boo tmgr . exe ubicado en el direc­
torio raíz de la partición de arranque. Este programa en primer lugar comprueba el estado en que se en­
cuentra el sistema operativo. Si estaba en el estado suspendido o el estado hibernado entonces invoca al
programa winresume . exe para reanudar la ejecución del sistema. Si el sistema estaba en el estado apa­
gado entonces inicia la carga del sistema operativo mediante la invocación del programa win l o ad . exe.
winl oad . exe se encarga de cargar en la memoria principal los componentes del sistema operativo
que se ejecutan en modo núcleo: el ejecutivo y el núcleo ubicados en ntoskrnl . exe , la capa HAL
ubicada en la librería hal . dl l , el driver win3 2 k . sys que implementa la GUI, y todos los drivers ne­
cesarios de acuerdo con la información especificada en la clave SYSTEM del registro de Windows. A
continuación transfiere el control a una rutina de bajo nivel del núcleo que se encarga de inicializar todos
los componentes del sistema operativo que se ejecutan en modo núcleo. Además crea el primer proce­
so en modo usuario: el gestor de sesión de usuario ( sms s . exe ) . Este proceso se encarga de iniciar el
subsistema de entorno de Windows ( c s r s s . exe ) , cargar diferentes librerías DLL, realizar las operacio­
nes de configuración establecidas en los subárboles del registro, e iniciar al proceso de inicio de sesión
(winl ogon . exe ) .
El proceso winl ogon . exe se encarga de crear al administrador de validación ( l s a s s . exe ) y el
gestor de servicios ( s ervi c e s . exe ) . Además se encarga de realizar todas las tareas necesarias para
iniciar la sesión del usuario. El proceso l s a s s . exe se encarga de la autentificación del usuario. Si el
nombre de usuario y la contraseña introducidas coinciden con algunos de los perfiles definidos en el
registro entonces se inicia el proceso exp l orer . exe que implementa el escritorio de Windows . Por su
parte el proceso s e rvi c e s . exe se encarga de crear y controlar a los procesos de servicios de Windows.
Este proceso para saber cuáles son los servicios que debe iniciar consulta el registro.
8.2.9.
Objetos del núcleo
Un objeto del núcleo es una estructura de datos mantenida en el espacio de direcciones del núcleo de
Windows NT asociada a una determinada abstracción y gestionada por el administrador de objetos del
ejecutivo. La abstracción a la que está asociado un objeto define el tipo del objeto. Por ejemplo, el núcleo
asocia a un archivo abierto un objeto archivo, a un proceso un objeto proceso, a un hilo un obj eto hilo, a
un semáforo un objeto semáforo, a una clave del registro un objeto clave, a un driver instalado un objeto
driver, etc.
El sistema operativo Windows
311
Conviene señalar que Windows está escrito en su mayor parte en el lenguaj e de programación C,
por lo que estos objetos no deben confundirse con los obj etos utilizados en lenguaj es de programación
orientados a objetos como C + + . Los objetos implementados en Windows mediante C soportan ocultación
de datos y abstracción, pero no polimorfismo ni herencia.
Cada objeto tiene asignado un nombre codificado en Unicode, el ejecutivo mantiene un espacio de
nombres en memoria con una organización similar a una estructura de directorios de gráfica acíclica.
Windows utiliza el nombre de un objeto para localizar el objeto.
Un objeto implementado en Windows consta de dos partes : la cabecera y los datos específicos del
objeto. La cabecera contiene la información necesaria para gestionar el obj eto, como por ejemplo: su
nombre y directorio en el espacio de nombres, su descriptor de seguridad (ver sección 8.2. 1 0) y un
puntero a la estructura que implementa el tipo de obj eto. Esta información es común a todos los objetos
e independiente de su tipo.
Cada tipo de objeto definido se implementa mediante una estructura que contiene información de­
pendiente del tipo de objeto, como por ejemplo: derechos de acceso, recursos de memoria que puede
consumir y punteros a las funciones que se pueden invocar para operar (abrir, cerrar, borrar, etc) sobre
este tipo de objeto.
El administrador de objetos es el componente del ejecutivo encargado de gestionar (crear, configurar,
borrar, etc) todos los objetos del núcleo. Además proporciona una interfaz a los restantes componentes
del ejecutivo para crear y operar con los objetos.
Diferentes llamadas al sistema requieren de la creación de nuevos obj etos del núcleo o del acceso
a objetos ya existentes. Cuando un proceso invoca a una llamada al sistema que requiere de la apertura
o de la creación de un objeto del núcleo, el sistema devuelve al proceso como parámetro de retorno de
la llamada un descriptor del objeto (handle). Dicho descriptor debe ser utilizado como argumento de
entrada en las posteriores llamadas al sistema que realice dicho proceso que involucren a dicho objeto.
El sistema mantiene una tabla de descriptores (handle table) local a cada proceso. De esta forma un
mismo descriptor puede hacer referencia en dos procesos distintos a objetos distintos.
8.2.10.
Seguridad en Windows
Mecanismos de seguridad
Windows NT dispone de los siguientes mecanismos de seguridad [Tanenbaum, 2009] :
•
Inicio de sesión seguro. En Windows NT un usuario para que le aparezca la pantalla de inicio
de sesión en la que introducir su nombre usuario y su contraseña debe pulsar la combinación de
teclas [ c ontro l ] + [ a l t ] + [ supr l . El manej ador de interrupciones del teclado al detectar esta
combinación de teclas inicia al autentico programa de inicio de sesión. Los procesos de usuario no
disponen de ningún mecanismo para poder cambiar el programa al que redirecciona esta combina­
ción de teclas. Con ello se pretende evitar que un software malicioso pueda simular la ventana de
inicio de sesión para capturar la contraseña. Señalar que en algunos casos Windows NT desactiva
este mecanismo, de hecho en las versiones cliente de Windows está desactivado por defecto.
312
Ampliación de sistemas operativos
•
Control de acceso discrecional. Los propietarios de un objeto pueden especificar que otros usuarios
pueden utilizar dicho obj eto y que operaciones pueden realizar.
•
Control de acceso privilegiado. El administrador del sistema es el único que dispone de los permi­
sos necesarios para modificar los permisos establecidos por un usuario.
•
Protección del espacio de direcciones de un proceso. Cada proceso dispone de un espacio de
direcciones virtuales independiente que no puede ser accedido por otros procesos.
•
Borrado explicito de los marcos de página asignados a un proceso. Los marcos de memoria prin­
cipal asignados a las páginas de la región de pila o al montículo de un proceso se deben rellenar
inicialmente con páginas inicializadas con ceros para evitar que el proceso pueda leer la informa­
ción de las páginas contenidas en los marcos que le acaban de ser asignados.
•
Auditoría de seguridad. El administrador del sistema dispone de mecanismos para poder crear un
registro de eventos asociados con la seguridad del sistema.
Estructuras de datos utilizadas para implementar la seguridad
La implementación de la seguridad en Windows se basa principalmente en el uso de las siguientes
estructuras de datos:
•
Ficha de acceso (access token). Cuando un usuario se autentifica Windows asigna al primer pro­
ceso creado para el usuario, el proceso exp l orer . exe que implementa el escritorio, una ficha de
acceso que es heredada por todos los procesos que cree dicho proceso inicial debido a la interac­
ción del usuario con el escritorio.
Una ficha de acceso es una estructura que contiene, entre otros, los siguientes datos:
Identificador de seguridad del usuario al que pertenece el proceso. En Windows cada usuario
tiene asociado un identificador de seguridad (Security IDentifier, SID), que lo identifica de
forma univoca. El SID es un número binario largo parte del cual se genera aleatoriamente. El
SID de un proceso puede ser obtenido usando la función LookupAc count S i d.
- Identificador de seguridad del grupo de usuarios al que pertenece el proceso. Similar al SID
de usuario pero aplicado a nivel de grupo.
- Grupos. Especifica los grupos a los que pertenece el usuario. Este campo es necesario para
implementar la API POSIX.
- Lista de control de acceso discrecional. Es la lista de control de acceso asignada por defecto
a los objetos creados por el proceso.
Privilegios. Permiten proporcionar a un proceso permisos para realizar ciertas tareas reser­
vadas para el administrador, como por ejemplo apagar el computador o el acceso a ciertos
archivos.
El sistema operativo Windows
•
313
Descriptor de seguridad. En Windows cuando se crea un objeto se le asigna un descriptor de
seguridad que es una estructura de datos que especifica las operaciones que pueden realizar los
diferentes usuarios sobre el objeto. Contiene, entre otros, los siguientes datos: SID del usuario
propietario del objeto, SID del grupo propietario del objeto y un puntero a la lista de acceso
discrecional (Discretionary Access Control List, DACL) asociada al objeto. La DACL del objeto
contiene una o varias entradas. Cada entrada contiene un SID (de usuario o de grupo), el estado
asociado a dicha entrada: permitir o denegar, y el conjunto de operaciones seleccionadas sobre el
objeto.
El descriptor de seguridad de un objeto puede ser pasado como argumento de las llamadas al sistema
que producen la creación de dicho objeto. Por ejemplo la función CreateF i l e de la API Win32 que
produce la creación de un objeto archivo admite como argumento de entrada información que permite
configurar el descriptor de seguridad del archivo. Si no se suministra esta información entonces el sistema
utiliza para configurarlo la información contenida en la ficha de acceso del proceso que invoca la llamada.
También es posible usar diferentes funciones de la API Win32 para inicializar y configurar el descriptor
de seguridad de un objeto, como por ejemplo la función Ini t i a l i z e S ecuri tyDe s c r ip t o r .
Un hilo de un proceso para poder operar sobre un objeto ya creado debe primero abrirlo utilizan­
do alguna función de tipo Open. Por ejemplo para abrir un objeto archivo se debe invocar la función
OpenF i l e de la API Win32 pasándole como argumento el nombre del objeto y el conjunto de permisos
que necesita (lectura, escritura, etc). El monitor de referencia de seguridad del ejecutivo en primer lugar
consulta la ficha de acceso del proceso para determinar su SID. A continuación busca en las entradas
de la DACL del descriptor de seguridad del objeto una entrada que contenga dicho SID. Cuando la en­
cuentra comprueba si el proceso tiene concedidos todos los permisos que necesita. En caso afirmativo la
función devuelve al hilo un descriptor del objeto para que lo utilice en lugar del nombre del objeto en las
futuras funciones que operen sobre el objeto abierto.
8.3.
Implementación, control y planificación de procesos multihilos en
Windows
8.3.1.
Implementación de los procesos multihilos en Windows
Windows implementa un modelo de proceso multihilo con un hilo del núcleo por cada hilo de usuario.
Un proceso es considerado como la unidad de gestión de recursos mientras que un hilo del núcleo es
utilizado como la unidad de asignación del procesador. Todos los hilos de un proceso comparten los
recursos asociados a dicho proceso (espacio de memoria, tabla de descriptores, ficha de acceso, etc). Un
hilo se ejecuta en modo usuario hasta que invoca una llamada al sistema, entonces pasa a ser ejecutado
en modo núcleo. También existen hilos creados por el propio sistema operativo para realizar diferentes
tareas administrativas que únicamente se ejecutan en modo núcleo.
Windows utiliza varias estructuras de datos para implementar el modelo de proceso multihilo. Algu­
nas de estas estructuras son mantenidas en el espacio de direcciones virtuales del proceso, mientras que
314
Ampliación de sistemas operativos
Pila en modo
usuario
Pila en modo
usuario
¡------ - - - - - - - - - - - - -------------- ----------- ... ... ... ... .,
!1
•
PEB
------------
-
------------------
-
B loque
EPROCESS
;--
r-- -
·--
��
L ..
4 W32PROCESS
�
Tabla de
de s c r ip tores
----
L ....
TEB
- -- -
Bloque
KPROCESS
-
--
--------------- --
B loque
KTHREAD
-
-------
Bloque
- KTHREAD
Bloque
ETHREAD
B loque
ETHREAD
r-
-
TEB
!
Espacio de
direcciones
del proceso
Espacio de
direcciones
del núcleo
---
'
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _,
..
4
W32THREAD
Pila en modo
núcleo
•
-1
W32THREAD
Pila en modo
núcleo
Principales estructuras de datos mantenidas por Windows para un implementar un proceso
multihilo, en este caso de dos hilos
Figura 8.2 -
otras son mantenidas en el espacio de direcciones virtuales del núcleo. En las siguientes subsecciones se
describen las estructuras de datos asociadas a un proceso y las estructuras de datos asociadas a un hilo.
Estructuras de datos asociadas a un proceso
Windows para implementar un proceso mantiene, entre otras, las siguientes estructuras de datos (ver
Figura 8.2) :
•
Bloque de entorno del proceso (Process Environment Block, PEB). Estructura mantenida en el
espacio de direcciones del proceso que contiene, entre otros, los siguientes datos: lista de módulos
cargados (archivos . exe y . dl l ) , variables de entorno, directorio de trabaj o actual, e información
para gestionar el montículo del proceso.
•
Tabla de descriptores. Estructura de datos mantenida en el espacio de direcciones del núcleo que
contiene los descriptores de los obj etos abiertos (archivos, semáforos, etc) por el proceso.
El sistema operativo Windows
315
•
Bloque W32PROCESS . Estructura mantenida en el espacio de direcciones del núcleo que contiene
la información sobre el proceso a la que necesita acceder win3 2 k . sys . Este bloque es creado
la primera vez que un hilo del proceso invoca una llamada al sistema asociada con la GUI de
Windows.
•
Bloque KPROCES S , también denominado bloque de control del proceso (Process Control Block,
PCB). Estructura mantenida en el espacio de direcciones del núcleo que contiene los datos que
Windows necesita conocer para planificar los hilos del proceso, como por ejemplo: puntero al
directorio de páginas del proceso (ver sección 8 . 5 . 3), tiempo de ejecución en modo usuario y en
modo núcleo, procesador al que está asociado, prioridad base del proceso, cuanto asignado a un
hilo por defecto y punteros para mantener una lista de hilos del núcleo (bloques KTHREAD)
asociados al proceso.
•
Bloque EPROCESS . Estructura mantenida en el espacio de direcciones del núcleo que contiene,
entre otros, los siguientes datos relativos a un proceso: bloque KPROCESS , identificador del pro­
ceso, identificador del proceso padre, estatus de salida, fecha y hora de creación y terminación,
cuotas de uso de los recursos, información para la gestión de memoria del proceso, puntero a la
ficha de acceso, puntero a la tabla de descriptores, puntero al bloque PEB , nombre de ruta del
archivo ejecutable que contiene la imagen del proceso, clase de prioridad del proceso, puntero al
bloque W32PROCESS y puntero al objeto tarea. Señalar que una tarea Uob) en Windows es un
conjunto de procesos.
Estructuras de datos asociadas a un hilo
Windows para implementar un hilo mantiene, entre otras, las siguientes estructuras de datos (ver
Figura 8 .2):
•
Pila en modo usuario y pila en modo núcleo. Windows asigna a cada hilo de un proceso una pila
en modo usuario y una pila en modo núcleo. Un hilo utiliza su pila en modo usuario hasta que
invoca una llamada al sistema y comienza a ejecutarse en modo núcleo entonces utiliza su pila en
modo núcleo. Cuando un hilo realiza una llamada al sistema o cuando se bloquea a la espera de un
evento su contexto hardware se almacena en una estructura de datos CONTEXT que se almacena en
la pila del núcleo. El contexto hardware almacenado en la pila es restaurado para poder continuar
con la ejecución del hilo justo en el punto en el que fue interrumpida.
•
Bloque de entorno del hilo (Thread Environment B lock, TEB). Estructura mantenida en el espacio
de direcciones del proceso que contiene, entre otros, los siguientes datos: identificador del hilo,
información sobre la pila en modo usuario, y puntero al bloque PEB .
•
B loque KTHREAD. Estructura mantenida en el espacio de direcciones del núcleo que contiene los
datos que Windows necesita conocer para planificar y sincronizar la ejecución del hilo. También
mantiene un puntero a una estructura con información sobre la pila del núcleo del hilo y un puntero
al TEB del hilo.
316
Ampliación de sistemas operativos
•
B loque W32THREAD. Estructura mantenida en el espacio de direcciones del núcleo que contiene
la información sobre el hilo a la que necesita acceder win3 2 k sys . Este bloque es creado la pri­
mera vez que un hilo del proceso invoca una llamada al sistema asociada con la GUI de Windows.
.
•
8.3.2.
Bloque ETHREAD. Estructura mantenida en el espacio de direcciones del núcleo que contiene,
entre otros, los siguientes datos relativos a un hilo de un proceso: bloque KTHREAD, puntero al
bloque W32THREAD, hora y fecha de creación y terminación del hilo, identificador del proceso
al que pertenece el hilo, puntero al bloque EPROCESS de dicho proceso, y dirección de comienzo
de la rutina que implementa el hilo.
Control de procesos multihilos en Windows
Estados de un hilo
Un hilo en Windows durante su tiempo de vida puede encontrarse en algunos de los siguientes esta­
dos 8 (ver Figura 8.3):
•
Inicializado (initialized). Es el estado en que se encuentra un hilo mientras está siendo creado.
•
Preparado (ready). El hilo está a la espera de ser planificado para ejecución.
•
Ejecutándose (running). Solo puede existir un hilo en este estado por cada procesador disponible.
Un hilo entra en este estado cuando se está ejecutando en un procesador.
•
Suspendido (standby). Solo puede existir un hilo en este estado por cada procesador disponible.
Un hilo en el estado preparado pasa a este estado cuando es seleccionado por el planificador para
ser ejecutado en el procesador al que está vinculado a continuación del hilo que lo está utilizando
actualmente. Puede suceder que un hilo en el estado suspendido regrese al estado preparado sin
llegar a usar el procesador si el planificador selecciona a otro hilo más prioritario para que entre
en el estado suspendido.
•
Terminado (terminated). El hilo ha terminado su ejecución.
•
Esperando (waiting). Un hilo pasa a este estado cuando tiene que esperar por un determinado
suceso, por ejemplo que se complete una operación de E/S .
•
Transición (transition). Un hilo entra en este estado si al salir del estado esperando las páginas de
su pila del núcleo no están cargadas en la memoria principal. Cuando estas páginas sean cargadas
el hilo pasará al estado preparado.
8En realidad existen más estados de los aquí enumerados pero se ha preferido omitirlos para facilitar la comprensión del
diagrama de transición de estados.
El sistema operativo Windows
Se selecciona otro hilo
más prioritario
//
/Seleccionado
Pasa a ej ecutarse
Expropiado
Creación
317
Termina
Se produce
el evento pero
su pila del núcleo
no está cargada
en memoria
Figura 8.3
-
Diagrama de transición de estados de un hilo en Windows
Creación de procesos e hilos
Existen varias funciones en la API Win32 que permiten crear un proceso, aunque sin duda la más
conocida y utilizada es la función Cre a te Pro c e s s de la librería kerne l 3 2 . dl l . Esta función admite
hasta diez argumentos de entrada, entre ellos: el nombre del programa a ejecutar en el hilo o hilos del
nuevo proceso, un puntero a las variables de entorno, las prioridades de planificación, el directorio de
trabajo del nuevo proceso, y los indicadores para especificar los descriptores de obj etos que heredará el
nuevo proceso.
Una vez invocada una función CreatePro c e s s se realizan, entre otras, las siguientes acciones [Rus­
sinovich et al., 2009] :
l. Validar los argumentos de entrada y convertirlos al formato admitido por los argumentos de la
llamada al sistema NtCreateUserPro c e s s . A continuación invocar a esta llamada.
2. En modo núcleo la rutina de tratamiento del núcleo de esta llamada al sistema procesa los argu­
mentos, abre el archivo ejecutable que se desea ejecutar y crea un objeto sección (ver sección 8.5 .2)
para más tarde mapear el archivo dentro del espacio de direcciones virtuales del nuevo proceso.
3 . Crear un objeto proceso en el ejecutivo de Windows . La creación de este objeto requiere asignar
y configurar un bloque EPROCESS , crear la ficha de acceso inicial, crear la tabla de descripto-
318
Ampliación de sistemas operativos
res, crear el espacio de direcciones inicial del proceso (ver sección 8.5 .2), inicializar el bloque
KPROCESS, configurar el PEB y concluir la configuración del espacio de direcciones virtuales
del proceso, la cual entre otras acciones requiere mapear el archivo ejecutable dentro del espacio
del nuevo proceso.
4. Crear un objeto hilo inicial en el ejecutivo de Windows. La creación de este objeto requiere crear
e inicializar un bloque ETHREAD, crear la pila en modo usuario y en modo núcleo, configurar el
contexto hardware inicial, asignar y configurar el TEB del hilo, y configurar el bloque KTHREAD.
El nuevo hilo es puesto en el estado inicializado.
5 . Realizar una postinicialización especifica del subsistema de entorno de Windows. En este punto la
llamada al sistema NtCreateUserPro c e s s ha retornado a modo usuario y existe un nuevo pro­
ceso creado que consta de un único hilo. Sin embargo todavía es necesario realizar algunas tareas
adicionales relacionadas con el subsistema de entorno de Windows ( c s r s s . exe ) para comple­
tar la inicialización del proceso [Tanenbaum, 2009] : kerne l 3 2 . dl l en primer lugar envía un
mensaje a c s r s s . exe para comunicarle que un nuevo proceso ha sido creado y le adjunta los des­
criptores del objeto proceso y del obj eto hilo creados para que pueda duplicarlos. En segundo lugar
c s r s s . exe registra al proceso y su hilo en las tablas que mantiene con todos los procesos e hilos
Win32 existentes. En tercer lugar asigna e inicializa una estructura W3 2 PROCE S S y W3 2 THREAD.
Finalmente muestra en la pantalla un cursor con la forma de corona circular en movimiento para
indicarle al usuario que se está iniciando un programa pero que puede usar el cursor mientras tanto.
Si el proceso no realiza una llamada al sistema asociada con la GUI en los próximos segundos el
cursor vuelve a su forma habitual (una flecha). Si el proceso realiza una llamada al sistema asocia­
da con la GUI transcurrido un cierto tiempo se muestra una ventana y el cursor vuelve a su forma
original.
6. Comenzar la ejecución del hilo inicial. En este punto c s r s s . exe ha devuelto el control a la fun­
ción CreatePro c e s s que ahora invoca a la llamada al sistema NtResumeThread para pasar al
estado preparado al hilo inicial del nuevo proceso y que éste pueda ser planificado para ejecución.
Además devuelve al proceso padre los identificadores y descriptores del proceso e hilo recién crea­
dos. Si la creación se ha realizado con éxito entonces C r e a t e Proc e s s devuelve como valor de
retorno un valor distinto de cero, en caso de error devuelve cero.
Por otra parte un hilo de un proceso puede crear otro hilo dentro del mismo proceso invocando a la
función Creat eThread de la librería kerne l 3 2 . dl l . Las acciones que realiza esta función guardan
cierta analogía con las acciones anteriormente descritas para la función CreatePro c e s s pero aplica­
das a nivel de hilo. Si se desea crear un hilo dentro de un proceso distinto se puede usar la función
Creat eRemo t eThread.
Otras operaciones sobre procesos e hilos
Aparte de las funciones C r e a t e Pro c e s s y Creat eThread existen otras muchas funciones dispo­
nibles en la API Win32 para operar a nivel de procesos o de hilos, como por ejemplo:
El sistema operativo Windows
319
•
OpenPro c e s s . Abre un objeto proceso.
•
OpenThread. Abre un objeto hilo.
•
Exi tPro c e s s . Termina la ejecución de un proceso y todos sus hilos.
•
Exi tThread. Termina la ejecución de un hilo
•
Ge tCurrent Pro c e s s id. Devuelve el identificador del proceso actual.
•
GetCurrentThreadid. Devuelve el identificador del hilo actual.
•
GetExi tCodePro c e s s . Devuelve el estatus de salida de un proceso.
•
GetExi tCodeThr ead. Devuelve el estatus de salida de un hilo.
•
S l eep. Pone al hilo en el estado esperando durante un determinado periodo de tiempo expresado
en milisegundos que se debe introducir como argumento de entrada de la función.
•
Swi t chToThread. Cede el uso del procesador a otro hilo en el estado preparado.
8.3.3.
Planificación de procesos multihilos en Windows
Windows es un sistema operativo de núcleo expropiable que utiliza como unidad de planificación
a los hilos del núcleo. Windows implementa un algoritmo de planificación de tipo expropiativo basado
en múltiples colas de prioridad y realimentación. Se consideran 32 niveles de prioridad comprendidos
dentro del rango [0, 3 1 ] , siendo O la prioridad más baj a posible y 3 1 la más alta. Estos 32 niveles son
divididos en dos grupos (ver Figura 8 .4) :
•
Niveles de tiempo real. Comprende los 1 6 niveles más prioritarios, es decir, los niveles de prioridad
en el rango [ 1 6, 3 1 ] . Windows asigna estos niveles de prioridad a los hilos del núcleo asociados
a tareas críticas del sistema, como por ejemplo: la gestión de la memoria, la gestión de la caché,
etc. También un usuario con los privilegios adecuados puede hacer que un hilo de un proceso de
usuario se ejecute con un nivel de prioridad de tiempo real, aunque no es recomendable para no
interferir con las tareas del sistema. Un hilo con un nivel de prioridad de tiempo real nunca ve
modificada su prioridad durante su tiempo de vida, es decir, su prioridad se mantiene fija. Señalar
que realmente Windows no implementa las características típicas de una planificación de tiempo
real. El nombre de niveles de tiempo real se utiliza únicamente para indicar que los hilos con estos
niveles de prioridad se planifican preferentemente a los restantes niveles.
•
Niveles dinámicos. Comprende los niveles de prioridad en el rango [ 1 , 1 5 ] . En estos niveles se eje­
cutan la mayoría de los procesos de los usuarios. Un hilo con un nivel de prioridad dinámico puede
ver modificada su prioridad durante su tiempo de vida. Windows bajo determinadas circunstancias
puede incrementar durante un corto periodo de tiempo la prioridad de un hilo.
320
Ampliación de sistemas operativos
Prioridad más alta
31
�
Niveles de tiempo real
16
15
1
1
1
1
1
1
1
1
1
1
1
-
Niveles dinámicos
1
Prioridad más baj a
Figura 8.4 -
o
Nivel reservado
Niveles de prioridad definidos en Windows
El nivel de prioridad O está reservado por Windows para la ejecución del hilo de inicialización de pá­
ginas a cero (Zero page thread) (ver sección 8.5 .4). Existe una instancia de este hilo por cada procesador
existente en el computador.
Prioridad de un proceso y de un hilo
Cada proceso tiene asignado una prioridad denominada prioridad base del proceso Pbp que es fun­
ción de la clase de planificación a la que pertenezca el proceso. Se distinguen seis posibles clases de
planificación: tiempo real (real-time), alta (high), por encima de normal (above normal), normal, debajo
de normal (below normal) y ociosa (idle). La Pbp por defecto asociada a cada una de estas clases es : 24,
1 3 , 1 0, 8, 6 y 4, respectivamente. Algunos procesos del sistema tienen una Pbp ligeramente superior al
nivel por defecto. Por ejemplo el gestor de sesión tiene asociada una Pbp ligeramente superior al valor
por defecto (8) de la clase de planificación normal.
La clase de planificación, y en consecuencia la prioridad base de un proceso, es heredada por defecto
de su proceso padre. Para cambiar la clase de planificación de un proceso se puede usar por ejemplo la
función S e t P r i o r i tyC l as s .
Por s u parte, cada hilo tiene asociada dos prioridades:
•
Prioridad base del hilo Pbh · Esta prioridad es función de la clase de planificación a la que pertenece
el proceso al que está asociado el hilo y de la prioridad relativa del hilo Pr respecto a Pbp · La
prioridad relativa de un hilo puede tomar alguno de los siguientes valores : tiempo crítico (time
El sistema operativo Windows
321
critica!) P r = 1 5 , la más alta (highest) P r = 2, por encima de normal (above normal) P r = 1 ,
normal P r = O , debajo de normal (below normal) P r = - 1 , la más baja (lowest) Pr = - 2 y ociosa
(idle) P r = - 1 5.
Cuando la prioridad relativa de un hilo se configura al valor tiempo crítico ( P r = 1 5) entonces
Pbh se fij a al nivel de prioridad más alto dentro del grupo de niveles de prioridad en los que se
encuentre la Pbp de la clase de planificación a la que pertenece el proceso al que está asociado el
hilo. Luego si P r = 1 5 y el proceso al que está asociado el hilo pertenece a la clase de tiempo real
entonces Pbh = 3 1 . En el caso de que el proceso pertenezca a cualquiera de las restantes clases de
planificación entonces Pbh = 1 5 .
Por el contrario s i l a prioridad relativa de un hilo s e configura al valor ocioso (P r = - 1 5) entonces
la Pbh se fij a al nivel de prioridad más bajo dentro del grupo de niveles de prioridad en los que se
encuentre la Pbp de la clase de planificación a la que pertenece el proceso al que está asociado el
hilo. Luego si P r = - 1 5 y el proceso al que está asociado el hilo pertenece a la clase de tiempo real
entonces Pbh = 1 6. En el caso de que el proceso pertenezca a cualquiera de las restantes clases de
planificación entonces Pbh = l .
En el caso de que la prioridad relativa P r se configure con los valores: la más alta (P r = 2), por
encima de normal ( P r = 1 ) , normal (P r = 0), debajo de normal (P r = - 1 ) o la más baja ( P r = - 2 ),
entonces la prioridad base del hilo se calcula mediante la siguiente expresión:
Pbh
=
Pbp + P r
(8. 1 )
La funciones GetThreadPr i o r i ty y S e tThreadP r i o r i ty permiten obtener y configurar, res­
pectivamente, la prioridad relativa de un hilo.
•
e
Prioridad actual del hilo P a · Es la prioridad que utiliza el sistema operativo para decidir que hilo
se debe planificar en un procesador. Inicialmente Pa es igual a Pbh pero si el proceso al que perte­
nece el hilo pertenece a una clase distinta de la tiempo real el sistema operativo puede aumentar
temporalmente la Pa de un hilo dentro del rango [Pbh + 1 , 1 5] bajo determinadas circunstancias.
Ejemplo 8.1
Supóngase un proceso que consta de un hilo. El proceso tiene asociada la clase de planificación normal,
luego la prioridad base del proceso es por defecto Pbp = 8 . Supóngase además que la prioridad relativa
del hilo está configurada al valor P r = 2 (la más alta). En dicho caso la prioridad base del hilo será igual
a Pbh = Pbp + P r = 8 + 2 = 1 0 . Por su parte la prioridad actual del hilo tomará inicialmente el valor
P a = Pbh = 1 0. Posteriormente el sistema operativo puede elevar, bajo determinadas circunstancias,
temporalmente Pa a algún nivel de prioridad dentro del rango [ 1 1 , 1 5 ] .
•
Implementación y gestión de las colas de prioridad
Los hilos en el estado preparado de la misma prioridad se mantienen en una cola PIFO. Windows
mantiene un conjunto de 32 colas de hilos en el estado preparado por cada procesador existente en el
322
Ampliación de sistemas operativos
sistema. Además por cada conjunto mantiene una máscara de 32 bits denominada resumen de prepara­
dos (ready summary). A las estructuras de datos que mantiene Windows para implementar las colas de
planificación se les denomina base de datos del distribuidor (dispatcher database).
Cada bit j de un resumen de preparados está asociado a una cola j, si el bit j está activado significa
que la colaj no esta vacía. Windows examina el resumen de preparados para determinar la cola de mayor
prioridad no vacía, ya que siempre planifica para ejecutarse en un procesador al primer hilo de la cola de
prioridad más alta no vacía del conjunto de colas asociada a dicho procesador.
S i existen varios hilos en la cola de mayor prioridad entonces se aplica una algoritmo de tumo
rotatorio, es decir, cada hilo se ejecuta durante un cuanto a cuyo término pasa al final de la cola y
comienza a ejecutarse el siguiente hilo de la cola. Si solo existe un hilo en la cola de mayor prioridad,
dicho hilo va recibiendo los cuantos que vaya necesitando hasta completar su ejecución.
Si durante la ejecución de un hilo H l entra en el estado preparado un hilo de mayor prioridad H2
entonces se le expropia el procesador al hilo H l sin esperar a que termine su cuanto. H l es colocado al
principio de la cola y cuando sea planificado se ejecutará durante el tiempo de cuanto que le restaba por
ejecutar.
Sentido de análisis
Colas de hilos en el estado preparado
asociadas a la CPU 1
Prioridad
más alta
'-T-......_.-'
Resumen
de preparados
Cabecera cola
31
Cabecera cola
30
Cabecera cola
Cabecera cola
1
Prioridad
más baja
Figura 8.5 -
Windows
Cabecera cola
o
Posible estado de las colas de hilos preparados asociadas a un procesador en un sistema
El sistema operativo Windows
e
323
Ejemplo 8.2
Supóngase que el estado de las colas de hilos preparados asociadas al procesador CPU l de un sistema
Windows es el que se muestra en la Figura 8 . 5 . Se observa que no existe ningún hilo en la cola 3 1 ni en
la cola i. Por el contrario hay dos hilos en la cola 30, tres hilos en la cola 1 y un hilo en la cola O.
Para determinar cuál será el próximo hilo que va a ser planificado en CPU l Windows examina de iz­
quierda a derecha el resumen de preparados de las colas de hilos preparados de CPU l en busca de un
1 , es decir, busca la cola asociada al nivel de prioridad más alto que no esté vacía. Así, en primer lugar
examina el bit O, éste vale O ya que la cola 3 1 está vacía. A continuación examina el bit l . Como la cola
30 contiene dos hilos el bit 1 tiene el valor l . Luego se selecciona para ser planificado el hilo situado más
cerca de la cabecera de la cola 30.
•
Duración del cuanto
La duración de un cuanto depende del tipo de versión de Windows: cliente o servidor. En el caso de
una versión cliente el cuanto asignado a un hilo tiene una duración por defecto de 2 tics de reloj , mientras
que el caso de una versión servidor tiene una duración de 12 tics de reloj . La duración de un tic de reloj
depende de cada plataforma. En el caso de la arquitectura x86 un tic de reloj tiene una duración de 1 0
ms, luego l a duración d e u n cuanto e s de 20 m s e n e l caso de las versiones cliente de Windows y 1 20 ms
en el caso de las versiones servidor. Estos valores pueden ser incrementados por el administrador en un
factor de 2, 4 o 6, si así lo desea.
Windows también aumenta el cuanto del hilo asociada a la ventana que se pone en primer plano en
el escritorio de acuerdo con una cantidad especificada en el registro de Windows. Con esta medida se
pretende mejorar la interactividad con el usuario.
Estructura e invocación del planificador
El planificador de Windows, a diferencia de otros sistemas operativos, no es implementado con una
única rutina que se ejecuta dentro de un hilo especial del núcleo, sino mediante un conjunto de rutinas
denominadas de forma colectiva como distribuidor o despachador del núcleo (kernel's dispatcher). Estas
rutinas son invocadas durante la ejecución de un hilo en modo núcleo cuando se produce determinados
eventos, como por ejemplo:
•
Un hilo ha pasado al estado preparado, bien porque acaba de ser creado o porque se ha producido
el evento por el que estaba esperando, por ejemplo, que se completara una operación de E/ S .
•
U n hilo sale del estado ejecutándose porque h a terminado, h a consumido s u cuanto, cede e l uso
del procesador a otro hilo o se bloquea en espera de que se produzca un evento (entra en el estado
esperando).
•
La prioridad de un hilo es cambiada por una llamada al sistema o por el propio distribuidor del
núcleo.
324
Ampliación de sistemas operativos
•
Se cambia mediante una llamada al sistema, como por ejemplo S e tTheadAf f i n i tyMa s k, el
procesador en que debe ejecutarse un hilo. Por defecto un hilo puede ejecutarse en cualquiera de
los procesadores existentes en la máquina, pero Windows permite asociar la ejecución de un hilo
a un determinado procesador, es lo que se conoce como afinidad del procesador.
Aumento temporal de la prioridad actual de un hilo
B ajo determinadas circunstancias Windows puede aumentar temporalmente la prioridad actual Pa de
un hilo perteneciente a una clase de planificación distinta de la de tiempo real que acaba de salir del estado
esperando o que lleva mucho tiempo en el estado preparado y todavía no ha accedido al procesador. El
objetivo de este aumento de la prioridad es compensar al hilo por el tiempo que ha perdido esperando.
Al aumentar su prioridad tendrá más probabilidades de ser elegido para ser planificado.
Inicialmente la prioridad actual de un hilo es igual a su prioridad base, es decir, Pa = Phh · B aj o
determinadas circunstancias la prioridad actual s e aumenta a u n valor Phh + x comprendido dentro del
rango [Pbh + 1 , 1 5 ] . Este aumento de la prioridad actual es temporal, ya que cada vez que el hilo consume
un cuanto su prioridad actual se decrementa en una unidad, es decir, Phh + x - l. La prioridad actual dej a
de decrementarse cuando alcanza e l valor d e l a prioridad base del hilo, e s decir, Pa = Phh ·
E l valor del incremento x d e l a prioridad base de un hilo e s fijado por el sistema operativo e n función
de las circunstancias por las que el hilo pasó al estado esperando o si lleva demasiado tiempo en el estado
esperando. Entre las circunstancias que producen un aumento de la prioridad de un hilo se encuentran
las siguientes:
•
Cuando se completa una operación de E/S, se despiertan a los hilos que estaban esperando por
dicha operación, el incremento x de prioridad actual que reciben dependen del dispositivo de E/S
en el que se ha realizado la operación. Si se trata de un disco duro, un CD-ROM, un puerto paralelo
o una tarj eta de vídeo, entonces x = l. Si se trata de una operación de red entonces x = 2. Si se
trata del teclado o del ratón entonces x = 6. Finalmente si se trata de una tarj eta de sonido entonces
X = 8.
•
Cuando se despierta a un hilo que estaba esperando por un mecanismo de sincronización (ver
sección 8 .4.2) como por ejemplo un semáforo o un evento, entonces x = 2 si pertenece al proceso
que se encuentra en primer plano (foreground). En caso contrario x = l.
•
Cuando se despierta a un hilo asociado a una ventana de la GUI su prioridad se incrementa en
x = 2 con el fin de mej orar la interactividad con el usuario.
•
Si un hilo lleva en el estado preparado durante más de 4 segundos entonces configura la prioridad
actual del hilo a su máximo valor posible, es decir, Pa = 1 5 y puede ejecutarse durante cuatro
cuantos consecutivos al término de los cuales su prioridad actual se configura a su valor base
Pa = Phh · Con esta medida se pretende evitar el abandono de hilos.
El sistema operativo Windows
e
325
Ejemplo 8.3
Supóngase un hilo cuya prioridad base es Pbh = Pbp + Pr = 8 + 2 = 10. Inicialmente su prioridad actual
es Pa = 1 0. Si el hilo pasa al estado esperando en espera de que se complete una operación de E/S en
la red entonces cuando se complete la operación su prioridad actual se incrementará en x = 2 unidades,
es decir, Pa = Pbh + 2 = 10 + 2 = 12. Cuando complete un cuanto su prioridad se reducirá a Pa = 1 1 y
cuando complete un segundo cuanto su prioridad se reducirá a Pa = 1 0. Es decir, al cabo de dos cuantos
recupera su valor de prioridad actual inicial.
•
8.4.
Sincronización y comunicación entre procesos multihilos en Windows
8.4.1.
Mecanismos de sincronización usados por el sistema operativo
Windows es un sistema operativo de código reentrante que soporta multiprogramación y multiproce­
samiento simétrico. Para garantizar la exclusión mutua en el uso de las secciones críticas del código del
sistema operativo se utilizan diferentes mecanismos de sincronización, siendo los spinlocks (ver sección
3 . 3) uno de los más utilizados.
Las rutinas básicas para la manipulación de un spinlock son:
•
KeAc qu i r e SpinLock ( ) . Para adquirir (cerrar) el spinlock.
•
KeRe l ea s e SpinLo c k ( ) . Para liberar (abrir) el spinlock.
Estas rutinas son implementadas en el kernel de Windows y pueden ser invocadas por los componen­
tes de Windows que se ejecutan en modo núcleo.
8.4.2.
Mecanismos de sincronización entre procesos multihilos disponibles en Windows
Objetos del distribuidor
Otros mecanismos de sincronización disponibles en Windows son los semáforos, los semáforos bina­
rios o mutexes, y los eventos. Estos mecanismos pueden ser utilizados tanto por los propios componentes
de Windows como por los hilos de los procesos de los usuarios. Se implementan mediante objetos del
núcleo que disponen de capacidades de sincronización: objeto semáforo, objeto mutex, objeto evento,
etc. A estos objetos se les denomina de forma general como objetos del distribuidor ya que su uso puede
alterar o afectar a la planificación del hilo que se sincroniza con el obj eto.
Un objeto del distribuidor puede encontrarse en dos posibles estados: estado no señalado y estado
señalado. El estado inicial de un objeto se configura cuando es creado. Un obj eto del distribuidor se
encuentra en el estado no señalado hasta que se produce un determinado suceso que hace que pase al
estado señalado. Cuando el objeto pasa al estado señalado el sistema operativo realiza unas determinadas
acciones, que generalmente consisten en despertar a uno o varios hilos que estaban esperando por el
objeto. Una vez realizadas dichas acciones, el objeto puede retomar o no al estado no señalado. Tanto el
326
Ampliación de sistemas operativos
suceso que produce el cambio de estado del objeto como las acciones que realiza el sistema operativo
dependen de cada tipo de obj eto.
Por ejemplo, en un objeto semáforo binario o mutex cuando un hilo libera el semáforo el objeto pasa
al estado señalado. Entonces el núcleo desbloquea a uno de los hilos que se encontraban en el estado
esperando dentro de la cola del semáforo para que continúe su ejecución y devuelve al objeto al estado
no señalado.
Un hilo puede sincronizarse con un objeto del distribuidor, para ello debe invocar a alguna de las
funciones de la API Win329 pasándole como argumento el descriptor del objeto por el que desea esperar.
Por ejemplo se podría utilizar la función wa i tForS ingl eObj e c t . También se podría utilizar la función
Wa i tF o rMu l t ip l eübj e c t s si el hilo desea esperar por varios obj etos.
Cuando se atiende la llamada, el hilo pasa al estado esperando y se añade a la cola de hilos esperando
por un determinado objeto. Cuando se produzca el suceso asociado al objeto por el que espera el hilo
entonces éste será despertado. También es posible pasar como argumento de entrada de la función un
indicador para especificar que la espera debe ser cancelada si se sobrepasa una determinada cantidad de
tiempo.
Semáforos generales y binarios
Un objeto semáforo general o semáforo con contador se crea con la función Crea t e s emaphor e .
Además esta función también permite inicializarlo y fijar s u valor máximo. L a operaciones s i gna l_s em
(operación V) y wa i t_s em (operación P) se implementan con las funciones Re l ea s e S emaphore y
Wa i tForS ingl eObj e c t , respectivamente.
En el caso de un objeto semáforo binario o mutex, su creación e inicialización se realiza con la fun­
ción CreateMut ex. Mientras que las operaciones básicas s i gnal_s em y wai t_s em se implementan
con las funciones Re l ea s eMut ex y Wa i tForS ingl eObj e c t , respectivamente.
Eventos
Un objeto evento se crea con la función Creat eEvent . Esta función también permite especificar
su estado inicial: señalado o no señalado. Si la función se ejecuta con éxito devuelve el descriptor del
obj eto.
Un hilo puede esperar por un objeto evento determinado invocando a Wa i tForS ingl eObj e c t pa­
sándole como argumento el descriptor del objeto. Otro hilo para avisar que el evento se ha producido
debe invocar a S e tEvent . Las acciones que realiza esta función dependen del tipo de evento. Si se trata
de un evento de notificación entonces se desbloquean a todos los hilos que estaban esperando por el
evento y el evento permanece en el estado señalado hasta que un hilo invoca a una función Re s e tEvent
sobre el evento. En el caso de un evento de sincronización se despierta a un hilo de los que estaban
esperando por el evento y el evento es configurado al estado señalado.
9En el caso de un componente de Windows en modo núcleo éste invocaría directamente a la llamada al sistema correspon­
diente sin necesidad de usar la función de la API Win32.
El sistema operativo Windows
327
Si se invoca a la función S e t Event y no existe ningún hilo esperando en el evento entonces sim­
plemente se cambia el estado del evento a señalado. De esta forma si un hilo invoca a una función
Wa i tForS ingl eObj e c t no tendrá que esperar por el evento porque ya se habrá producido.
La función Pu l s eEvent es similar a S e t Event con la diferencia de que si no existe ningún proceso
esperando entonces el evento se pierde ya que el evento no se pone en el estado señalado.
8.4.3.
Mecanismos de comunicación entre procesos multihilos disponibles en Windows
Windows implementa diversos mecanismos de comunicación entre procesos multihilos, entre ellos :
tuberías, conectores, mailslots, llamadas a procedimientos remotos y objetos compartidos. En las si­
guientes subsecciones se describen estos mecanismos.
Tuberías
El funcionamiento de las tuberías implementadas en Windows es similar al estudiado en los SOBU­
NIX. La principal novedad de la implementación de las tuberías en Windows es que existen dos modos
de funcionamiento:
•
Modo byte. Por la tubería se transmite un fluj o no estructurado de datos (bytes) con un tamaño
máximo fijo. Este modo coincide con la implementación de las tuberías en los SOBUNIX.
•
Modo mensaje. Por la tubería se transmite un fluj o de bytes estructurado en mensaj es de un cierto
tamaño. Por ejemplo un flujo de bytes de 256 bytes puede estructurarse en dos mensaj es de 1 28
bytes cada uno.
Las tuberías sin nombre se crean con la función C r e a t e P i p e . Para leer o escribir en ellas se deben
usar las funciones ReadF i l e y wr i t eF i l e , respectivamente.
En el caso de las tuberías con nombre se crean mediante la función CreateNamedP ipe. Para
conectarse a una tubería con nombre el proceso cliente debe utilizar las funciones C r e a t eF i l e o
Cal lNamedP ipe.
Cuando un hilo deja de usar una tubería debe usar la función C l o s eHand l e para liberar los recursos
que utiliza.
Conectores
Los conectores (sockets) se crean usando la función s o c k e t . Si un hilo desea conectarse a un conec­
tor ya creado debe usar la función C onne c t . Una vez conectado si desea enviar información debe usar
la función S end, mientras que para recibir información debe usar la función Recv. Cuando se termina
de usar un conector debe cerrarlo utilizando la función C l o s e S o c k e t .
328
Ampliación de sistemas operativos
Mailslots
Los mailslots son un mecanismo de comunicación unidireccional entre procesos multihilos importa­
do del sistema operativo OS/2. Se puede utilizar tanto localmente dentro de una misma máquina como
para comunicaciones en red, aunque no operan en redes de área ancha como Internet. Los mailslots
permiten enviar un mismo mensaj e a múltiples receptores. Sus principales inconvenientes es que son
unidireccionales y que no generan de forma explicita un mensaje de confirmación de recepción del en­
vío.
Un hilo puede crear un mailslot usando la función CreateMa i l s l o t la cual devuelve un descriptor
del objeto mailslot creado. Una vez creado, otros hilos si conocen el descriptor del mailslot pueden
escribir mensajes en el mailslot usando la función Wr i t e F i l e . El propietario del mailslot puede leer los
mensajes usando la función ReadF i l e . Cuando un hilo dej a de usar un mailslot debe usar la función
C l o s eHand l e para liberar los recursos que utiliza.
Llamadas a procedimientos remotos
Las llamadas a procedimientos remotos (Remote Procedure Calls, RPCs) son un mecanismo de
comunicación entre procesos que permite a un proceso A invocar a un procedimiento implementado
en otro proceso B de la misma máquina local o de una máquina remota. El proceso B ejecuta dicho
procedimiento y devuelve el resultado al proceso A. Este mecanismo se suele implementar mediante
paso de mensaj es de acuerdo a una estructura del tipo cliente-servidor.
La capa de transporte de mensajes puede implementarse mediante conectores TCP/IP, tuberías con
nombre o llamadas a procedimientos remotos avanzados (Advanced Local Procedure Calls, ALPCs).
Las ALPCs son un mecanismo de comunicación entre procesos usado internamente por Windows que
permite el paso de mensaj es a alta velocidad. Las ALPCS se implementan en el ejecutivo de Windows.
Objetos compartidos
Algunos objetos de Windows pueden ser compartidos por varios procesos. Este es el caso de un
objeto sección que permite mapear un archivo dentro del espacio de direcciones virtuales de cada uno de
los procesos que comparten el obj eto. Los cambios que realice un proceso sobre el archivo asociado al
objeto sección dentro de su espacio de direcciones serán visibles para todos los procesos que comparten
el objeto.
8.5.
Gestión de memoria en Windows
8.5.1.
Administrador de memoria
Windows utiliza la técnica de demanda de página para administrar la memoria principal. Todas las
tareas relativas a la administración de memoria son realizadas por el administrador de memoria que es
uno de los servicios que ocupa una mayor parte del código del ejecutivo de Windows, lo que da idea de
la complejidad del mismo.
El sistema operativo Windows
329
El administrador de memoria se implementa como un conjunto de rutinas que pueden ser invocadas
dentro del contexto de los hilos de los procesos. Además también utiliza para su implementación los
siguientes hilos del sistema:
•
Gestor de configuración del equilibrio. Se encarga de invocar periódicamente o si se cumplen
determinadas circunstancias a otros hilos asociados al administrador de memoria.
•
Gestor de los conjuntos de trabajo. Se encarga de implementar las políticas generales de gestión
de memoria: reemplazamiento de páginas, gestión de los conjuntos de trabajo, envejecimiento de
páginas, etc. Es invocado por el gestor de configuración del equilibrio una vez por segundo o si la
memoria libre disminuye por debajo de un determinado límite.
•
lntercambiador de pilas de procesos o hilos. Se encarga de realizar el intercambio de procesos e
hilos dentro y fuera de la memoria principal. Este hilo es despertado por el gestor de configuración
del equilibrio o por el planificador cuando hay que realizar una operación de intercambio.
•
Escritor de páginas modificadas. Se encarga de escribir páginas modificadas en los archivos de pá­
ginas (ver sección 8 . 5 .5). Este hilo es despertado cuando el tamaño de la lista de hilos modificados
excede un determinado límite.
•
Escritor de páginas mapeadas. Se encarga de escribir páginas modificadas en los archivos que
mapean dichas páginas. Este hilo es despertado cuando el tamaño de la lista de hilos modificados
excede un determinado límite o si las páginas de un archivo han estado en esta lista durante más
de cinco minutos.
•
Hilo de puesta de páginas a cero. Se encarga de inicializar con ceros las páginas de la lista de
marcos libres y pasarlos a la lista de marcos inicializados a cero (ver sección 8.5 .4).
•
Hilo de segmento dereferenciado. Se encarga de la reducción de la caché del sistema, así como del
aumento o la disminución de tamaño de los archivos de páginas.
El administrador de memoria de Windows utiliza diferentes algoritmos y reglas heurísticas para
realizar sus tareas. Señalar que estos algoritmos y reglas no han sido hechos públicos por Microsoft.
8.5.2.
Gestión de la memoria virtual
En Windows cada proceso tiene su propio espacio de direcciones virtuales. Un proceso ejecutándose
en modo usuario únicamente puede acceder a su espacio de direcciones de usuario. Las modificaciones
que un proceso realice en su espacio no son visibles al resto de procesos salvo que las realice en una
región de memoria compartida. Por otra parte, cuando el proceso se ejecuta en modo núcleo, como por
ejemplo cuando atiende una llamada al sistema, puede acceder a todo el espacio de direcciones virtuales,
tanto al del usuario como al del sistema operativo. Conviene recordar que cuando un proceso se ejecuta
en modo núcleo en realidad se está ejecutando el sistema operativo pero en el nombre del proceso.
330
Ampliación de sistemas operativos
OxFFFFFFFF
Espacio
de
direcciones
virtuales
del sistema
operativo
O x8 0 0 0 0 0 0 0
Ox7 FFEFFFF
Reservada (64 KiB)
Espacio
de
direcciones
virtuales
del usuario
O xO O O l O O O O
OxO O O O O O O O
2 GiB
2 GiB
Reservada (64 KiB)
-
Estructura más habitual del espacio de direcciones virtuales utilizado por Windows en
arquitecturas Intel x86 de 32 bits
Figura 8.6
En Windows, al igual que en otros sistemas operativos, el tamaño y la distribución del espacio de
direcciones virtuales dependen de cada arquitectura. En la arquitectura Intel x86 de 32 bits el espacio de
direcciones virtuales tiene un tamaño máximo de 232 = 4 GiB . Windows divide este espacio en cuatro
zonas (ver Figura 8.6):
•
Espacio reservado para la captura de punteros nulos. Esta zona no es accesible por los procesos.
Tiene un tamaño de 64 KiB .
•
Espacio de direcciones del usuario. Contiene las regiones de un proceso: código, datos, montículo,
pilas de los hilos, regiones de memoria compartida y archivos mapeados en memoria. Tiene un
tamaño próximo a los 2 GiB .
•
Espacio reservado para la captura de punteros erróneos. Esta zona no es accesible por los proce­
sos. Tiene un tamaño de 64 KiB .
•
Espacio de direcciones del sistema operativo. Contiene el código y los datos de los distintos com­
ponentes del sistema operativo: HAL, ejecutivo, núcleo, drivers, etc. También contiene las tablas
El sistema operativo Windows
331
de páginas de los procesos, la caché del sistema y la reserva de memoria paginada y no paginada.
Tiene un tamaño de 2 GiB .
En esta arquitectura Windows también puede trabaj ar con un espacio de direcciones de usuario de
casi 3 GiB con lo que el espacio de direcciones del sistema operativo queda reducido a 1 GiB .
Obviamente, en las arquitecturas de 64 bits el espacio de direcciones de usuario puede ser mucho
más grande. Por ejemplo en la arquitectura AMD x64 los procesos de 32 bits pueden tener un espacio de
direcciones de usuario de casi 4 GiB . Mientras que los procesos de 64 bits pueden tener un espacio de
usuario de 8 TiB . En esta arquitectura el espacio de direcciones del sistema operativo también tiene un
tamaño de 8 TiB .
En la técnica de demanda de página el espacio de direcciones virtuales se divide en páginas cuyo
tamaño depende de la arquitectura y del sistema operativo. Windows en las arquitecturas Intel x86 y
AMD x64 suele trabaj ar con un tamaño de página de 4 KiB , aunque en determinadas circunstancias
también trabaj a con páginas grandes de 4 MiB para mejorar el rendimiento del sistema. En Windows una
página i del espacio de direcciones virtuales puede encontrarse en tres posibles estados :
•
Libre. L a página n o está siendo utilizada actualmente. Cualquier referencia a una dirección virtual
asociada a una página libre produce un fallo de página por referencia a una dirección ilegal. A este
tipo de fallos de página en Windows se les denomina violación de acceso.
•
Asignada (committed). La página está asociada a una determinada información (código, datos,
etc).
•
Reservada. Son páginas libres que se reservan para contener una determinada información. Por
ejemplo, cuando se crea la pila de usuario de un nuevo hilo se reservan varias páginas virtuales
libres contiguas en el espacio de direcciones del proceso para su implementación. De las páginas
reservadas para la pila inicialmente solo una de ellas pasa al estado asignada.
Estructuras de datos para implementar el espacio de direcciones virtuales de un proceso
El administrador de memoria de Windows cuando se crea un proceso asigna a cada región existen­
te en el espacio de direcciones virtuales de un proceso un descriptor de direcciones virtuales (Virtual
Address Descriptor, VAD) que es una estructura que contiene, entre otros, los siguientes datos:
•
Rango de direcciones virtuales reservado para la región.
•
Objeto sección. Es un obj eto del núcleo que establece la correspondencia con el almacenamiento
de respaldo de las páginas de la región en memoria secundaria (ver sección 8 . 5 .5). Este objeto
permite mapear un archivo dentro de una región del espacio de direcciones virtuales.
•
Tipo de región. La región puede ser privada para uso exclusivo para el proceso o compartida por
varios procesos .
•
Protección : solo lectura, lectura y escritura, y copiar a l escribir.
332
Ampliación de sistemas operativos
Para encontrar más rápidamente el VAD que contiene una determinada dirección virtual, todos los
VADs del espacio de direcciones de un mismo proceso son organizados en un árbol AVL.
Funciones de la API Wln32 para la gestión del espacio de direcciones virtual de un proceso
Existen diferentes funciones en la API Win32 que permiten operar sobre el espacio de direcciones
virtuales de un proceso, entre las más utilizadas se encuentran las siguientes:
•
Vi rtualAl l o c . Permite reservar o asignar una cierta región en el espacio de direcciones virtuales
de un proceso.
•
V i r tua l Fre e . Permite liberar, desasignar, o liberar y desasignar una cierta región en el espacio
de direcciones virtuales de un proceso.
•
Vi r tua l Pro t e c t . Permite cambiar los permisos de una región.
•
Vi r tua l Query. Devuelve información sobre el estado de una cierta región.
•
CreateF i l eMapp ing. Crea una objeto de archivo mapeado, que es otra forma de denominar a
un objeto sección.
•
Op enF i l eMapp ing. Abre un archivo de objeto de archivo mapeado previamente creado.
•
MapVi ewO f F i l e . Mapea parcial o totalmente un archivo en el espacio de direcciones de un pro­
ceso.
•
8.5.3.
unrnapVi ewO f F i l e . Elimina un archivo mapeado del espacio de direcciones de un proceso.
Traducción de direcciones
Windows soporta tablas de páginas paginadas de diferentes niveles. El número de niveles de pagi­
nación utilizados depende de la arquitectura hardware. Por ejemplo, en el caso de la arquitectura Intel
x86 de 32 bits Windows utiliza por defecto dos niveles de paginación. Aunque si se trabaj a en dicha
arquitectura con el modo de extensión de dirección física (Physical Address Extension, PAE) entonces
utiliza tres niveles. También en la arquitectura Intel IA-64 utiliza tres niveles de paginación. En el caso
de la arquitectura AMD x64 utiliza cuatro niveles de paginación.
e
Ejemplo 8.4
En la arquitectura Intel x86 las direcciones virtuales tienen un tamaño de 32 bits. Windows considera
que las direcciones virtuales se descomponen en tres campos (ver Figura 8.7):
•
Índice del directorio de páginas (IDP). Tiene un tamaño de 10 bits. Contiene el índice de la entrada
de la tabla de páginas de primer nivel, también denominado directorio de páginas, donde hay que
buscar el número del marco de memoria que contiene a la página que ubica a la tabla de páginas
de segundo nivel que es una tabla de páginas ordinaria.
El sistema operativo Windows
333
N° de página i
�
-------------...,
-------------
Indice directorio
de páginas (IDP)
Indice tabla
de páginas (ITP)
Desplazamiento
1 0 bits
1 0 bits
1 2 bits
Figura 8.7 -
Formato de una dirección virtual en la arquitectura x86
•
Índice de la tabla de páginas (ITP). Tiene un tamaño de 10 bits (o 9 bits si el modo PAE esta
activado) Contiene el índice de la entrada de la tabla de páginas donde hay que buscar el número
del marco de memoria que contiene a la página que ha sido referenciada.
•
Desplazamiento. Tiene un tamaño de 12 bits. Especifica el desplazamiento desde el comienzo de
la página.
Cada proceso tiene un único directorio de páginas con tantas entradas como tablas de página se requieran
para describir el espacio de direcciones virtuales del proceso. La dirección física de comienzo Dirpo del
directorio de páginas de un proceso se almacena en el bloque KPROCESS asociado al proceso. Cuando
el proceso es planificado para ejecución el registro CR3 se carga con la Dirro del directorio de páginas
del proceso.
Señalar que como el campo IDP tiene un tamaño de 10 bits entonces el número de entradas máximo que
puede tener el directorio de páginas de un proceso es 2 10 = 1 024 entradas. Windows utiliza 4 bytes para
representar a una entrada de un directorio de páginas. Luego el tamaño máximo del directorio de páginas
de un proceso es de 4 KiB .
Cada entrada de un directorio de páginas contiene la localización y el estado de una de las tablas de
páginas del proceso. Las tablas de páginas se van creando según se van necesitando por ello el número
de entradas del directorio de páginas de un proceso no suele ser muy alto.
Asimismo puesto que el campo ITP tiene un tamaño de 1 0 bits entonces el número de entradas máximo
que puede tener una tabla de páginas es también de 1 024 entradas. Tanto Windows como el hardware uti­
lizan 5 bytes para representar una entrada de una tabla de páginas, luego el tamaño máximo de una tabla
de páginas es de 32 KiB . Señalar que en una entrada de una tabla de páginas el tamaño del campo número
de marco de página es de 20 bits, luego como máximo la memoria principal se puede descomponer en
220 marcos.
Cuando el procesador referencia a una dirección virtual la traducción de dicha dirección a una dirección
física se realiza siguiendo los siguientes pasos (ver Figura 8 . 8) :
l . Se suma IDP a l a dirección Dirpo contenida e n e l registro CR3 para construir la dirección física
Dirp 1 de la entrada del directorio de páginas donde hay que buscar el número k del marco de
memoria que contiene a la página que ubica a la tabla de páginas.
334
Ampliación de sistemas operativos
2. Se accede a Dirp¡ para leer dicho número de marco k y se le suma a ITP para construir la dirección
física Dirp2 de la entrada de la tabla de páginas donde hay que buscar el número j del marco de
memoria que contiene a la página i referenciada en la dirección virtual.
3. Si la entrada está marcada como válida se accede a la memoria principal para leer el número de
marco j y poder construir la dirección física Dirp3 a la que equivale la dirección virtual referenciada
por el procesador. En caso contrario se produciría un fallo de página.
•
La traducción de una dirección virtual en una dirección física solo se realiza si referencia a una pá­
gina válida y el tipo de acceso que se pretende realizar está permitido por la protección de la página.
En caso contrario se produce un fallo de página que es atendido por el manipulador de fallos de página
de Windows (MrnAc c e s s Fau l t ( ) ) que es una rutina que se ejecuta en el contexto del hilo cuya ejecuDirección virtual
�
N° de página i
1 IDP 1
+
ITP
1
Desplazamiento
J
1
Marco j
1
•
......
DirFo
J
1
Desplazamiento
_./
Dirección Física
Registro CR3
DirFo
Directorio
de páginas
�
Marco k
ll'f ¡
}
DP
�(+
�
D1rF2
Marco k
Tabla de páginas
Marco}
I
ITP
r--
Marco}
�
DirF3
Página i
t
Desp.
'
Memoria Principal
Figura 8.8 - Traducción
Memoria Principal
Memoria Principal
de una direcciones virtual válida a direcciones físicas en la arquitectura x86
El sistema operativo Windows
335
ción produjo el fallo de página. A los fallos de página que no requieren leer la página en disco se les
denominan fallos de página suaves. En caso contrario se les denominan fallos de página duros.
Con objeto de reducir el número de fallos de página duros que produce la ejecución de un proceso,
Windows almacena la secuencia de páginas referenciadas por dicho proceso utilizando una tecnología
denominada SuperFetch. Cuando dicho proceso vuelve a ser iniciado el administrador de memoria realiza
una prepaginación de las páginas del proceso de acuerdo con la secuencia de páginas referenciadas
guardada para dicho proceso. Dichas páginas son cargadas en la lista de marcos de página en standby de
memoria principal (ver sección 8.5 .4) de tal forma que las referencias a estas páginas producen fallos de
página suaves.
8.5.4.
Gestión de la memoria física
Conjunto de trabajo
Para gestionar la memoria física Windows utiliza el concepto de conjunto de trabajo de un proceso
el cual queda definido por las páginas pertenecientes al proceso cargadas en memoria, las cuales pueden
ser referenciadas sin producir un fallo de página. El tamaño y la composición del conj unto de trabajo de
un proceso varían durante el tiempo de vida del proceso.
Windows fija un límite inferior y un límite superior para el tamaño del conjunto de trabajo de un
proceso. Cuando se inicia la ejecución de un proceso el límite inferior se configura a un valor de entre 20
y 50 páginas. Mientras que el límite superior se configura a un valor comprendido entre 45 y 345 páginas.
Estos valores iniciales dependen de la memoria física total existente, además pueden ser configurados
por el administrador del sistema.
Cuando existe suficientemente memoria libre Windows permite que un proceso pueda superar su
límite máximo. Sin embargo cuando la memoria principal libre comienza a escasear Windows comienza
a reducir el tamaño de los conjuntos de trabajo de los procesos que han superado su límite máximo.
Si con esta medida la memoria libre sigue siendo escasa entonces comienza a reducir el tamaño de los
conjuntos de trabaj o de todos procesos.
La gestión de los conjuntos de trabajo de los procesos es realizada por el gestor de los conjuntos de
trabajo que es invocado por el gestor de configuración del equilibrio una vez por segundo o si la memoria
libre disminuye por debajo de un determinado límite.
Base de datos de los números de marcos de página
La base de datos de los números de marco de página es una tabla que el administrador de memoria
de Windows mantiene para describir el estado de cada marco de página de la memoria principal. Un
marco de página puede encontrarse en alguno de los siguientes estados [Russinovich et al. , 2009] :
•
Activo o válido. El marco contiene una página que pertenece al conjunto de trabaj o de uno o varios
procesos o al conjunto de trabajo del sistema operativo.
•
Transición. Se trata de un estado temporal para un marco que contiene una página que no pertenece
al conjunto de trabaj o de un proceso ni a ninguna de las listas de páginas. Un marco se encuentra
336
Ampliación de sistemas operativos
en este estado cuando está asignado a una página sobre la que se está realizando una operación de
E/S.
•
Standby. El marco contiene una página que ha sido eliminada del conjunto de trabajo de un proceso
o ha sido prepaginada. Dicha página no ha sido modificada desde su última escritura en el disco.
•
Modificado. El marco contiene una página que ha sido eliminada del conjunto de trabajo de un
proceso y cuyo contenido ha sido modificado y debe ser escrita en el almacenamiento de respaldo.
•
Libre. El marco está libre y contiene una página con datos.
•
Inicializado a O. El marco está libre y contiene una página llena de ceros.
•
Rom. El marco contiene una página que representa a la memoria ROM.
•
Malo (bad). El marco contiene una página que ha generado un error de paridad, u otro error hard­
ware, y no puede ser utilizada. También se utiliza internamente para representar a las páginas del
sistema operativo que se encuentran en transición entre un estado y otro.
La base de datos de los números de marco de página tiene una entrada por cada marco de página en
que se descompone la memoria principal. La tabla está indexada por el número de marco de página j.
Cada entrada se implementa como una estructura de datos de tamaño fijo cuyo formato puede variar en
función de si la página contenida en el marco es compartida o privada. En cada entrada se almacenan,
entre otros, los siguientes datos: estado del marco, contador del número de entradas de tablas de página
que referencian al marco, y un puntero a la entrada de la tablas de páginas ordinarias (si es una página
privada) o prototipo (si es una página compartida) que apunta al marco.
Una tabla de página prototipo es una variante de una tabla de páginas ordinarias que Windows
utiliza para almacenar la información necesaria para traducir las referencias a una determinada región
de memoria compartida. Las entradas de las tablas de páginas que hacen referencia a una determinada
página de una región de memoria compartida poseen un puntero a la entrada adecuada de la tabla de
páginas prototipo asociada a la región de memoria compartida correspondiente.
e
Ejemplo 8.5
En la Figura 8.9 se muestra a modo de ejemplo un posible estado de las entradas k = 35 a k = 42 de la
base de datos de los números de marcos de página. La entrada k = 35 de la base de datos está asociada al
marco j = 35 de memoria principal. De acuerdo con la figura este marco se encuentra actualmente en el
estado activo lo que significa que contiene una página que actualmente pertenece al conjunto de trabajo
de un proceso. En concreto se trata de la página i = O del proceso A.
La entrada k = 37 de la base de datos está asociada al marco j = 37 de memoria principal, el cual se
encuentra actualmente en el estado modificado. Luego contiene una página que ha sido eliminada del
conjunto de trabajo de un proceso y su contenido ha sido modificado y debe ser escrita en el almacena­
miento de respaldo. En concreto se trata de la página i = 2 del proceso A.
Finalmente, la entrada k = 42 de la base de datos está asociada al marco j = 42 de memoria principal que
se encuentra actualmente en el estado activo. Se observa que dicho marco contiene una página compartida
El sistema operativo Windows
337
Base de datos de los números
de marcos de página
i
1
!
1
k=3 5
Activo
Tabla de páginas
Proceso A
-------------------------------------------------------
1111
k=3 6
k=37
k=3 8
j=6 1 v=O
i=3
p=O v= l
i=4
j=60 v=O
Modificado
-------------------------------------------------------
1111
.---
k=3 9
J
1
''
'1
k=40
k=4 1
k=42
37 m 1
i=O
i= l
i=2
j-35 v- l
Activo
----------------·
j-42 v- 1
�p
p= l
!
11
i'
1
!
1
Tabla de páginas prototipo
de una región compartida
Figura 8.9 -
o
Tabla de páginas
Proceso B
i=O
p=O v= l
1
1
Estado de la base de datos de los números de marcos de página del Ejemplo 8 . 5
y a que l a entrada p = O d e la tabla d e páginas prototipo asociada a una región d e memoria compartida
entre los procesos A y B apunta precisamente a la entrada k = 42 de la base de datos.
•
El administrador de memoria organiza las entradas de la base de datos de los números de marco
de página en cuatro listas: lista de marcos inicializados a O, lista de marcos libres, lista de marcos
modificados, y lista de marcos en standby. Cada entrada perteneciente a una lista contiene el número de
la siguiente entrada que forma parte de dicha lista.
Cuando un proceso termina su ejecución todas sus páginas privadas son colocadas en la lista de
marcos libres. Por otra parte, cuando una página dej a de pertenecer al conjunto de trabaj o de un proceso,
bien porque ha sido reemplazada o bien porque se ha reducido el tamaño del conj unto por necesidades de
memoria, si la página ha sido modificada entonces ingresa en la lista de marcos modificados. Mientras
que si no ha sido modificada ingresa en la lista de marcos en standby.
Cuando el administrador de memoria necesita asignar un marco inicializado a cero, por ejemplo,
para la región de pila o el montículo de un proceso, entonces selecciona un marco de la lista de marcos
inicializados a cero. Si esta lista está vacía entonces selecciona un marco de la lista de marcos libres y
antes de asignarlo lo inicializa a cero. Si la lista de marcos libres también está vacía entonces selecciona
338
Ampliación de sistemas operativos
a un marco de la lista de marcos en standby y antes de asignarlo lo inicializa a cero.
Existe un hilo denominado hilo de puesta de página a cero que se encarga de inicializar a cero las
páginas que se encuentran en la lista de marcos libres y pasarlas a la lista de marcos inicializados a cero.
Existen varias instancias de este hilo, una por cada procesador disponible. Este hilo se ejecuta con la
prioridad más baj a posible (prioridad 0), en consecuencia solo se ejecuta cuando no existe ningún otro
hilo en el estado preparado.
Por otra parte, cuando el administrador de memoria necesita asignar un marco de memoria que no
requiere estar inicializado a cero entonces primero lo intenta obtener de la lista de marcos libres. Si dicha
lista está vacía entonces lo intenta obtener de la lista de marcos inicializados a cero. Finalmente si esta
lista también está vacía entonces acude a la lista de marcos en standby.
En la Figura 8 . 1 0 se resumen las posibles transiciones entre las listas de marcos de páginas .
Fallo de página
inicializada a cero
Lista de marcos
inicializados a cero
,
....
Fallo de página duro
Conjuntos de trabajos
de los procesos
Fallo de página
suave
Fallo de página
suave
Lista de marcos
libres
Lista de marcos
en standby
�
Lista de marcos
modificados
Paginas seleccionadas para ser remplazadas
Figura 8.10 -
8.5.5.
Transiciones entre las listas de marcos de páginas
Respaldo de páginas en memoria secundaria
Las regiones del espacio de direcciones virtuales de un proceso se pueden clasificar en dos tipos:
regiones generadas mediante el mapeado de un determinado archivo (código y datos inicializados) y
regiones anónimas no generadas mediante ningún mapeado (pila y montículo).
El sistema operativo Windows
339
El almacenamiento de respaldo en memoria secundaria de las páginas pertenecientes a regiones ge­
neradas mediante el mapeado de un archivo es el propio archivo en disco. Para las páginas pertenecientes
a regiones anónimas o copias privadas de páginas marcadas como copiar al escribir, Windows utiliza
como almacenamiento de respaldo los archivos de páginas (page files) que son archivos cuyos bloques
de datos almacenan páginas de los procesos o del sistema operativo.
Windows soporta hasta 1 6 archivos de páginas. El tamaño máximo de un archivo de páginas varía
en función de la arquitectura. Por ejemplo, en la arquitectura Intel x86 sin uso del modo PAE el tamaño
máximo de un archivo de páginas es de 4,095 MiB . Mientras que si se usa el modo PAE el tamaño
máximo es 1 6 TiB . Cuando se arranca el sistema el proceso gestor de sesión accede al registro para leer
la lista de los archivos de página que hay que abrir.
Cuando una página de una región anónima es asignada Windows reserva para ella espacio en un
archivo de páginas. Sin embargo la localización exacta de la página dentro del archivo no se asigna por
adelantado sino una vez que la página es escrita en el archivo.
Los marcos de página que contienen páginas modificadas que han sido seleccionadas para ser inter­
cambiadas fuera de memoria principal se encuentran dentro de la lista de marcos de página modificados.
Estas páginas modificadas deben ser escritas en su almacenamiento de respaldo correspondiente. Existen
dos hilos del sistema encargados de realizar esta tarea:
•
Escritor de páginas modificadas. Se encarga de escribir páginas modificadas en los archivos de
páginas. Este hilo es despertado cuando el tamaño de la lista de hilos modificados excede un
determinado límite.
•
Escritor de páginas mapeadas. Se encarga de escribir páginas modificadas en los archivos que
mapean dichas páginas. Este hilo es despertado cuando el tamaño de la lista de hilos modificados
excede un determinado límite o si las páginas de un archivo han estado en esta lista durante más
de cinco minutos.
Una vez que una página modificada ha sido escrita en su almacenamiento de respaldo el marco que
la contiene pasa de la lista de marcos modificados a la lista de marcos en standby.
8.6.
Gestión de archivos en Windows
8.6.1.
Funciones de la API Win32 asociadas a la gestión de archivos y directorios
Existen varias funciones en la API Win32 asociadas a la gestión de archivos y directorios, entre las
funciones más conocidas se encuentran las siguientes :
•
CreateF i l e . Permite crear un archivo nuevo o abrir uno ya creado. Si se ejecuta correctamente
se crea un objeto archivo cuyo descriptor (handle) es devuelto al proceso que ha invocado a esta
función.
•
C l o s eHand l e . Cierra el archivo asociado al descriptor pasado como argumento de entrada.
340
Ampliación de sistemas operativos
•
De l e t eF i l e . Borra un archivo cuyo nombre de ruta debe ser pasado como parámetro de entrada.
Su funcionamiento es similar a la función unl ink de los SOBUNIX.
•
ReadF i l e . Lee una determinada cantidad de bytes de un archivo y los almacena en una determina
posición de memoria.
•
Wr i t eF i l e . Lee una determinada cantidad de bytes de una determinada posición de memoria y
los escribe en un archivo.
•
S e tF i l e P o inter. Configura a una determina posición el puntero de lectura/escritura de un ar­
chivo.
•
Ge t F i l eAttribu t e s . Devuelve los atributos de un archivo: si es un archivo o un directorio, si
está encriptado, si está comprimido, si está oculto, si es un enlace simbólico, etc.
•
CreateDi r e c to ry. Crea un directorio nuevo cuyo nombre de ruta debe ser introducido como
argumento de entrada.
•
Remove D i r e c t o ry. Elimina un directorio vacío cuyo nombre de ruta debe ser introducido como
argumento de entrada.
•
8.6.2.
S e tCurrentDi r e c t o ry. Cambia el directorio de trabaj o actual.
Sistemas de archivos
Cada sistema de archivos presente en memoria secundaria es tratado por Windows como una unidad o
volumen lógico independiente, cada una de los cuales posee su propia estructura de directorios. Windows
asigna una letra (C, D, E, . . . ) a cada unidad. El nombre de ruta de un archivo comienza por tanto con el
nombre del volumen lógico en el que está almacenado.
Las versiones modernas de Windows cuando se instalan en una partición de disco crean un sistema de
archivos principal de tipo NTFS (ver sección 8 .7). Aparte de NTFS Windows también soporta sistemas
de archivos CDFS , UFS , FAT 1 2, FAT 1 6, FAT32 y extFAT. Para interactuar con un determinado tipo de
sistema de archivos, el gestor de E/S (ver sección 8 . 8) invoca al driver del sistema de archivos (File
System Driver, FSD) correspondiente. Por ejemplo, para los sistemas de archivos NTFS utiliza el FSD
nt f s . sys , para el sistema CDFS utiliza el FSD c d f s . sys , etc.
El sector de arranque de cada partición con un sistema de archivos soportado por Windows contiene
la información necesaria para que el FSD asociado a dicho tipo de sistema de archivos pueda identificar
y localizar los metadatos y datos almacenados en el volumen. S eñalar que el FSD no accede al disco
directamente sino que invoca al gestor del volumen que a su vez invoca al driver del disco correspondiente
Por otra parte, cuando un proceso intenta acceder (leer o escribir) a alguna parte del archivo que no
está cargada en memoria entonces el gestor de memoria invoca al gestor de E/S que en función de donde
está localizado el archivo invoca al FSD adecuado para que realice la operación solicitada.
El sistema operativo Windows
8. 7.
341
El sistema de archivos NTFS
El sistema de archivos NTFS (New Technology File System, sistema de archivos de tecnología nue­
va) fue desarrollado a mediados de los noventa para ser el sistema de archivos principal de Windows
NT. Se trata de un sistema de archivos bastante versátil diseñado para cumplir con las necesidades de
almacenamiento y recuperación de datos de altas prestaciones necesarias en las estaciones de trabajo y
servidores de las empresas.
8.7.1.
Características principales
Un sistema de archivos NTFS presenta, entre otras, las siguientes características :
•
La unidad básica de asignación de espacio es el cluster. Un cluster es un conjunto contiguo de
sectores de disco. El tamaño en bytes de un cluster es una potencia de dos comprendida dentro
del rango [5 1 2 bytes, 64 KiB] . El tamaño se define en el momento de la creación del sistema de
archivos en función del tamaño de la partición. Por ejemplo si la partición tiene un tamaño mayor
de 32 GiB el tamaño de un cluster se fij a a 64 KiB . En este caso si un sector tiene un tamaño de
5 1 2 bytes entonces un cluster constará de 1 28 sectores contiguos.
Cada cluster tiene asignada una dirección de 64 bits, con lo que teóricamente el tamaño máximo
de una partición NTFS es de 2 64 clusters. Actualmente Windows limita el tamaño de una dirección
de un cluster a 32 bits lo que para un tamaño de cluster de 64 KiB permite que el tamaño máximo
de una partición sea ligeramente inferior a 256 TiB .
En Windows el flujo de datos de un archivo se descompone en M clusters virtuales contiguos,
mientras que una partición de disco se descomponen en P clusters lógicos contiguos. En ambos
casos los clusters se numeran comenzando en O. Si se utiliza Bv para denotar a una número de
cluster virtual de un archivo y BL para denotar a un número de cluster lógico de una partición,
entonces Bv puede tomar valores enteros comprendidos entre O y M l. Mientras que BL puede
tomar valores enteros comprendidos entre O y P - l .
-
•
Toda l a información contenida e n u n sistema de archivos NTFS s e estructura e n archivos. Los da­
tos almacenados en un volumen NTFS , incluidos los metadatos del propio sistema de archivos, se
estructuran en archivos. Esta estructuración simplifica la localización, mantenimiento y protección
de los datos.
•
Un archivo (o un directorio) consiste de múltiples flujos de bytes. A diferencia de otros sistemas
de archivos donde un archivo es implementado como una secuencia lineal de bytes, en NTFS un
archivo (o un directorio) consiste de múltiples flujos de bytes de tamaño variable. Cada flujo de
bytes representa a un atributo del archivo. Entre los atributos de un archivo soportados en un
sistema NTFS se encuentran los siguientes:
- Información estándar ( $ STANDARD_INFORMAT I ON) . Este atributo especifica si el archivo
es de solo lectura o de lectura-escritura, si es un archivo o un directorio, la fecha y hora de
342
Ampliación de sistemas operativos
creación del archivo, la fecha y hora de la última modificación del archivo, y el contador de
enlaces duros.
- Nombre del archivo ( $ F I L E_NAME).
- Descriptor de seguridad ( $ SECURITY_DESCRI PTOR) . Este atributo se mantiene por compatibilidad con las versiones anteriores de NTFS . La versión actual de NFTS almacena los
descriptores de seguridad de todos los archivos en el archivo de metadatos $ S e cur e.
- Datos ( $ DATA). Contiene los datos del archivo (o directorio).
- Identificador del objeto ( $ OBJECT_I D). Es un identificador de 64 bytes, siendo los 1 6 bytes menos significativos únicos de cada volumen. Existen funciones de la API Win32 que
permiten abrir un archivo por su identificador de objeto en lugar de usar su nombre.
- Raíz índice. ( $ INDEX_ROOT). Se utiliza para implementar directorios (ver sección 8.7.3).
- Asignación índice. ( $ INDEX_ALLOCATI ON) . Se utiliza para implementar directorios.
- Mapa de bits. ( $ B I TMAP). Se utiliza para implementar directorios.
Cada atributo tiene la siguiente estructura: código numérico del tipo atributo y valor del atributo.
También es posible poner un nombre a un atributo, el cual se almacena después del valor del atri­
buto. El uso del nombre de un atributo resulta de utilidad cuando un archivo tiene varios atributos
de un mismo tipo. Por ejemplo un archivo puede tener varios atributos datos o varios atributos
nombre.
•
Un archivo puede constar de múltiples flujos de datos. En NTFS un archivo consta por defecto
de un único atributo datos que no tiene nombre. Adicionalmente es posible definir otros atributos
datos asignándole a cada uno un nombre. Luego en NTFS un archivo puede contener múltiples
flujos de datos de diferentes tamaños. Cada fluj o de datos adicional puede ser accedido de la
siguiente forma:
nombre de l archivo : nombre de l f lu j o
Por ejemplo, supóngase un archivo prueba . txt que consta de dos flujos de datos: uno el flujo de
datos por defecto sin nombre y otro definido adicionalmente de nombre par t e 2 . Para trabaj ar con
el flujo por defecto simplemente se referencia al nombre del archivo, mientras que para trabaj ar
con el flujo con nombre habría que referenciarlo de la siguiente forma: prueba . txt : part e2 .
•
Los nombres de los archivos se codifican en código Unicode. Ello permite utilizar en los nombres
de los archivos caracteres diferentes del alfabeto latino. Un sistema NTFS es capaz de distinguir
entre caracteres en mayúsculas o en minúsculas en los nombres de archivos, luego Prueba . txt
y prueba . txt son nombres de archivos diferentes en NTFS . Sin embargo Windows no hace uso
de esta propiedad salvo cuando ejecuta funciones asociadas a la API POSIX. En la API Win32 no
se distingue entre mayúsculas y minúsculas a la hora de interpretar los nombres de los archivos,
aunque si respeta el que se usen mayúsculas en los nombres, es decir, que no las cambia cuando
almacena el nombre.
El sistema operativo Windows
343
•
Un nombre de archivo puede tener una extensión máxima de 255 caracteres.
•
Implementa una estructura de directorios de gráfica acíclica con soporte de enlaces duros y de
enlaces simbólicos. Los enlaces duros solo se pueden realizar a archivos dentro de un mismo vo­
lumen. Además no es posible realizar enlaces duros a directorios. Estas restricciones no se aplican
en el caso de los enlaces simbólicos. Por motivos de seguridad únicamente el administrador del
sistema tiene los privilegios necesarios para crear enlaces simbólicos. Por su parte un enlace duro
puede ser creado por cualquier usuario siempre que tenga los derechos de acceso oportunos sobre
el archivo al que apunta con el enlace duro.
Para crear un enlace duro se puede usar el comando rnkl ink con la opción / H . También se puede
utilizar la función C r e a t eHardL ink de la API Win32. La creación de un enlace simbólico se
puede realizar usando el comando rnkl i nk o la función Creat eSyrnbo l i c L i nk de la API Win32.
Los enlaces simbólicos son implementados en NTFS mediante un mecanismo de redirecciona­
miento denominado puntos de reanálisis. Un punto de reanálisis (reparse points) es un archivo o
un directorio que tiene un bloque de datos denominado datos de reanálisis asociado con él. Un
dato de reanálisis es un dato definido por el usuario sobre el estado o localización del archivo o
el directorio. Cuando NTFS encuentra un punto de reanálisis durante el análisis de un nombre de
ruta, se produce un error y se devuelve el dato de reanálisis al gestor de obj etos que reinicia la
operación de análisis teniendo en cuenta el dato de reanálisis encontrado. Los puntos de reanálisis
también son utilizados en NTFS para el montaj e del sistema de archivos.
•
Recuperación. Un sistema de archivos NTFS puede ser recuperado y devuelto a un estado con­
sistente si se producen fallos en el sistema o en el disco. Conviene aclarar que lo que se recupera
es el estado de las estructuras de datos del sistema de archivos no los contenidos de los archivos.
Para poder recuperar el sistema de archivos se realiza un almacenamiento redundante de los datos
críticos del sistema. Además las operaciones que pueden cambiar el estado del sistema se imple­
mentan mediante transacciones atómicas. Una transacción atómica se realiza completamente o no
se realiza. Cada transacción se registra en el archivo de registro (log file) antes de realizarse sobre
el volumen. De esta forma si se produce un fallo se consulta el archivo de registro para saber que
transacciones estaban pendientes para rehacerlas o deshacerlas. De esta forma siempre se garantiza
que el sistema de archivos se encuentra en un estado consistente.
•
Registro por diario Uournaling). NTFS soporta diferentes mecanismos para registrar los cambios
que se producen en los archivos y directorios almacenados en un volumen NTFS . Esta información
resulta de gran utilidad para determinadas aplicaciones, como por ejemplo los gestores de copias
de seguridad. Uno de estos mecanismos es el diario de cambios (change j ournal) que es un archivo
especial (interno del sistema NTFS) que puede ser leído por las aplicaciones.
•
Soporte de cuotas. NTFS dispone de mecanismos para fiscalizar y limitar el espacio en disco
disponible para cada usuario.
344
Ampliación de sistemas operativos
•
Compresión. NTFS permite crear archivos en modo comprimido, para ello se debe introducir el
argumento adecuado en la función CreateF i l e . El proceso de compresión es realizado por el
driver del sistema NTFS cuando el archivo es escrito en el disco. Cuando un proceso solicita leer un
archivo almacenado en modo comprimido el driver descomprime el archivo. Tanto la compresión
como la descompresión son actividades totalmente invisibles al proceso que no se percata de su
realización.
•
Encriptación. NTFS también permite crear archivos encriptados . El procedimiento de encriptación
y desencriptación es realizado por el driver de encriptación del sistema de archivos o driver EFS
(Encryption File System). Solo los usuarios autorizados pueden ver el contenido de un archivo
encriptado. Generalmente la encriptación se aplica marcando un directorio con este atributo de tal
forma que todos los archivos que se aloj an en el directorio (y los nuevos que se creen en él) son
encriptados de manera automática. Tanto la encriptación como la desencriptación son actividades
totalmente invisibles al proceso que no se percata de su realización.
8. 7 2
.
.
Estructura en el disco de un sistema NTFS
Un sistema de archivos NTFS presenta la siguiente estructura en la partición de disco donde se crea
[Stallings, 2005] (ver Figura 8 . 1 1 ) :
Partición de disco
Tabla de
archivos maestra
Figura 8.11
Á rea de datos de los archivos
- Estructura en el disco de un sistema de archivos NTFS
•
Á rea de arranque. Se sitúa al principio de la partición y puede ocupar hasta 1 6 sectores consecuti­
vos. Contiene información sobre la estructura del volumen y las estructuras de datos del sistema de
archivos, como por ejemplo la dirección física de comienzo de la tabla de archivos maestra. Si se
trata de la partición activa entonces el área de arranque también contiene el programa de arranque
o cargador de Windows.
•
Tabla de archivos maestra (Master File Table, MFT). Es la estructura de datos más importante
de un sistema NTFS . Contiene información sobre los atributos de todos los archivos y directorios
existentes en el volumen.
•
A rchivos del sistema. Es un área de aproximadamente 1 MiB de tamaño donde se alojan archivos
cuyos clusters de datos contienen metadatos del sistema de archivos.
•
Á rea de datos de los archivos. Se utiliza para almacenar los valores de los atributos de un archivo
o directorio que por su tamaño no pueden ser almacenados en la MFT.
El sistema operativo Windows
345
Tabla de archivos maestra
Cada fila de la MFT se implementa mediante una estructura de datos denominada registro de archivo
(file record) que tiene un tamaño fijo de 1 KiB . Esta estructura contiene los atributos de un archivo o
un directorio. Por cada atributo se almacena una cabecera y el valor del atributo. Luego un registro de
archivo puede verse como una sucesión de pares (cabecera de atributo, valor de atributo).
Si el valor de un atributo ocupa mucho espacio entonces no puede ser contenido en un registro de
archivo de la MFT y se le debe asociar uno o más grupos de clusters en el área de datos de la partición.
A cada grupo de clusters en el área de datos asociado al valor de un atributo se le denomina serie (run)
o extensión. La cabecera del atributo contiene la información necesaria para localizar las series del valor
del atributo en la partición.
A un atributo cuyo valor se almacena completamente en la MFT se le denomina atributo residente,
en caso contrario se le denomina atributo no residente. Algunos atributos siempre son, por definición,
residentes. Este es el caso, por ejemplo, de la información estándar y del nombre del archivo. Otros
atributos serán residentes o no en función de su tamaño. Este es el caso, por ejemplo, del atributo datos
del archivo.
La cabecera de un atributo indica si el atributo es residente o no residente. Además para el caso de
un atributo residente la cabecera contiene también la longitud del atributo y el desplazamiento a partir
del comienzo de la cabecera donde comienza el valor del atributo. En el caso de atributos no residentes
la cabecera contiene la siguiente información por cada serie: número de cluster virtual del archivo Bv de
inicio de la serie, número de cluster lógico de la pattición BL de inicio de la serie y número de clusters
que ocupa la serie.
Cada archivo o directorio existente en el volumen, incluida la propia MFT, tiene asignado al menos
un registro de archivo en la MFT. A dicho registro se le denomina registro de archivo base. Si el archivo
contiene tantos atributos (o sus cabeceras ocupan mucho espacio) que no pueden almacenarse en un único
registro de archivo de la MFT entonces se le asigna un segundo registro de archivo para poder mantener
toda la información del archivo. Si con un segundo registro tampoco es suficiente se le asignará un tercer
registro, y así sucesivamente hasta poder acomodar toda la información sobre los atributos de un archivo
(o directorio).
Para localizar en que registro de archivo se encuentra cada atributo en el registro de archivo base se
añade un atributo denominado lista de atributos que contiene el nombre y código de cada uno de los
atributos del archivo y la referencia de archivo del registro de archivo de la MFT donde se encuentra
localizado el atributo.
La referencia del archivo es un identificador de 64 bits que se construye en función de la entrada k
(k = O, 1 , 2, 3 , . . . , 248 1 ) que ocupa el archivo en la MFT. Este identificador consta de dos campos: el
número de secuencia y el número de archivo. El número de secuencia ocupa los 16 bits más significativos
y es un contador que se incrementa cada vez que dicha entrada es reutilizada. Por su parte el número de
archivo ocupa los restantes 48 bits y codifica el índice k de la entrada.
La referencia de un archivo puede cambiar durante el tiempo de vida de un archivo, es decir, un
archivo bajo determinadas circunstancias puede ser movido de una entrada k a otra entrada h de la MFT.
La referencia de un archivo guarda cierta analogía con el número de nodo-i de los SOBUNIX.
-
346
Ampliación de sistemas operativos
1 KiB
Atributo
Atributo
información estándar nombre de archivo
Cabecera
Figura 8.12 -
Atributo datos
Valor
.
Estado del registro de archivo de la MFf asociado al archivo prueba txt del Ejemplo
8.6
1 KiB
Atributo
Atributo
información estándar nombre de archivo
1111
Fila 65
de la MFT
---- 1
225
1
1
226
1
2
227
1
3
228
Primera serie de datos
Figura 8.13 - Estado del
8.6
IJo llll
Alumnos.dat
o
1 --- - 1
Atributo datos
1
5
4
316
1
IJo
- -
Localización de
las series
1- - - -
- - - - - - - ·
:...
Bv
BL
N
o
225
4
4
316
2
Área de datos
de la partición
317
Segunda serie de datos
.
registro de archivo de la MFf asociado al archivo Alumno s da t del Ejemplo
El sistema operativo Windows
e
347
Ejemplo 8.6
En la Figura 8 . 1 2 se muestra el estado de un registro de archivo (fila 5 1 ) de la MFf asociado a un archivo
de nombre prueba . txt cuyos atributos están contenidos en su totalidad en el registro.
Por el contrario en la Figura 8 . 1 3 se muestra el estado de un registro de archivo (fila 65) de la MFf
asociado a un archivo de nombre Al urnn o s . da t cuyo atributos datos tiene un tamaño que ha requerido
almacenarlo en dos series de 4 y 2 clusters contiguos respectivamente del área de datos de la partición.
La primera serie está asociada a los 4 primeros clusters virtuales de datos del archivo (Bv = O, 1 , 2, 3)
y ocupa los clusters lógicos BL = 225 a BL = 228 de la partición. Por su parte, la segunda serie está
asociada a los dos últimos clusters virtuales de datos del archivo (Bv = 4, 5) que ocupan los clusters
BL = 3 1 6 y BL = 3 1 7 de la partición.
•
Archivos del sistema
El nombre de los archivos del sistema empieza con el carácter $ . Algunos ejemplos de archivos del
sistema son:
•
Espejo de la MFf ( $MFTM i r r ). Este archivo contiene por motivos de seguridad una copia de las
33 primeras filas de la MFf.
•
Archivo registro ( $ L o g F i l e ). Contiene un listado de las transacciones atómicas a realizar sobre el
sistema de archivos . Se mantiene para poder recuperar el estado del volumen en caso de fallo.
•
Tabla de definición de atributos ($AttrDe f). Esta tabla define los atributos de los archivos sopor­
tados en el volumen. Además establece si los atributos se pueden indexar para realizar búsquedas
o si se pueden recuperar durante una operación de recuperación del sistema.
•
Mapa de bits de los clusters del volumen ( $ B i tMap ) . El estado de un bit del mapa determina el
estado (libre o asignado) de un determinado cluster del volumen.
El área de arranque también se implementa como un archivo del sistema (archivo $Boot), pero a
diferencia del resto de archivos del sistema se ubica siempre al principio de la partición. También la
propia MFf se implementa como un archivo del sistema (archivo $MFT) que se ubica a continuación del
área de arranque.
Los 33 primeros registros de archivos de la MFf (filas O a 32) están reservadas para los archivos del
sistema. El archivo de la MFf ( $ MFT) tiene asignada la fila O, el archivo espej o de la MFf ( $ MFTMirr )
tiene asignada la fila 1 , al archivo registro ( $LogF i l e ) la fila 2, el archivo de la tabla �e definición de
atributos ($At t rDe f ) la fila 4, el directorio raíz ( \ ) la fila 5, el archivo del mapa de bits de los clusters
del volumen ( $ B i tMap ) la fila 6 y el archivo del sector de arranque ( $ B o o t ) la fila 7.
348
Ampliación de sistemas operativos
8. 7 .3.
Estructura de un directorio en NTFS
Cada directorio (al igual que cada archivo) definido en una partición de NTFS tiene asignado al
menos un registro de archivo en la MFf. El registro de archivo asociado a un directorio contiene (ver
Figura 8 . 14 ), aparte del atributo información estándar y nombre del archivo (directorio en este caso),
un atributo denominado raíz índice cuyo valor es una lista de las entradas del directorio. Cada entrada
del directorio consta de una parte de longitud fija y otra de longitud variable. La parte de longitud fija
almacena, entre otros datos, la referencia del archivo (o subdirectorio) en la MFf y la longitud del
nombre del archivo (o subdirectorio). La parte de la entrada del directorio de longitud variable se utiliza
para almacenar el nombre del archivo o subdirectorio.
Si un directorio contiene muchas entradas entonces parte de las entradas se almacenan en el atributo
índice raíz y el resto de entradas se almacenan en series en el área de datos. A las series que contienen
entradas de directorios se les denomina bu.ffers índices. En este caso se añade en el registro de archivo
base del directorio un atributo denominado asignación índice que contiene la información necesaria para
localizar los buffers índices en la partición. También se añade un atributo denominado Mapa de bits que
permite establecer que entradas en los buffers índices están libres y cuales ocupadas.
En el caso de directorios con muchas entradas en vez de mantener una lista se implementa un árbol­
B 10 con objeto de acelerar la gestión del directorio: realización de búsquedas e inserción de nuevas
entradas.
e
Ejemplo 8.7
En la Figura 8 . 1 4 se muestra el estado de un registro de archivo (fila 80) de la MFf asociado a un di­
rectorio de nombre F o t o s . Se observa que este directorio, de acuerdo con el valor de su atributo raíz
índice, consta de tres entradas. En cada entrada se almacenará información sobre un archivo o subdirec­
torio. Puesto que el número de entradas es pequeño se pueden almacenar en su totalidad en el registro de
archivo base y no ha sido necesario utilizar buffers índices.
l KiB
�1
Atributo
Atributo
información estándar Nombre archivo
Fil• 8
de la MFT
!f
Cabecera
Figura 8.14 - Estructura de
�
\
11
Valor
Fotos
Atributo
Raíz índice
1 1 t 1 1 1_-_-_-_-_-j
Entrada
del directorio
un registro de archivo en la MFf asociado a un directorio con pocas entradas
•
10Un árbol-B es una estructura de datos del tipo árbol binario de búsqueda [Cormen et al . , 2009].
El sistema operativo Windows
8. 7 4
.
.
349
Localización de archivos en un sistema NTFS
Cuando un proceso crea un nuevo archivo o abre un archivo ya existente debe introducir como ar­
gumento de entrada de la función Create F i l e de la API Win 32 el nombre de ruta del archivo. Dicha
ruta debe ser analizada componente a componente. Si la ruta es correcta cada componente contiene la
referencia de archivo del siguiente componente.
e
Ejemplo 8.8
Supóngase que para abrir el archivo
C : \ Fo t o s \ p l aya . j pg
un proceso ha invocado a la función CreateF i l e . El análisis de la ruta comienza en el directorio raíz
( \ ) del volumen C que recuérdese tiene asignado el registro de archivo 5 de la MFT. S e buscaría en el
atributo índice raíz del directorio raíz una entrada cuyo nombre coincida con F o t o s .
S i existe dicha entrada, entonces se lee l a referencia d e archivo del directorio \ Fo t o s l a cual apunta
al registro de archivo asociado a dicho directorio. Supóngase que se trata del registro de archivo 80. A
continuación se accede al atributo raíz índice de dicho registro de archivo en busca de una entrada que
contenga el nombre p l aya . j pg .
De nuevo, si existe dicha entrada, se lee la referencia de archivo del archivo e : \ Fo t o s \ p l aya . j pg
la cual apunta finalmente al registro de archivo asociado al archivo que se desea abrir. Supóngase, por
ejemplo, que se trata del registro de archivo 95 .
•
Si un archivo se crea o se abre correctamente se le asigna un objeto archivo cuyo descriptor es
devuelto al proceso que invocó a la función CreateF i l e de la API Win 32. El objeto archivo contiene
un puntero a una estructura de datos que depende del tipo de sistema de archivos (FAT, NTFS , etc). En
el caso de un sistema de archivos NTFS esta estructura se denomina bloque de control del flujo (Stream
Control Block, SCB). Existe un S CB por cada atributo de un archivo. Cada SCB contiene la información
necesaria poder localizar a un determinado atributo. El obj eto archivo apunta al SCB del atributo del
archivo que se desea leer o escribir.
Todos los SCB de un determinado archivo apuntan a una estructura denominada bloque de control
del archivo (File Control Block, FCB ) que, entre otros datos, contiene la referencia del archivo al que
está asociado la cual permite localizar el registro base del archivo en la MFT.
e
Ejemplo 8.9
En la Figura 8. 1 5 se muestran las estructuras de datos necesarias para poder implementar una operación
solicitada por un proceso sobre el fluj o de datos sin nombre (atributo datos) de un archivo perteneciente
a un sistema de archivos NTFS .
•
350
Ampliación de sistemas operativos
Tabla de descriptores (handles)
asociada a un proceso
Bloque de control
de fluj o (SCB)
Objeto archivo
---+
Atributo
Datos
Tabla de archivos
Maestra (MFT)
�
Bloque de control
del archivo (FCB)
Figura 8.15 -
Estructuras de datos del Ejemplo 8.9
Subsistema de E/S en el ejecutivo
Administrador
de E/S
Administrador
de PnP
:
._
Drivers
Administrador
de potencia
Tratamiento
de interrupciones en el
núcleo
i
HAL
;
Hardware
Figura 8.16 - Componentes
E/S.
de Windows que se ejecutan en modo núcleo encargados de la gestión de la
El sistema operativo Windows
8.8.
351
Gestión de E/S en Windows
La gestión de la E/S en Windows involucra a diferentes componentes del sistema operativo que se
ejecutan en modo núcleo (ver Figura 8 . 1 6): el subsistema de E/S, los drivers de dispositivos y las rutinas
de tratamiento de las interrupciones. En las siguientes secciones se describe como se implementan estos
componentes en Windows.
8.8.1.
Subsistema de E/S
El subsistema de E/ S de Windows se implementa mediante los siguientes componentes del ejecutivo:
•
Administrador de E/S . Es el componente central del subsistema de E/S. Se encarga de atender
las peticiones de E/S realizadas por las aplicaciones de los usuarios y el resto de componentes
del ejecutivo. Además define y soporta la interfaz de trabajo con los drivers. Más en detalle el
administrador de E/S se encarga de la realización, entre otras, de las siguientes tareas :
- Asignar a cada petición de E/ S una estructura de datos denominada paquete de petición de
E/S (1/0 Request Packet, IRP) que contiene toda la información que necesita conocer el
subsistema para procesar la petición.
- Invocar al driver adecuado. El administrador de E/S cuando invoca un driver para realizar una
determinada operación le pasa su IRP correspondiente. Asimismo cuando el driver termina de
realizar la operación solicitada modifica adecuadamente el IRP y se lo envía al administrador
de E/ S para que proceda a completar la petición o se la pase a otro driver.
- Asignar a cada driver que se carga en el sistema un objeto driver e invocar a la rutina de
inicialización del driver que rellena los atributos del objeto con los puntos de entrada del
driver. Un punto de entrada es la dirección de comienzo de una rutina del driver.
- Proporcionar rutinas comunes que pueden ser invocadas por los drivers. Por ejemplo una
rutina para interactuar con el controlador de DMA, una rutina para invocar a otros drivers,
una rutina para solicitar buffers de E/ S, etc.
•
Administrador de PnP. Se encarga de detectar la conexión o desconexión de dispositivos de E/S
en el computador. Cuando el administrador de PnP detecta que se ha conectado un dispositivo
entonces se encarga de cargar el driver apropiado.
•
Administrador de potencia. Se encarga de gestionar el consumo de energía de los componentes
hardware del computador.
Estos componentes del ejecutivo de Windows para realizar sus tareas trabajan estrechamente con los
drivers de los dispositivos. En el registro de Windows se almacena una descripción de los dispositivos de
E/S existentes en el computador así como la información necesaria para la inicialización y configuración
de los drivers de dichos dispositivos.
352
Ampliación de sistemas operativos
8.8.2.
Drivers de dispositivos en Windows
De forma general los drivers de dispositivos usados en Windows se pueden descomponer en dos
grandes categorías : los drivers que se ejecutan en modo usuario y los drivers que se ejecutan en modo
núcleo. Ejemplos de drivers de Windows que se ejecutan en modo usuario son por ejemplo los drivers de
dispositivos virtuales que se utilizan para emular aplicaciones de 1 6 bits de MS-DOS y los drivers de las
impresoras del subsistema Windows.
Los drivers que se ejecutan en modo núcleo se pueden clasificar en las siguientes categorías [Russi­
novich et al. , 2009] :
•
Drivers de sistemas de archivos. Un driver de un sistema de archivos atiende las peticiones de E/ S
sobre un determinado tipo de sistema de archivos. Por ejemplo el driver nt f s . sys atiende las
peticiones de E/S sobre los sistemas NTFS .
•
Drivers PnP. Son drivers que trabaj an en colaboración con el administrador de PnP y el adminis­
trador de potencia.
•
Drivers no PnP. Son drivers no asociados a ningún dispositivo hardware que extienden la funcio­
nalidad del sistema operativo. Ejemplos de drivers no PnP son los drivers que se utilizan para el
soporte de los diferentes protocolos de red.
Otra posible clasificación de los drivers proviene del modelo de drivers de Windows (Windows Driver
Model, WDM) establecido por Microsoft, que proporciona a los programadores las especificaciones
que debe cumplir un driver para funcionar correctamente en Windows. De acuerdo con este modelo se
distinguen tres tipos de drivers [Russinovich et al. , 2009] :
•
Drivers de bus. Gestionan buses físicos o lógicos. Se encargan de detectar e informar al adminis­
trador de PnP de los dispositivos que se encuentran conectados a los buses. También se encargan
de controlar y configurar el consumo de energía de los buses. Microsoft proporcionan drivers de
bus para los tipos de buses más comunes : PCI, PnPISA, SCSI, USB and FireWire. Aunque si lo
desean los programadores pueden escribir sus propios drivers de bus.
•
Drivers de función. Un driver de función es el driver principal de un dispositivo ya que es el que
más información contiene sobre el funcionamiento de un determinado dispositivo y el que accede
propiamente al mismo. Este tipo de drivers suelen ser escritos por el fabricante del dispositivo.
•
Drivers de filtro. Son drivers opcionales que se utilizan para añadir alguna funcionalidad o modi­
ficar el comportamiento de un dispositivo o de otro driver.
Se observa que en el WDM cada tipo de driver (bus, función o filtro) se encarga de realizar una
tarea muy específica. Con este reparto de tareas se pretende simplificar la escritura de los drivers a los
programadores. Puesto que Microsoft proporciona drivers de buses y como los drivers de filtros son
opcionales, los programadores únicamente tienen que concentrarse en escribir bien el driver de función
de un determinado dispositivo.
El sistema operativo Windows
353
En Windows es común que una petición de E/ S requiera de la ejecución de varios drivers. El subsis­
tema de E/S se encarga de invocar al primer driver necesario para realizar una determinada tarea. Dicho
driver puede que requiera invocar a otro driver, para ello debe utilizar alguna función proporcionada por
el administrador de E/S .
e
Ejemplo 8.10
Supóngase que un hilo de un proceso de usuario ha invocado a la función Wr i t e F i l e de la API Win32
para escribir en un determinado archivo. Los argumentos de entrada de esta función son, entre otros,
los siguientes : el manej ador del archivo, el número de bytes a escribir, el buffer donde se encuentran
aloj ados los datos a escribir, y el desplazamiento medido en bytes desde el comienzo del archivo donde
se escribirán los bytes. Dicha función invoca a la llamada al sistema NtWr i t eF i l e que al ser atendida
por el ejecutivo produce que se invoque al administrador de E/ S . É ste a su vez invoca al driver del sistema
de archivos al que pertenece al archivo, por ejemplo si es un sistema NTFS al driver n t f s . sys . Este
driver traduce el desplazamiento en bytes relativo al comienzo del archivo en un desplazamiento en bytes
relativo al comienzo del volumen. Entonces pasa esta información mediante el administrador de E/S al
driver de disco. Este driver traduce esta posición lógica en una posición física y se comunica con el disco
para escribir los datos en el disco.
•
Cuando se carga un driver el administrador de E/S le asigna un objeto driver. Además invoca a la
rutina de inicialización del driver que rellena los atributos del objeto con los puntos de entrada del driver.
También crea un objeto dispositivo por cada dispositivo que controla dicho driver. Un objeto dispositivo
Objeto driver
,...
Función Read
Función Write
Función Ioctl
�
__.
_.
......
Código del driver cargado
en memoria princip al
Objeto
dispositivo
1
Figura 8.17 -
__.
Obj eto
dispositivo
1
Relación entre un objeto driver y sus objetos dispositivos asociados
354
Ampliación de sistemas operativos
es un objeto que representa y contiene información sobre un determinado dispositivo físico o lógico en
el sistema.
Todos los objetos dispositivos asociados a un determinado driver son organizados en una lista (ver
Figura 8 . 17). El objeto driver contiene un puntero al comienza de su lista de objetos dispositivos. Además
cada obj eto dispositivo contiene un puntero al objeto driver que lo controla.
Cuando el administrador de E/S recibe una petición de E/S sobre un determinado dispositivo con­
sulta el objeto dispositivo asociado a dicho dispositivo para obtener la dirección del objeto driver que
controla al dispositivo. Entonces accede al objeto driver para obtener el punto de entrada de la función
del driver que implementa la operación que se requiere realizar sobre el dispositivo y le pasa como ar­
gumento el IRP que contiene la información sobre la operación a realizar. Cuando el driver termina de
realizar la operación solicitada modifica adecuadamente el IRP y se lo envía al administrador de E/S
para que proceda a completar la petición o se la pase a otro driver.
8.8.3.
Gestión de interrupciones en Windows
Niveles de petición de interrupción
En Windows la gestión de las interrupciones se implementa en el núcleo. Éste prioriza la atención
de las interrupciones asignando a cada tipo de interrupción una prioridad denominada nivel de petición
de interrupción (lnterrupt Request Level, IRQL) que es un número entero positivo comprendido en el
rango [0, N] . El valor de N depende de cada arquitectura. Por ejemplo en la arquitectura Intel x86 N=3 1 ,
mientras que en las arquitecturas AMD x64 e Intel IA64 N= 1 5 .
Cuanto mayor e s e l valor del IRQL de una interrupción mayor e s s u prioridad, luego e l nivel de
prioridad de interrupción más alto corresponde a IRQL=N.
Asimismo el nivel de prioridad de interrupción más baj o corresponde a IRQL=O. A este nivel se le
denomina nivel pasivo y no está asociado a ningún tipo de interrupción sino que es el nivel de prioridad
asignado a la ejecución normal de los hilos tanto en modo núcleo como en modo usuario.
e
Ejemplo 8.1 1
E n la arquitectura Intel x86 Windows distingue 3 2 niveles de petición de interrupción. E l nivel más
prioritario es IRQL=3 1 que está asignado a la ejecución de la rutina del núcleo KeBugChec kEx ( ) , la
cual es invocada cuando se detecta una inconsistencia irrecuperable que podría corromper el sistema.
El siguiente nivel, IRQL=30, se asigna a interrupciones asociadas a un fallo de potencia. El nivel
IRQL=29 se asigna a interrupciones usadas para implementar la comunicación entre procesadores. El
reloj del sistema es atendido con un nivel IRQL=28. El nivel IRQL=27 se reserva para la implementa­
ción del perfil del núcleo, un mecanismo de medida del comportamiento del sistema.
Los dispositivos hardware tienen asignado un nivel IRQL comprendido dentro del rango [3, 26] . Los
niveles IRQL= l e IRQL=2 están reservados para las interrupciones software. Mientras que el IRQL=O,
es el nivel pasivo.
•
El sistema operativo Windows
355
Supóngase que se está ejecutando un hilo H l en modo usuario con IRQL=O y llega una interrupción
1 1 con un nivel IRQL=h. Entonces se produce una conmutación de modo usuario a modo núcleo y
se almacena el contexto hardware del hilo en un marco de su pila del núcleo asociada para que pueda
continuarse con su ejecución una vez finalizado el tratamiento de la interrupción y si no existe un hilo más
prioritario. A continuación el flujo de control se transfiere a un manipulador general de interrupciones
que identifica la interrupción que se ha producido, eleva el nivel de prioridad del procesador al valor
IRQL=h e invoca a la rutina especifica de tratamiento de la interrupción 1 1 .
Nótese que al elevar el nivel de prioridad de un procesador al valor IRQL=h todas las interrupciones
con IRQL::; h quedan bloqueadas (enmascaradas) en dicho procesador. Un interrupción con IRQL=k
con k < h no será atendida hasta que el nivel de prioridad del procesador sea configurado por debajo de
k.
Por otra parte, si mientras se está ejecutando la rutina de tratamiento de 1 1 con IRQL=h llega una
interrupción 12 con IRQL=p, con p > h, entonces se eleva el nivel de prioridad del procesador al valor
p, se guarda el contexto hardware de la rutina de tratamiento de 1 1 , y comienza a ejecutarse la rutina
de tratamiento de 12. Cuando esta rutina se complete entonces el nivel de prioridad del procesador se
reducirá de nuevo al valor h, y se continuará con la ejecución de la rutina de tratamiento de 1 1 .
Interrupciones software generadas por el sistema operativo
Aunque el hardware es la principal fuente de interrupciones, el sistema operativo también puede
generar interrupciones. En este caso se trata de interrupciones software las cuales tienen asignado los
niveles de petición de interrupción IRQL= 1 e IRQL=2. Entre las principales causas que producen que
Windows genere una interrupción software se encuentran las siguientes :
•
Llamadas a procedimientos asíncronos (Asynchronous Procedure Call, APC). Una APC es un
mecanismo que permite ejecutar un determinado código de una aplicación o del propio sistema
operativo en el contexto de un determinado hilo, es decir, dentro de un determinado espacio de
direcciones. Se distinguen dos tipos de APCs:
- APCs en modo núcleo. Se caracterizan porque para ser ejecutadas no requieren el permiso del
hilo en cuyo contexto desean ser ejecutados. Son utilizadas por los componentes del ejecutivo
de Windows para realizar aquellas tareas que requieren ser completadas en el contexto de un
determinado hilo, como por ejemplo suspender o terminar un determinado hilo.
- APCs en modo usuario. Se caracterizan porque para ser ejecutadas requieren el permiso
del hilo en cuyo contexto desean ser ejecutados . Diferentes funciones de la API Win 32
utilizan APCs en modo usuario. Por ejemplo la función ReadF i l eEx permite al hilo que la
invoca especificar la rutina que debe ser ejecutada cuando la operación de lectura solicitada
se complete.
Una APC se describe mediante un objeto del núcleo denominado objeto APC. Las APCs que se
encuentran a la espera de ser ejecutados residen en una cola APC gestionada por el núcleo. Existe
una cola APC por cada hilo. Cada vez que el núcleo inserta un objeto APC en la cola APC de
356
Ampliación de sistemas operativos
un hilo genera una interrupción software asociada al APC con un IRQL= l . Cuando el hilo es
planificado para ser ejecutado en primer lugar se ejecutan las interrupciones software asociados a
las APCs que tenga en su cola.
•
Llamadas a procedimientos aplazados (Deferred Procedure Call, DPC). Una DPC es una función
que implementa una tarea del sistema cuya ejecución puede ser aplazada hasta completar la tarea
actual. Las DPC proporcionan al sistema operativo la capacidad de generar una interrupción y
ejecutar una determinada función del sistema en modo núcleo. El núcleo utiliza DPCs para repla­
nificar el procesador después de que el cuanto de un hilo ha expirado. Los drivers utilizan DPCs
para completar peticiones de E/ S .
Una DPC s e describe mediante u n obj eto del núcleo denominado objeto DPC. Las DPCs que se
encuentran a la espera de ser ejecutados residen en una cola DPC gestionada por el núcleo. Existe
una cola DPC por cada procesador. El núcleo cada vez que inserta un objeto DPC en la cola DPC de
un procesador genera una interrupción software con IRQL=2. Cuando el IRQL de un procesador
cae por debajo del valor IRQL=2 entonces se comienzan a ejecutar las DPCs existentes en la cola
DPC de dicho procesador.
8.9.
Resumen
Windows de Microsoft es un sistema multiprogramado y multitarea, con soporte para multiprocesa­
miento. Consta de diversos componentes software, algunos de los cuales (procesos de servicios, procesos
del sistema, aplicaciones, librerías DLL y subsistemas de entorno) se ejecutan en modo usuario, mientras
que otros (capa HAL, drivers de dispositivos, GUI, núcleo y ejecutivo) se ejecutan en modo núcleo.
En Windows a las llamadas al sistema se les denomina servicios del sistema. Las funciones de envol­
tura de las llamadas al sistema de Windows se encuentran en la librería ntdl l . dl l . Microsoft ha pu­
blicado muy poca información sobre las funciones de esta librería, por lo que es difícil trabaj ar con ellas
directamente. El acceso a las funciones de la librería ntdl l . dl l , es decir, la invocación de llamadas al
sistema, se realiza de forma indirecta a través de las funciones de las librerías DLL que implementan las
APis soportadas por Windows, las cuales si están bien documentadas.
Windows implementa un modelo de proceso multihilo con un hilo del núcleo por cada hilo de usua­
rio. Existen varias funciones en la API Win32 que permiten crear un proceso, aunque sin duda la más
conocida y utilizada es la función C r e a t e Pro c e s s de la librería kerne l 3 2 . dl l . Por otra parte un hilo
de un proceso puede crear otro hilo dentro del mismo proceso invocando a la función Crea t eThread.
Windows es un sistema operativo de núcleo expropiable que utiliza como unidad de planificación a
los hilos del núcleo. Windows implementa un algoritmo de planificación de tipo expropiativo basado en
múltiples colas de prioridad y realimentación. Se consideran 32 niveles de prioridad comprendidos dentro
del rango [0, 3 1 ] , siendo O la prioridad más baj a posible y 3 1 la más alta. Estos 32 niveles son divididos
en dos grupos : niveles de tiempo real y niveles dinámicos. Los niveles de tiempo real comprenden los
16 niveles más prioritarios, es decir, los niveles de prioridad en el rango [ 1 6, 3 1 ] . Windows asigna estos
niveles de prioridad a los hilos del núcleo asociados a tareas críticas del sistema, como por ejemplo:
El sistema operativo Windows
357
la gestión de la memoria, la gestión de la caché, etc. Los niveles dinámicos comprenden los niveles de
prioridad en el rango [ 1 , 1 5 ] . En estos niveles se ejecutan la mayoría de los procesos de lo usuarios.
Windows para garantizar la exclusión mutua en el uso de las secciones críticas del código del sistema
operativo utiliza principalmente spinlocks. Otros mecanismos de sincronización disponibles en Windows
son los semáforos, los semáforos binarios o mutexes, y los eventos. Estos mecanismos pueden ser utili­
zados tanto por los propios componentes de Windows como por los hilos de los procesos de los usuarios.
Windows también implementa diversos mecanismos de comunicación entre procesos multihilos: tube­
rías, conectores, mailslots, llamadas a procedimientos remotos, obj etos compartidos, etc.
Windows utiliza la técnica de demanda de página para administrar la memoria principal. Todas las
tareas relativas a la administración de memoria son realizadas por el administrador de memoria que es
uno de los servicios que ocupa una mayor parte del código del ejecutivo de Windows, lo que da idea de
la complejidad del mismo.
Para gestionar la memoria física Windows utiliza el conjunto de trabajo de un proceso el cual queda
definido por las páginas pertenecientes al proceso cargadas en memoria que pueden ser referenciadas sin
producir un fallo de página. El tamaño y la composición del conjunto de trabajo de un proceso varían
durante el tiempo de vida del proceso.
Cada sistema de archivos presente en memoria secundaria es tratado por Windows como una unidad o
volumen lógico independiente, cada una de los cuales posee su propia estructura de directorios. Windows
asigna una letra (C, D, E, . . . ) a cada unidad. El nombre de ruta de un archivo comienza por tanto con el
nombre del volumen lógico en el que está almacenado.
Existen varias funciones en la API Win32 asociadas a la gestión de archivos, entre las funciones
más conocidas se encuentran las siguientes : CreateF i l e , De l e t eF i l e , C l o s eHandl e , ReadF i l e y
Wr i t eF i l e .
Las versiones modernas d e Windows cuando s e instalan e n una partición d e disco crean u n sistema
de archivos principal de tipo NTFS . Aparte de NTFS Windows también soporta sistemas de archivos
CDFS , UFS , FAT 1 2, FAT 1 6, FAT32 y extFAT. Para interactuar con un determinado tipo de sistema de
archivos, el gestor de E/ S invoca al driver del sistema de archivos correspondiente.
El sistema de archivos NTFS fue desarrollado a mediados de los noventa para ser el sistema de
archivos principal de Windows NT. Este sistema de archivos presenta, entre otras, las siguientes caracte­
rísticas: la unidad básica de asignación de espacio es el cluster, toda información contenida en un sistema
de archivos se estructura en archivos, un archivo (o un directorio) consiste de múltiples flujos de bytes,
un archivo puede constar de múltiples flujos de datos, un nombre de archivo puede tener una extensión
máxima de 255 caracteres, los nombres se codifican en código Unicode, implementa una estructura de
directorios de gráfica acíclica con soporte de enlaces duros y enlaces simbólicos, posibilidad de recupe­
ración del sistema, registro por diario, soporte de cuotas, compresión y encriptación.
Un sistema de archivos NTFS presenta la siguiente estructura en la partición de disco donde se crea:
área de arranque, tabla de archivos maestra, archivos del sistema, área de datos de los archivos. La tabla
de archivos maestra es la estructura de datos más importante de un sistema NTFS . Contiene información
sobre los atributos de todos los archivos y directorios existentes en el volumen. Por su parte los archivos
del sistema son archivos cuyos clusters de datos contienen metadatos del sistema de archivos.
358
Ampliación de sistemas operativos
El administrador de E/S es el componente central del subsistema de E/ S de Windows. Se encarga de
atender las peticiones de E/S realizadas por las aplicaciones de los usuarios y el resto de componentes
del ejecutivo. Además define y soporta la interfaz de trabajo con los drivers.
8.10.
Lecturas recomendadas
Si se desea obtener una explicación adicional de los contenidos tratados en este capítulo se pueden
consultar, por ejemplo: el capítulo 1 1 de [Tanenbaum, 2009] y el libro [Russinovich et al. , 2009] .
Asimismo para obtener una descripción detallada del uso de las funciones de la API Win 32 apare­
cidas en este capítulo se puede consultar los libros [Richter y Nasarre, 2007] y [Hart, 20 1 0] . También se
puede consultar la librería MSDN (www . msdn . mi c ro s o f t . c om) .
8.11.
Autoevaluación
8.1. Enumerar las características principales del sistema operativo Windows. (Respuesta en sección 8 .2.2)
8.2. Dibujar un diagrama adecuadamente rotulado de la estructura del sistema operativo Windows.
Comentar brevemente cada uno de sus componentes. (Respuesta en sección 8 .2.3)
8.3. ¿Qué es la API Win32? Comentar algunas de las librerías DLL que implementan la funcionalidad
de la API. (Respuesta en sección 8.2.4)
8.4. Explicar las acciones que pueden producirse cuando se invoca a una función de una librería DLL.
(Respuesta en sección 8 .2.4)
8.5. Explicar la implementación de la interfaz con el usuario de Windows. (Respuesta en sección 8 .2.5)
8.6. Explicar cómo se invocan y el tratamiento de las llamadas al sistema en Windows.
(Respuesta en sección 8.2.6)
8.7. ¿Qué es el registro de Windows ? ¿Cómo se implementa? ¿Quién puede acceder al registro?
(Respuesta en sección 8.2.7)
8.8. ¿Qué son los objetos del núcleo? ¿Cómo se implementan? ¿Quién se encarga de gestionarlos?
(Respuesta en sección 8.2.9)
8.9. Explicar qué es el identificador de un objeto y para qué se utiliza. (Respuesta en sección 8.2.9)
8.10. Enumerar y comentar brevemente los mecanismos de seguridad disponibles en Windows NT.
(Respuesta en sección 8.2. 1 0)
8.11. Enumerar y comentar brevemente las estructuras de datos utilizadas en Windows para implementar
la seguridad. (Respuesta en sección 8.2. 1 0)
El sistema operativo Windows
359
8.12. Describir la implementación de los procesos multihilos en Windows. (Respuesta en sección 8 .3 . 1 )
8.13. Dibujar un diagrama, adecuadamente rotulado, con las principales estructuras d e datos mantenidas
por Windows para implementar un proceso multihilo que conste de dos hilos. Explicar brevemente
la utilidad de cada una de las estructuras que aparezcan en el diagrama. (Respuesta en sección 8 .3 . 1 )
8.14. Dibujar el diagrama de transición de estados d e u n hilo en Windows. (Respuesta e n sección 8 . 3 .2)
8.15. Explicar la creación de procesos e hilos en Windows. (Respuesta en sección 8 . 3 .2)
8.16. Dibujar un diagrama, adecuadamente rotulado, con los niveles de prioridad definidos en Windows.
(Respuesta en sección 8 . 3 . 3 )
8.17. Describir las prioridades asociadas a u n proceso o a u n hilo e n Windows.
(Respuesta en sección 8 . 3 . 3 )
8.18. Describir l a implementación y la gestión d e las colas d e prioridad e n Windows .
(Respuesta e n sección 8 . 3 . 3 )
8.19. Explicar l a duración d e u n cuanto e n Windows . (Respuesta en sección 8 . 3 . 3 )
8.20. Describir la estructura y la invocación del planificador de Windows. (Respuesta en sección 8 . 3 . 3 )
8.21. Explicar el objetivo y las circunstancias bajo las cuales Windows aumenta temporalmente la prio­
ridad actual de un hilo. (Respuesta en sección 8 . 3 .3)
8.22. Describir los mecanismos de sincronización utilizados por Windows. (Respuesta en sección 8 .4. 1 )
8.23. Describir los mecanismos d e sincronización entre procesos multihilos disponibles e n Windows.
(Respuesta en sección 8 .4.2)
8.24. Describir los mecanismos de comunicación entre procesos multihilos disponibles en Windows.
(Respuesta en sección 8.4.3)
8.25. Explicar la implementación del administrador de memoria de Windows. (Respuesta en sección 8 . 5 .2)
8.26. Explicar la gestión de la memoria virtual en Windows. (Respuesta en sección 8 . 5 .2)
8.27. Describir la traducción de direcciones en Windows. (Respuesta en sección 8 . 5 . 3 )
8.28. Describir el uso que hace Windows del concepto de conjunto de trabajo de un proceso. (Respuesta
en sección 8 . 5 .4)
8.29. ¿Qué es la base de datos de los números de marcos de página? ¿En que posibles estados puede
encontrarse un marco de página? (Respuesta en sección 8 . 5 .4)
8.30. Dibujar un diagrama adecuadamente rotulado con las transiciones entre las listas de marcos de
página definidas en Windows. Explicar el diagrama dibujado. (Respuesta en sección 8 . 5 .4)
360
Ampliación de sistemas operativos
8.31. ¿Qué son los archivos de páginas? (Respuesta en sección 8.5 .5)
8.32. Enumerar diez funciones de la API Win32 disponibles para la gestión de archivos y directorios en
Windows (Respuesta en sección 8.6. 1 )
8.33. Explicar el tratamiento que realiza Windows de los diferentes sistemas de archivos existentes en la
memoria secundaria. (Respuesta en sección 8.6.2)
8.34. Enumerar y comentar las características principales de un sistema de archivos NTFS .
(Respuesta en sección 8.7. 1 )
8.35. Explicar la estructura en disco que presenta u n sistema de archivos NTFS .
(Respuesta en sección 8.7.2)
8.36. Describir la implementación de la tabla de archivos maestra. (Respuesta en sección 8.7 .2)
8.37. Enumerar algunos ejemplos de archivos del sistema. (Respuesta en sección 8.7 .2)
8.38. Explicar la estructura de un directorio en un sistema de archivos NTFS . (Respuesta en sección 8.7.3)
8.39. Explicar la localización de archivos en un sistema de archivos NTFS . (Respuesta en sección 8.7.4)
8.40. Describir la implementación del subsistema de E/S en Windows . (Respuesta en sección 8 . 8 . 1 )
8.41. Explicar qué es un driver de sistema de archivos, un driver PnP y un driver no PnP.
(Respuesta en sección 8 . 8 .2)
8.42. Explicar los tipos de drivers que se distinguen de acuerdo con el modelo WDM.
(Respuesta en sección 8.8 .2)
8.43. Dibujar un diagrama adecuadamente rotulado que ilustre la relación entre un objeto driver y sus
obj etos dispositivos asociados. Explicar la interacción del administrador de E/S con estos objetos.
(Respuesta en sección 8 . 8 .2)
8.44. Explicar cómo se gestionan las interrupciones en Windows. (Respuesta en sección 8 . 8 . 3 )
8.45. Explicar qué son y cómo se gestionan las llamadas a procedimientos remotos ¿Qué tipos se distin­
guen? (Respuesta en sección 8 . 8 . 3 )
8.46. Explicar qué son y cómo se gestionan las llamadas a procedimientos aplazados.
(Respuesta en sección 8 . 8 . 3 )
El sistema operativo Windows
8.12.
361
Ejercicios
8.1. En un sistema Windows una cierta aplicación está implementada como un proceso monohilo.
Supuesto que dicho proceso tiene asociada la clase de planificación alta y que la prioridad relativa
del hilo está configurada al valor debajo de normal determinar:
a) La prioridad base del proceso.
b) La prioridad base del hilo.
e) La prioridad actual del hilo.
8.2. Supóngase que en un cierto sistema Windows existen dos volúmenes C y D de tipo NTFS, y que
el volumen de trabajo actual es el volumen D. Explicar el significado de las siguientes órdenes del
intérprete cmd . exe :
a) mkl i nk / h en l a c e l . txt \ t rabaj o \ l i s t ado . txt
b) mkl i nk /d f o t o s C : \ imagene s \ f o t o s \ camara
8.3. Diseñar en el intérprete cmd . ex e de Windows un ejemplo que ilustre que un archivo en NTFS
puede constar de múltiples flujos de datos.
8.4. En un volumen NTFS un cierto archivo consta de 10 clusters virtuales (Bv = O, 1, . . . , 9) los cuales
se encuentran almacenados en los siguientes clusters lógicos BL: 6 1 , 62, 63, 90, 9 1 , 92, 93, 85, 86
y 1 1 2. Determinar la información relativa a la localización de las series del atributo de datos del
archivo que se almacena en la entrada asociada al archivo en la MFT del volumen.
8.5. El proceso de compresión de un archivo en un sistema NTFS es el siguiente: primero se aplica
el algoritmo de compresión sobre los 16 primeros clusters virtuales del archivo, si el resultado de
la compresión se puede almacenar en menos de 16 cluster lógicos, entonces los clusters virtuales
comprimidos se escriben en el disco, a ser posible en una única serie. Si el resultado de la compre­
sión ocupa 16 clusters entonces los clusters se almacenan sin comprimir en el disco en una única
serie, si es posible. A continuación se repite el análisis con los siguientes 16 clusters virtuales
del archivo, y así sucesivamente hasta analizar todos los clusters virtuales. Supóngase un cierto
archivo cuyos datos ocupan 48 clusters virtuales. Los primeros 16 clusters virtuales han podido
ser comprimidos en una serie de 8 cluster lógicos contiguos, la dirección del primer cluster lógico
de la serie es BL = 40. Los siguientes 1 6 clusters virtuales no han podido ser comprimidos y se
han almacenado en una serie de 16 cluster lógicos contiguos, la dirección del primer cluster lógico
de la serie es BL = 50. Finalmente los últimos 16 clusters virtuales han podido ser comprimidos
en serie de ocho clusters lógicos contiguos, la dirección del primer cluster lógico de la serie es
BL = 95. Determinar la información relativa a la localización de las series del atributo de datos del
archivo que se almacena en la entrada asociada al archivo en la MFT del volumen NTFS .
8.6 Realizar una búsqueda en Internet sobre las herramientas software disponibles para analizar el
funcionamiento y el rendimiento del sistema operativo Windows.
Apéndice A
Soluci ones completas de los ej erci cios
A.l.
Soluciones ejercicios capítulo 1
Solución Ejercicio 1.1
a) Para visualizar la ruta absoluta del directorio de trabaj o actual se debe escribir la orden
pwd
b) Para visualizar un listado del contenido del directorio de trabajo actual que permita diferenciar
entre archivos y directorios se puede escribir la orden
ls
-
ls
-1
F
También se podría usar la orden
e) Para visualizar un listado que únicamente contenga los nombres de los archivos que acaban con la
1
1
1
1
letra o o con la letra t se debe escribir la orden
l s * [ ot ]
d) Para mover al subdirectorio f o t o s los archivos da t o s y f o t o smu l se debe escribir la orden
mv da t o s f o t o smu l f o t o s
e ) Para hacer que e l directorio f o t o s pase a ser e l directorio d e trabajo actual se debe escribir la
orden
cd f o t o s
363
364
Ampliación de sistemas operativos
Solución Ejercicio 1.2
a) Esta orden ordena ( s o r t ) por orden alfabético las líneas del archivo fA y escribe el resultado en
el archivo fB.
b) Esta orden almacena en el archivo asd el resultado de la orden ls 1 que genera un listado largo
de los archivos del directorio de trabajo incluyendo tamaño, permisos, propietario, permisos, etc.
Si el archivo asd no existe se crea. Si el archivo ya existe se eliminará su contenido y se remplazará
por la salida de la orden l s - l .
-
,
e) Esta orden almacena en el archivo wer t 2 3 el resultado de l a orden l s - i , que genera un listado
largo de los archivos del directorio de trabajo mostrando en la primera columna el número de
nodo-i de cada archivo. Si el archivo wer t 2 3 no existe se crea. Si el archivo ya existe, la salida de
la orden l s - i se añade a partir del final del archivo.
d) Esta orden muestra en la pantalla el contenido del archivo prueba . txt ubicado en el directorio
de trabaj o inicial. Señalar que el nombre de ruta del archivo especificado en esta orden hace uso
del comodín tilde ' � ' el cual sustituye al nombre de ruta absoluta ( / home o /us ers) del directorio
que contiene los directorios de trabajo de todos los usuarios. Si se utiliza en la forma 1 entonces
hace referencia al nombre de ruta absoluta del directorio de trabajo inicial del usuario.
11
�
11
Por lo tanto supuesto, por ejemplo, que el directorio de trabaj o inicial del usuario que invoca
esta orden es / home / j o s erna entonces la orden propuesta expandiendo el comodín tilde sería
equivalente a
mo re / home / j o s ema / prueba . txt
e) Esta orden copia los archivos par t epr imera y par t e s egunda en el directorio traba j o . Señalar que la orden hace uso del comodín llaves { c adl , c ad2 , . . . , cadN } el cual expande una
palabra por cada una de las cadenas de caracteres cadj j = 1 , . ,N incluidas dentro de las llaves.
11
11
.
.
Solución Ejercicio 1.3
a) Se puede usar por ejemplo el comando
c a t / e t c / she l l s
b) S e puede usar por ejemplo el comando
where i s bash
También se podría usar el comando loca t e bash o el comando whi ch bash.
e) Se puede visualizar el valor de la variable de entorno SHELL:
Soluciones completas de los ejercicios
365
echo $ SHELL
Si estamos usando el intérprete bash se mostrará en pantalla un mensaj e similar a
/ b i n / bash
d) Se puede visualizar el valor de la variable del intérprete BASH_VERSION:
echo $ BASH_VERS I ON
e) En bash existen definidas diferentes variables especiales, entre las más utilizadas se encuentran
las siguientes:
•
$ ? . Contiene el estatus de salida del último comando ejecutado por bash. El estatus de sa­
lida de un comando es un valor entero positivo pequeño que éste devuelve cuando finaliza.
Como regla general se suele considerar que si el estatus de salida es igual a O entonces el
comando se ha ejecutado con éxito, mientras que si es igual a 1 entonces se ha producido al­
gún error. También se pueden devolver otros valores distintos, de acuerdo con algún criterio
prestablecido por el programador. El comando exi t permite especificar el valor del estatus
de salida.
•
$ $. Contiene el PID del proceso que implementa el intérprete.
•
$ ! . Contiene el PID del proceso asociado al último comando que fue ejecutado en segundo
plano por el intérprete.
•
$ o . Contiene la cadena de caracteres asociada al nombre del shell script que se está ejecutan­
do actualmente en el intérprete.
•
$ # . Contiene una cadena de caracteres con el número de argumentos de entrada del shell
script o la función.
•
$ * . Contiene los argumentos de entrada del shell script o función. Se suele utilizar en los
bucles f or.
•
$ i . Con i
=
1, 2, 3 , . . . , 9 contiene la cadena de caracteres asociada al argumento i-ésimo de
entrada del shell script que se está ejecutando actualmente.
f) La sustitución de comandos permite usar la salida de un comando como si fuese el valor de una
variable. En bash esto se consigue de la siguiente forma:
$ ( c omando )
Por ejemplo la orden D I R = $ ( pwd ) almacena en la variable D I R la salida del comando pwd el cual
muestra el nombre de ruta del directorio de trabaj o actual.
Otra forma de implementar la sustitución de comandos es entrecomillando el comando con acentos
graves :
366
Ampliación de sistemas operativos
' c omando '
Luego la orden DIR= ' pwd ' es equivalente a DIR= $ ( pwd ) .
g) En bash una cadena de caracteres entrecomillada con comillas dobles, " c adena " , es analizada por
el intérprete en busca de comandos que deban ser sustituidos o caracteres que deban ser expandi­
dos. Por ejemplo, supuesto que en el directorio de trabaj o actual existe el archivo s c r ip t l . sh
que contiene 78 palabras entonces la orden
echo " N º pa l abras = $ ( wc -w s c r ip t l . sh ) "
produce la siguiente salida en la pantalla:
Nº palabras = 7 8 s c r i p t l . sh
Por el contrario, una cadena de caracteres entrecomillada con comillas simples, 'c adena', no es
analizada por el intérprete. Por ejemplo, la orden
echo ' N º pa l abras = $ ( wc -w s c r i p t l . sh ) '
genera la siguiente salida en la pantalla:
Nº pa l abras = $ ( wc -w s c r i p t l . sh )
h) En bash l a introducción de datos desde el teclado se consigue usando la orden read. Por ejemplo,
la orden:
read -p " Introduce tu nombr e : " nombre
muestra en la pantalla el mensaj e In tradu c e tu nombre y se queda a la espera de que el usuario
introduzca por el teclado una cadena de caracteres y pulse la tecla de retomo de carro. Cuando esto
suceda la cadena introducida se almacenará en la variable nombre .
i) Los operadores lógicos disponibles en b a s h son:
•
El && E2 . Realiza la operación AND lógica entre El y E2.
•
El
•
1 1 E2 . Realiza la operación O R lógica entre E l y E2.
! E l . Realiza la operación NOT lógica sobre E l .
Los operadores de comparación de cadenas disponibles en bash son:
•
A = B. Comprueba si las cadenas A y B son iguales.
Soluciones completas de los ejercicios
•
A ! = B. Comprueba si las cadenas A y B son distintas.
•
A
•
A > B. Comprueba s i l a cadena A es mayor lexicográficamente que l a cadena B .
•
- n A . Comprueba s i l a cadena A e s n o nula y tiene una longitud mayor d e cero.
•
- z A. Comprueba si la cadena A tiene una longitud igual a cero.
<
367
B . Comprueba si la cadena A es menor lexicográficamente que la cadena B .
Finalmente los operadores de comparación de números enteros disponibles en bash son:
e
X
-lt
y.
Comprueba si x es menor que y.
e
X
-le
y.
Comprueba s i x es menor o igual a y.
e
X
- eq
y.
Comprueba si x es igual a y.
e
X
-ne
y.
Comprueba si x es distinto de y.
e
X
-ge
y.
Comprueba si x es mayor o igual a y.
e
X
-gt
y.
Comprueba si x es mayor que y.
j) Algunos de los operadores de comparación de atributos de archivos disponibles en bash son:
•
-a archivo. Comprueba si el archivo existe.
•
- e archivo . Comprueba si el archivo existe.
•
-
•
- s archivo. Comprueba si el archivo existe y no está vacío.
f archivo. Comprueba si el archivo existe y es un archivo regular.
k) El operador [ expre s i ón J evalúa la expresión incluida en su interior. Esta es la forma más
habitual de realizar la evaluación de condiciones en las sentencias condicionales. También se puede
utilizar el comando t e s t .
1 ) S e puede usar el comando l e t operac i ón o e l doble paréntesis ( ( operac i ón ) ) . Las siguien­
tes líneas ilustran la realización de operaciones aritméticas con enteros:
X=2 ; Y = 3 ;
l e t Z l =X+Y
Z 2 = $ ( ( X+Y ) )
echo $ Z l $ Z 2
También se podría usar e l comando expr.
m) En bash una sentencia condicional de tipo i f tiene la siguiente sintaxis :
368
Ampliación de sistemas operativos
i f c ondi c i ón1
then
s ent enc i as 1
e l i f c ondi c i on2
then
s entenc i a s 2
e l i f c ondi c i on3
then
s ent enc i a s 3
else
s entenc i a s 4
fi
L a sentencia condicional anterior s e puede escribir también d e la siguiente forma:
i f c ondi c i ón1 ; then
s ent enc i a s 1
e l i f c ondi c i on2 ; then
s ent enc i a s 2
e l i f c ondi c i on3 ; then
s entenc i a s 3
e l se
s ent enc i a s 4
fi
Las siguientes líneas muestran un ejemplo de sentencia condicional d e tipo i f en bash:
X = 2 ; Y= 5 ;
i f [ $ X - l e $Y l ; then
echo X = $ X e s menor o i gual a Y= $Y
el se
e cho X=$X e s mayor a Y= $ Y
fi
n ) E n bash u n bucle whi l e tiene la siguiente sintaxis :
whi l e [ c ondi c i ón
do
s ent enc i a s
done
Un bucle unt i l tiene una sintaxis similar, simplemente hay que cambiar whi l e por un ti l. Las
siguientes líneas muestran un ejemplo de bucle whi l e :
Soluciones completas de los ejercicios
369
COLOR= " ve rde "
whi l e [ $ COLOR ! = " ro j o "
do
echo " Incorrec t o "
read -p " Introdu c e un c o l or : " COLOR
done
echo " C orrec t o "
o) En bash un bucle f o r se implementa de forma diferente a otros lenguajes de programación, como
por ejemplo C. Su sintaxis es la siguiente:
f o r var i ab l e [ in l i s t a ]
do
s ent enc i a s que u s an $var i ab l e
done
Las siguientes líneas muestran un ejemplo de bucle f o r :
for i in $ ( l s ) ;
do
echo " i t em : $ i "
done
El siguiente ejemplo ilustra una implementación del bucle for más similar a la usada en C:
for i in $ ( seq 1 1 0 ) ;
do
echo " i = $ i "
done
p) En bash la sentencia c a s e presenta la siguiente sintaxis :
c a s e c adena i n
patron1 )
s en t enc i as 1 ; ;
pat ron2 )
s ent enc i a s 2 ; ;
esac
Las siguientes líneas muestran un ejemplo de uso de c a s e :
370
Ampliación de sistemas operativos
Z=2
case $ Z
1 ) echo
echo
2 ) echo
echo
3 ) echo
echo
* ) echo
echo
e s ae
in
Uno
A¡ ¡
Dos
B
Tres
e¡ ¡
Cua l qu i e r o t r o va l o r
Otros ¡ ¡
'
'
q) El siguiente ejemplo ilustra cómo se declara y se invoca en bash una función con parámetros de
entrada que devuelve un valor de salida
#Dec l arac i ón de una func i ón asd que rec ibe dos argument o s de entrada :
func t i on asd {
echo " pr imer parame t r o = $ 1 , segundo parame t r o = $ 2 "
re turn 3
# Invo c a c i ón de l a fun c i ón c on l o s paráme t r o s Ho l a
a s d Ho l a Mundo
echo " $ ? " #Vi sual i z ac i ón de l c ódigo de s a l i da
y
Mundo
Señalar que para devolver un cierto valor desde una función se debe usar el comando r e turn. El
valor devuelto hace las veces de estatus de salida.
Solución Ejercicio 1.4
El shell script de la Figura l. 7 en primer lugar muestra en el dispositivo de salida estándar, por defecto
la pantalla, el mensaje
Introduc e una cadena :
En segundo lugar invoca al comando read para leer una cadena de caracteres desde el dispositivo de
entrada estándar, por defecto el teclado. La cadena leída se almacena en la variable CADENA. En tercer
lugar define una variable LONG I TUD a la que le asigna la salida del comando
echo $ CADENA 1 wc
-e
Este comando, mediante el uso de una tubería ( 1 ) , pasa l a cadena contenida en l a variable CADENA como
entrada del comando wc - e , el cual cuenta el número de caracteres que contiene la cadena.
A continuación mientras el valor de LONGITUD sea mayor que O se ejecuta un bucle whi l e en el que
se realizan las siguientes acciones en cada iteración del bucle: en primer lugar se define una variable x
como la unión de la cadena de caracteres x y la unión de la cadena de caracteres que resulta de eliminar
Soluciones completas de los ejercicios
371
(comando cut) LONGITUD caracteres de la variable CADENA. En segundo lugar se decrementa en una
unidad el valor de LONG I TUD.
Cuando se sale del bucle whi l e se imprime en la pantalla el valor de la variable x la cual contiene la
cadena CADENA escrita al revés.
En definitiva este shell script solicita al usuario una cadena de caracteres y la muestra en pantalla
escrita al revés.
Solución Ejercicio 1.5
El shell script de la Figura 1 . 8 en primer lugar comprueba si el número de argumentos de entrada ( $ #)
del shell script es mayor que cero. En caso negativo muestra en el dispositivo de salida unos mensajes
para indicar que se ha producido un error al especificar los argumentos e invoca al comando exi t para
terminar la ejecución del script y devolver como estatus de salida el valor l.
Por el contrario, si se cumple la condición entonces ejecuta un bucle f o r tantas veces como argu­
mentos de entrada ( $ * ) se le hayan pasado al shell script. En cada iteración del bucle se realizan las
siguientes acciones : en primer lugar se ejecuta el comando mv para mover el archivo cuyo nombre ha
sido pasado como argumento del script al directorio . / pap e l era el cual debe estar creado antes de
ejecutar el shell script. Nótese que si no es así el efecto del comando mv es el del cambiar el nombre
del archivo pasado como argumento por el nombre de pape l era. Señalar que los posibles mensajes de
error que pueda generar este comando son redireccionados (2 >) al dispositivo nulo, el cual actúa como
un sumidero.
En segundo lugar se comprueba el estatus de salida ( $ ? ) del comando mv. En función de su valor se
muestra un determinado mensaj e en el dispositivo de salida estándar.
Cuando se termina de ejecutar el bucle f o r se ejecuta el comando exi t para terminar la ejecución
del script y devolver como estatus de salida el valor O.
En definitiva este shell script mueve los archivos pasados como argumentos de entrada a un directorio
previamente creado en el directorio de trabajo denominado pap e l era. Es decir, implementa una especie
de papelera de reciclaje.
# ! / b i n / bash
#
CONT= O
wh i l e
[
$ C ONT - l e 6 0
]
do
date
CONT = $ ( ( $ CONT + 1 ) )
s l e ep 1
done
Figura A.l
- Solución del Ejercicio 1 .6
372
Ampliación de sistemas operativos
Solución Ejercicio 1.6
En la Figura A. l se muestra el código de un shell script para el intérprete bash que muestra la fecha
y la hora del sistema cada segundo durante un minuto.
Solución Ejercicio 1.7
En la Figura A.2 se muestra el código de un shell script para el intérprete bash que muestra el día de
la semana que fue ayer.
# ! / b i n / ba s h
#
HOY= $ ( da t e + %w }
AYER= $ ( ( $ HOY - 1 } }
# da t e + %w devuelve e l d í a de l a s emana en f o rma t o nurne r l c o ,
# c o n va l o r e s c omprend i d o s e n t r e O
# En e s t e c a s o ,
( domingo }
y 6
( s ábado } .
ayer t ornará va l o r e s entre - 1 y 5 .
# HOY a lmac ena el nume r o de d i a para hoy .
# AYER a l ma c e n a e l va l o r de HOY
echo
meno s
l.
" Ayer fue "
c a s e $AYER i n
-1}
echo
0}
echo
" S abado " ; ;
" Domingo 11 ; ;
11 Lune s .. ; ;
1}
echo
2}
echo " Ma r t e s u
3}
echo
" Mi e rc o l e s " ; ;
4}
echo
5}
*}
echo
" Jueves u ; ;
11 V i e rne S 11 j j
echo
" Inde f i n i do " ; ;
; ;
esac
Figura A.2 -
Solución del Ejercicio 1 .7
Solución Ejercicio 1.8
La función de librería sys t em cuya declaración es
# inc lude < s td l i b . h>
int sys t em ( c ons t char * C adena ) ;
resulta útil para ejecutar desde un programa una orden del intérprete de comandos. Esta función invoca
un intérprete de comandos para que ejecute la orden c adena y regresa después de que la orden se haya
terminado de ejecutar. Si la invocación al intérprete falla el valor devuelto por sys t em es 1 27. Si se
puede invocar al intérprete de comandos pero se produce algún error en la ejecución de la orden el valor
Soluciones completas de los ejercicios
373
devuelto es - 1 . Si el comando se ejecuta correctamente, la función devuelve el estatus de salida de la
orden. En la Figura A.3 se muestra un pequeño programa escrito en C que ilustra el uso de esta función.
# i nc lude < s t dl ib . h>
ma i n ( )
{
i n t s a l i da ;
s a l i da = sys t em ( " \ n echo $ PATH \ n " ) ;
p r i n t f ( " \ n S a l i da= %d \ n " , s a l i da ) ;
Figura A.3 -
Solución del Ejercicio 1 . 8
Solución Ejercicio 1.9
a) La máscara de modo 6644 en octal equivale a la máscara de modo binaria 11 O 11 O 1 O O 1 O O
que indica que los bits S_I SUID, S_I SGID están activados, que el propietario del archivo tiene
permiso de lectura y escritura, y que el grupo propietario de archivo y el resto de usuarios tienen
permiso de lectura sobre el archivo.
b) La máscara de modo simbólica asociada a este archivo es : - rwS r - S r - -
e) La máscara de modo simbólica - rwx r - - - - T es equivalente a la máscara de modo binaria
001 111 100 000
que en octal es 1 7 4 o . Luego un posible comando a utilizar es:
chmod 1 7 4 0 r e s u l tados
Solución Ejercicio 1.10
El enunciado del problema afirma que s 0 7 pertenece al usuario Wo l f (UID=50 1 , GID=202). Asi­
mismo su máscara de modo simbólica es - rwxrw- rwx, cuyo significado es el siguiente:
•
El propietario del archivo (Wo l f ) puede leer, escribir y ejecutar el archivo. Además este archivo
tiene su bit S_I SUI D desactivado.
•
Los usuarios del grupo propietario del archivo, por defecto GID=202, pueden leer y escribir el
archivo, pero no pueden ejecutarlo. Además este archivo tiene su bit S_I SGID desactivado.
•
El resto de usuarios pueden leer, escribir o ejecutar el archivo. Además este archivo tiene su bit
s I SVTX desactivado.
374
Ampliación de sistemas operativos
Una vez explicado el significado de la máscara de modo simbólica es posible contestar a lo que pide en
el enunciado:
a) De acuerdo con la máscara de modo simbólica el propietario del archivo (Wo l f) tiene permiso de
ejecución sobre su archivo s 0 7 . Al proceso A que se crea en el sistema asociado a la ejecución de
s 0 7 se le asigna UID=50 1 y EUID=50 1 . Al ejecutar el proceso A en primer lugar se invoca a la
llamada al sistema getuid para asignar el valor del UID del proceso a la variable u [ o ] , en este
caso u [ O ] = 5 0 1 . Luego se invoca a la llamada al sistema g e t e u i d para asignar el valor del EUID
del proceso a la variable u [ 1 J , en este caso u [ 1 J = 5 o l .
A continuación se invoca a l a llamada al sistema s e tu i d para asignar al UID y al EUID del
proceso el valor de u [ 1 ] . Como el EUID del proceso A no es el del superusuario y el valor de
u [ 1 ] coincide con el valor del UID del proceso A entonces solamente el EUID del proceso A se
configura con el valor de u [ 1 ] . En resumen el resultado de esta llamada al sistema es configurar el
EUID del proceso A al valor EUID=50 1 , valor que por otra parte ya tenía sin necesidad de haber
ejecutado esta llamada al sistema. Cómo s e tu i d se ha ejecutado con éxito entonces se asigna el
valor O a la variable u [ 2 J
•
Luego se comprueba si el valor de u [ 2 J es igual O. Cómo la comprobación es positiva se invoca a
la función anfitriona al pasándole como argumento la dirección de memoria de la función huésped
a2 .
La primera acción que se realiza al ejecutar la función a l es invocar a la función huésped a2
pasándole como argumento el valor inicial de la variable u, que es 30,4. Se comienza a ejecutar
la función a2 . La primera acción asociada a a2 es ejecutar un bucle 4 veces dentro del cual se
multiplica el valor de la variable a por 0.5. El resultado de la multiplicación se asigna a la variable
a A continuación se muestran los valores que toma la variable a en cada iteración del bucle:
•
(h = - 1 ) a = 0,5
*
•
(h = O) a = 0,5
*
1 5,2 = 7,6
•
(h = 1 ) a = 0,5
*
7,6 = 3,8
•
(h = 2) a = 0,5
*
3 , 8 = 1 ,9
30,4 = 1 5 ,2
Finalizado el bucle se ejecuta la instrucción re turn ( a ) con lo que la función a2 finaliza devol­
viendo 1 ,9 como valor de salida que es asignado a la variable u de la función a l . A continuación
se ejecuta la instrucción r e turn ( u ) de la función al con lo que finaliza devolviendo el valor 1 ,9
como valor de salida que es asignado a la variable z del código principal.
Por último se imprime en pantalla el mensaje
[501 , 501 ,
y el proceso A finaliza su ejecución.
o,
1 . 90 ]
Soluciones completas de los ejercicios
375
b) El usuario Fox no pertenece al grupo de Wo l f ya que sus GID son distintos. De acuerdo con la
máscara de modo simbólica tiene permiso de ejecución sobre s o 7 . Al proceso A que se crea en
el sistema asociado a la ejecución de s 0 7 se le asigna UID=502 y EUID=502. El funcionamiento
del proceso A es similar al descrito en el caso anterior, con la diferencia de que en este caso el
mensaj e que aparece en pantalla es
[ 502 , 502 ,
A.2.
o,
1 . 90]
Soluciones ejercicios capítulo 2
Solución Ejercicio 2.1
Al escribir la orden j 0 9 4 se comienza a ejecutar el programa j 0 9 . Supóngase que a la ejecución
de dicho programa se le asocia el proceso A, cuyo PID= 1 1 20 según el enunciado. En primer lugar se
comprueba si el número de argumentos con que ha sido invocado j o 9 es distinto de dos. Conviene
recordar que el nombre del programa cuenta como argumento. Puesto que j o 9 4 tiene dos argumentos
la condición del i f no se cumple y se pasan a ejecutar las sentencias del e l s e .
En segundo lugar s e invoca a la función d e librería a t o i que convierte e l segundo argumento ( ' 4 ' ) de
la invocación de j o 9 a número entero y lo almacena en la variable a.
En tercer lugar se ejecuta un bucle whi l e cuya condición para que se ejecute una iteración es que
la llamada al sistema f o rk devuelva el valor O y que la variable b no tome el valor a. Recuérdese que
f o rk crea un proceso hijo y devuelve O para el proceso hijo y el PID del hijo al proceso padre.
La evaluación de esta condición da como resultado la creación de un hijo B con PID= 1 1 2 1 , que al
cumplir que f o rk le ha devuelto O y que b es distinta de 4 ejecuta el contenido del bucle. El proceso
padre A no ejecuta el bucle ya que fork no le ha devuelto un O sino 1 1 2 1 , por lo que ejecuta una llamada
al sistema wa i t y se queda a la espera de que su proceso hijo B termine.
El proceso B muestra en pantalla el mensaj e
Mens a j e 1 [ 1 1 2 1 ]
e incrementa en una unidad el valor de la variable b que ahora toma el valor l. A continuación evalúa
la condición del bucle que da como resultado la creación de un hijo C con PID= 1 1 22, que al cumplir
que fork le ha devuelto O y que b es distinto de 4 ejecuta el contenido del bucle. El proceso padre B no
ejecuta el bucle ya que f ork no le ha devuelto un O sino 1 1 22, por lo que ejecuta una llamada al sistema
wa i t y se queda a la espera de que su proceso hijo C termine.
El proceso C muestra en pantalla el mensaj e
Mens a j e 1 [ 1 1 2 2 ]
e incrementa en una unidad el valor de la variable b que ahora toma el valor 2. A continuación evalúa
la condición del bucle que da como resultado la creación de un hijo D con PID= 1 1 23, que al cumplir
que f o rk le ha devuelto O y que b es distinto de 4 ejecuta el contenido del bucle. El proceso padre C no
376
Ampliación de sistemas operativos
ejecuta el bucle ya que f o rk no le ha devuelto un O sino 1 1 23, por lo que ejecuta una llamada al sistema
wa i t y se queda a la espera de que su proceso hijo D termine.
El proceso D muestra en pantalla el mensaj e
Mens a j e 1 [ 1 1 2 3 ]
e incrementa en una unidad el valor de la variable b que ahora toma el valor 3 . A continuación evalúa
la condición del bucle que da como resultado la creación de un hijo E con PID= 1 1 24, que al cumplir
que f ork le ha devuelto O y que b es distinto de 4 ejecuta el contenido del bucle. El proceso padre D no
ejecuta el bucle ya que f ork no le ha devuelto un O sino 1 1 24, por lo que ejecuta una llamada al sistema
wa i t y se queda a la espera de que su proceso hijo E termine.
El proceso E muestra en pantalla el mensaje
Mens a j e 1 [ 1 1 2 4 ]
e incrementa en una unidad el valor de la variable b que ahora toma el valor 4. A continuación evalúa la
condición del bucle que da como resultado la creación de un hijo F con PID= 1 1 25 , sin embargo como b
es igual 4 no ejecuta el contenido del bucle sino que ejecuta la llamada al sistema wa i t , pero como F no
tiene hijos no se suspende sino que imprime en pantalla el mensaj e
Mens a j e 2 [ 1 1 2 5 ] = 1 1 2 4
y finaliza.
Por su parte el proceso padre E tampoco ejecuta el bucle porque para él fork no ha devuelto un O
sino 1 1 25, y además b=4 por lo que ejecuta una llamada al sistema wa i t y se queda a la espera de que
su proceso hijo F termine. Como éste ya ha finalizado imprime en pantalla el mensaje
Mensaj e 2 [ 1 1 2 4 ] = 1 1 2 3
y finaliza.
Puesto que su hijo E ya ha terminado se despierta al proceso D que imprime en pantalla el mensaje
Mensaj e 2 [ 1 1 2 3 ] = 1 1 2 2
y finaliza.
Como su hijo D ya ha terminado se despierta al proceso C que imprime en pantalla el mensaj e
Mensaj e 2 [ 1 1 2 2 ] = 1 1 2 1
y finaliza.
A continuación puesto que su hijo C ya ha terminado se despierta al proceso B que imprime en
pantalla el mensaje
Mens a j e 2 [ 1 1 2 1 ] = 1 1 2 0
y finaliza.
Finalmente como su hijo B ya ha terminado se despierta al proceso A que imprime en pantalla el
mensaj e
Mensaj e 2 [ 1 1 2 0 ] = 1 0 0 0
y finaliza.
Soluciones completas de los ejercicios
377
Solución Ejercicio 2.2
1) Al escribir la orden j O 7 se comienza a ejecutar el programa j O 7 al que se le asocia, de acuerdo con
el enunciado, un proceso A cuyo PID es 789. Al ejecutar el proceso A en primer lugar se ejecuta
la llamada al sistema s i gnal que asigna el manej ador func a las señales del tipo S I GSUR l . En
segundo lugar, se asigna a la variable u el resto que resulta de dividir u entre 2, es decir, se le
asigna el valor 15 %2 = l.
En tercer lugar se crea, mediante la invocación de la llamada al sistema f o rk, un proceso hijo B
del proceso padre A. El PID de este proceso es, de acuerdo al enunciado, igual a 790. Luego en
este punto del programa se tienen dos procesos el padre A y el hijo B . Es el planificador del núcleo
el que decidirá qué proceso A o B se ejecuta en primer lugar.
Cuando se planifica para ejecución el proceso A, la llamada al sistema fork le devuelve el PID
del proceso hijo creado, es decir, 790. En consecuencia no se cumple la condición que evalúa el i f
por lo que se ejecuta la llamada al sistema exi t que finaliza el proceso A y devuelve a su proceso
padre (el interprete de comandos) un estatus de salida igual a l.
Cuando se planifica para ejecución el proceso B , la llamada al sistema fork le devuelve el valor
O. En consecuencia se cumple la condición que evalúa el i f por lo que se ejecuta la llamada al
sistema execv que invoca al programa ex2 . La primera acción del programa ex2 es invocar a la
llamada al sistema pau s e que hace que el proceso B se quede a la espera de recibir una señal que
no ignore o que no tenga bloqueada.
2) Para responder adecuadamente a este apartado se debe recordar que durante la ejecución de la
llamada al sistema execv se carga en memoria el nuevo ejecutable (ex2 ) reemplazando las re­
giones de código, datos y pila de usuario del proceso asociado al ejecutable actual (j 0 7 ) . Además
el núcleo borra en el área-u asociada al proceso A las direcciones de los manej adores de señales
y establece las acciones por defecto para cada tipo de señal . En el caso de la señal S I GUSRl su
acción asignada por defecto es terminar el proceso.
Al ejecutar la orden ki l l - S I GUSRl 7 9 0 se envía una señal S I GUSRl al proceso con PID igual
a 790, es decir, al proceso B . Este proceso no tiene establecido un manej ador para este tipo de
señales luego se ejecuta la acción por defecto, en consecuencia el proceso B finaliza.
Solución Ejercicio 2.3
1) Al escribir la orden s O S & se comienza a ejecutar el programa s O S en segundo plano. Supóngase
que a la ejecución de dicho programa se le asocia el proceso A, por el enunciado se sabe que su
PID es 1 035.
Al ejecutar el proceso A en primer lugar se invoca a la llamada al sistema s i gna l para especificar
que cuando el proceso reciba la señal S I GUSRl la acción que debe realizar el núcleo es la acción
por defecto asociada a dicha señal, es decir, terminar el proceso. En segundo lugar se invoca a la
llamada al sistema f o r k para crear un proceso hij o B , cuyo PID sería1 036. Como f ork devuelve
378
Ampliación de sistemas operativos
el PID del proceso hijo al padre, entonces no se cumple la condición i f y se invoca a la llamada
al sistema wa i t que suspende la ejecución del proceso A hasta que finalice su proceso hijo B .
Asimismo cuando el proceso hijo B sea planificado invocará a l a llamada al sistema s i gna l para
especificar que cuando reciba una señal S I GUSR1 se debe ignorar. A continuación invoca a la
llamada al sistema pau s e que hace que el proceso B quede a la espera de una señal que no ignore
o que no tenga bloqueada.
2) Al escribir la orden ki l l - S I GUSR1 1 0 3 6 se envía una señal S I GUSR1 al proceso con PID 1 036,
es decir, al proceso hijo B. Dicha señal es ignorada por el proceso.
3) Finalmente al escribir la orden ki l l - S IGUSR2 1 0 3 6 se envía ahora una señal S IGUSR2 al
proceso B . Como no se ha especificado ninguna acción para esta señal se ejecuta la acción por
defecto, que es terminar el proceso B . Así internamente el núcleo invoca a la rutina exi t ( ) siendo
el estatus de salida para el proceso padre A el número asociado a dicha señal, cuyo valor depende
de cada SOBUNIX y que lo vamos a denotar por NS . Puesto que el proceso B ha finalizado,
obviamente ya no se ejecuta la sentencia exi t ( 5 ) .
El núcleo devuelve al proceso A el PID 1 036 del proceso hij o y el estatus de salida NS. Así el
proceso A imprime en pantalla el mensaje
1 0 3 6 NS
y finaliza.
Solución Ejercicio 2.4
Al escribir la orden m O 9 se comienza a ejecutar el programa m O 9 . Supóngase que a la ejecución de
dicho programa se le asocia el proceso A, cuyo PID=2045 según el enunciado.
El proceso A hace una llamada al sistema fork para crear un proceso hijo (proceso B) al cual se le
asigna, de acuerdo con el enunciado, PID= 2046. La llamada al sistema fork devuelve O al proceso hijo
y 2046 al proceso padre. Estos valores se almacenan en la variable a del padre y del hijo, respectivamente.
Depende del planificador qué proceso se ejecuta después del f o rk, el padre A o el hijo B . Supóngase
que se ejecuta primero el proceso hij o B . Entonces entra en un bucle whi l e infinito, en cada pasada del
bucle se realizan las siguientes acciones : en primer lugar se realiza una operación binaria XOR ( a = a " 1 O),
es decir, a = a EB 1 0 = a· 1 0 + a · 10, entre la variable a, que contiene el valor O en la primera pasada del
bucle, y el número 10, almacenando el resultado en a.
En segundo lugar se invoca a la llamada al sistema ra i s e que envía al proceso B la señal S I GCHLD,
la acción por defecto asociada a esta señal es ignorarla, por lo que el proceso B no se ve perturbado por
dicha señal. Esta llamada al sistema devuelve un O si se ejecuta con éxito y - 1 en caso contrario. Se va a
suponer que se ejecuta con éxito.
En tercer lugar se imprime en pantalla el mensaje
Mensaj e 1 [ 2 0 4 6 ] : 0 : 1 0
Soluciones completas de los ejercicios
379
si se trata de una iteración impar del bucle, o el mensaje
Mensaje 1 [2046]: 0: O
si se trata de iteración par.
En cuarto lugar invoca a la llamada al sistema s 1 eep que suspende la ejecución del proceso B durante
4 segundos.
Cuando se planifica el proceso padre A invoca a la llamada al sistema sleep que suspende su ejecu­
ción durante 16 segundos. Cuando reanuda su ejecución invoca a la llamada al sistema kill para enviar
la señal SIGUSR1 al proceso hijo B. Esta señal tiene establecida como acción por defecto la terminación
del proceso que la recibe.
A continuación el proceso A invoca a la llamada al sistema sleep que suspende su ejecución du­
rante 3 segundos. Finalmente invoca a la llamada al sistema kill para enviar la señal SIGUSR2 a su
proceso padre, que es el intérprete de comandos (PID=2000). Esta señal tiene establecida como acción
por defecto la terminación del proceso que la recibe. Por lo que el intérprete de comandos desde donde
se invocó al programa m O 9 termina y se cierra su ventana.
Debe tenerse en cuenta que durante los 16 segundos que duerme el proceso padre A al proceso hijo
B le da tiempo a mostrar por pantalla los siguientes cuatro mensajes antes de que se cierre la ventana del
intérprete de comandos:
Mensaje
Mensaje
Mensaje
Mensaje
1
1
1
1
[2046]:
[2046]:
[2046]:
[2046]:
0:
o:
o:
o:
10
o
10
o
Solución Ejercicio 2.5
1) Al escribir la orden s09R 1 & se comienza a ejecutar el programa s09R en segundo plano. Su­
póngase que a la ejecución de dicho programa se le asocia el proceso A, por el enunciado se sabe
que su PID es 245.
Al ejecutar el proceso A en primer lugar invoca a la llamada al sistema signal para especificar
que cuando el proceso reciba la señal SIGUSR1 la acción que debe realizar el núcleo es ejecutar la
función fl. En segundo lugar invoca otra vez a la llamada signal para especificar que cuando el
proceso reciba la señal SIGUSR2 la acción que debe realizar el núcleo es ejecutar la la acción por
defecto asociada a dicha señal, es decir, terminar el proceso.
En tercer lugar invoca a la función atoi para pasar de carácter ASCII a número entero el primer
argumento de entrada (b [1]) del programa. Luego en la variable d se almacena el valor l.
En cuarto lugar comprueba si el número de argumento de entradas a es igual a 2 y si además d es
igual a l. Ambas condiciones en este caso se cumplen, ya que conviene recordar que el nombre
del programa cuenta como argumento de entrada. Por lo tanto se invoca a la llamada al sistema
sigsetrnask para bloquear la recepción de las señales SIGUSRl. Señalar que sigrnask es una
macro que permite configurar el valor de un determinado bit de la máscara de señales bloqueadas.
380
Ampliación de sistemas operativos
Si la llamada se ejecuta con éxito en la variable e se almacena la máscara de señales bloqueadas
que se tenía especificada antes de ejecutar esta llamada al sistema.
A continuación se invoca a la llamada al sistema sigblock para añadir nuevas señales a la másca­
ra de señales bloqueadas. En este caso se bloquea la recepción de las señales SIGUSR2. Finalmente
se invoca a la llamada al sistema pause y el proceso A entra en el estado dormido a la espera de
recibir una señal que no ignore y que no tenga bloqueada.
2) Al escribir la orden kill -SIGUSR1 245 se envía una señal SIGUSR1 al proceso con PID 245,
es decir, al proceso A. De acuerdo con el apartado anterior la recepción de señales SIGUSR1 está
bloqueada por el proceso luego el núcleo no le despierta.
3) Igual que el apartado anterior pero aplicado a las señales SIGUSR2.
Solución Ejercicio 2.6
La respuesta a este ejercicio depende de la salida que muestre por la pantalla el comando ps -j. Por
ejemplo se va a suponer que la salida es:
PID
3 9 68
63 82
63 3 9
PGID
3968
6382
63 3 9
SID
3968
3968
3968
TTY
pts /2
pts /2
pts /2
TIME
0:01
0:00
12:46
CMD
bash
ps
prog27
a) SID=3968. El proceso líder de la sesión es aquél cuyo PID coincide con el valor del SID, en este
caso el proceso con PID=3968 asociado al intérprete de comandos bash.
b) Se observa que existen tres grupos de procesos, cuyos PGID son: 3968. 6382 y 6339. En este caso
cada grupo consta de un único proceso.
A.3.
Soluciones ejercicios capítulo 3
Solución Ejercicio 3.1
En un sistema BSD4.3 el rango de prioridades [0, 49] está reservado para la ejecución de un proceso
en modo núcleo. Además el sistema BSD4.3 es de núcleo no expropiable, ello significa que si un proceso
está ejecutándose en modo núcleo éste continuará usando el procesador hasta que termine su ejecución,
se lo ceda voluntariamente a otro proceso o entre en el estado dormido a la espera de que se produzca
algún evento. En consecuencia el cuanto de ejecución de un proceso ejecutándose en modo núcleo es
infinito.
Por otra parte, un algoritmo de planificación de turno rotatorio con un cuanto de ejecución infinito es
equivalente a un algoritmo PIFO. Luego éste sería el algoritmo de planificación que se estaría aplicando
de forma efectiva sobre las colas asociadas al rango de prioridades [0, 49].
Soluciones completas de los ejercicios
381
Solución Ejercicio 3.2
En el intervalo [0, 100) ms se ejecuta el proceso A. Durante este intervalo la rutina de tratamiento de
la interrupción recalcula la prioridad del proceso A en t = 40 ms y en t = 80 ms. En t = 40 ms el campo
p_cpu del proceso A toma el valor 4, luego sustituyendo valores en (3. 1) y operando se obtiene que el
valor de la prioridad en modo usuario p_usrpri del proceso A en t = 40 ms es:
p_usrpri = PUSER+
¡u + 2·p_nice = 50+ � + 2·20 = 9 1
p_
De forma análoga en t = 8 0 ms el valor de la prioridad en modo usuario del proceso A es:
p_usrpri = 50+
� + 2·20 = 92
En t = 100 ms el campo p_cpu del proceso A toma el valor 10 y finaliza el cuanto asignado al
proceso A. Se invoca entonces a la rutina roundrobin ( ) para planificar al siguiente proceso de la cola,
en este caso el proceso B.
En el intervalo [ 100, 200) ms se ejecuta el proceso B. Durante este intervalo la rutina de tratamiento
de la interrupción recalcula la prioridad del proceso A en t = 140 ms y en t = 180 ms. En t = 140 ms el
campo p_cpu del proceso B toma el valor 4, luego el valor de la prioridad en modo usuario p_usrpri
del proceso B en t = 140 ms es:
p_usrpri = 50+
� + 2·20 = 91
De forma análoga !!n t = 180 ms el valor de la prioridad en modo usuario del proceso B es:
p_usrpri = 50+
� + 2·20 = 92
En t = 200 ms el campo p_cpu del proceso A toma el valor 10 y finaliza el cuanto asignado al
proceso B. Se invoca entonces a la rutina roundrobin ( ) para planificar al siguiente proceso de la cola,
en este caso el proceso C.
En el intervalo [200, 300) ms se ejecuta el proceso B. Durante este intervalo la rutina de tratamiento
de la interrupción recalcula la prioridad del proceso A en t = 240 ms y en t = 280 ms. En t = 240 ms el
campo p_cpu del proceso e toma el valor 4, luego el valor de la prioridad en modo usuario p_usrpri
del proceso e en t = 140 ms es:
p_usrpri = 50+
� + 2·20 = 91
De forma análoga en t = 280 ms el valor de la prioridad en modo usuario del proceso e es:
p_usrpri = 50+
� + 2·20 = 92
382
Ampliación de sistemas operativos
La ejecución de los procesos A, B y C se va alternando en la forma descrita hasta llegar a t = 1000
ms. El proceso A se ejecuta en los intervalos [300, 400), [600, 700) y [900, 1000) ms. Al terminar estos
tres cuantos de ejecución el valor del campo p_cpu del proceso A es igual a 40.
El proceso B se ejecuta en los intervalos [400, 500) y [700, 800) ms. Al terminar estos dos cuantos
de ejecución el valor del campo p_cpu del proceso B es igual a 30.
Por su parte el proceso C se ejecuta en los intervalos [500, 600) y [800, 900) ms. Al terminar estos
dos cuantos de ejecución el valor del campo p_cpu del proceso B es igual a 30.
En t = 1000 ms se invoca a la rutina schedcpu ( ) que en primer lugar multiplica el valor del campo
p_cpu de todos los procesos por el factor de decadencia, que de acuerdo con el enunciado es igual a 0,5.
Se tiene por tanto que p_cpu= 0,5·40 = 20 para el proceso A y p_cpu= 0,5·30 = 15 para los procesos
B y C.
En segundo lugar la rutina schedcpu ( ) recalcula la prioridad en modo usuario de cada proceso.
Para el proceso A se obtiene
O
p_usrpri = 50+
+ 2·20 = 95
�
Mientras que para los procesos B y C se obtiene
p_usrpri =
50+ � + 2·20 = 93
Por último la rutina schedcpu ( ) mueve a los procesos de la cola i = 22 asociada al rango de
prioridades [88, 9 1] en la que habían sido colocados al ser creados y los coloca en la cola i = 23 que está
asociada al rango de prioridades [92, 95]. Señalar que si no llega al sistema otro proceso más prioritario,
el proceso B será el próximo proceso en ser planificado.
Solución Ejercicio 3.3
Puesto que ts_cpupri = 1 la fila de la tabla de despacho que hay que consultar, cuando se produzca
alguno de los eventos que generan un cambio de prioridad, es la fila segunda asociada al nivel de prioridad
(PRIORITY LEVEL) 1.
a) Si el proceso consume su cuanto asignado entonces el valor de ts_cpupri se actualiza con el
valor de ts_tqexp de la segunda fila. Luego ts_cpupri =O. Como ts_upri = 14 entonces el
nuevo valor de la prioridad en modo usuario de acuerdo con (3.3) y (3.4) será ts_umdpri = 14.
Por lo tanto la prioridad en modo usuario del proceso se reduce de 15 a 14.
b) Si el proceso ha estado esperando para poder consumir su cuanto más de 5 segundos entonces el
valor de ts_cpupri se actualiza con el valor de ts_lwait de la segunda fila. Luego ts_cpupri
= 1 1. Como ts_upri = 14 entonces el nuevo valor de la prioridad en modo usuario de acuerdo
con (3.3) y (3.4) será ts_umdpri = 25. Luego la prioridad en modo usuario del proceso aumenta.
e) Si el hilo es despertado, cuando regresa a modo usuario el valor de ts_cpupri se actualiza con el
valor de ts_slpret de la segunda fila. Luego ts_cpupri = 1 1. Como ts_upri = 14 entonces
383
Soluciones completas de los ejercicios
el nuevo valor de la prioridad en modo usuario de acuerdo con (3.3) y (3.4) será ts_umdpri
En conclusión la prioridad en modo usuario del proceso aumenta.
=
25.
Solución Ejercicio 3.4
Al escribir la orden j1 o se comienza a ejecutar el programa j1 o. Supóngase que a la ejecución de
dicho programa se le asocia el proceso A. En primer lugar se le asigna el valorO a los elementos sem_flg
del array de estructuras z de tipo sembuf. Conviene recordar que las estructuras de tipo sembuf se
utilizan para especificar las operaciones que se desean realizar sobre un conjunto de semáforos. Los
elementos sem_flg permiten pasar indicadores a la llamada al sistema semop.
En segundo lugar se invoca a la llamada al sistema ftok para crear una llave numérica de 32 bits
que permite controlar el acceso a una instancia de un mecanismo IPC. Supuesto que se ejecuta con éxito
en y, que es una variable del tipo predefinido key_t, se almacenará la llave creada. En caso de error en
y se almacenará el valor (key_t) -l.
En tercer lugar se comprueba, si se ha producido algún error en la ejecución de la llamada al sistema
ftok. En dicho caso se ejecuta la función printf que muestra por pantalla el mensaje
mensaje wert
y se invoca a la llamada al sistema exit para terminar la ejecución del proceso A, devolviendo como
estatus de salida para su proceso padre el valor 3.
Si ftok se ha ejecutado con éxito entonces se invoca a la llamada al sistema semget para obtener
o crear un conjunto de dos semáforos. Si la llamada se ejecuta con éxito entonces en x se almacenará
el identificador entero del conjunto de 2 semáforos asociados a la llave y. Si no existe un conjunto de
semáforos asociado a dicha llave se crea (IPC_CREAT) uno nuevo con permisos de lectura y escritura
para el propietario (0600).
Después se invoca a la llamada al sistema semctl para inicializar con el valorO todos los semáforos
(SETALL) del conjunto de semáforos con identificador x.
A continuación se invoca a la llamada al sistema fork para crear un proceso hijo (proceso B). Esta
llamada devuelveO al proceso hijo y el PID del hijo al proceso padre. El proceso que se ejecute primero
(padre o hijo) dependerá del planificador. Supongamos que se ejecuta primero el proceso hijo B, entonces
tras asignar el valorO al elemento sem_num y el valor 1 al elemento sem_op de la estructura z [ O l invoca
a la llamada semop para realizar una operación signal_sem sobre el semáforoO del conjunto x. Como
el semáforoO de x había sido inicializado aO tras realizar esta operación toma el valor l.
A continuación el proceso B tras asignar el valor 1 al elemento sem_num y el valor -1 al elemento
sem_op de la estructura z [1] invoca a la llamada semop para realizar una operación wait_sem sobre el
semáforo 1 del conjunto x. Como el semáforo 1 de x había sido inicializado aO, el proceso B se bloquea
en espera de que algún otro proceso realice una operación signal_sem sobre este semáforo.
Por su parte el proceso padre A, invoca de nuevo a la llamada al sistema fork para crear otro proceso
hijo (proceso C). Esta llamada devuelve O al proceso hijo y el PID del hijo al proceso padre. El proceso
que se ejecute primero (padre o hijo) dependerá del planificador. Supongamos que se ejecuta primero
el proceso padre A, éste como no tiene más instrucciones para ejecutar finaliza. Se ejecuta entonces el
384
Ampliación de sistemas operativos
hijo C que invoca a la llamada al sistema sleep y suspende su ejecución durante dos segundos. Cuando
despierta tras asignar el valorO al elemento sem_num y el valor -1 al elemento sem_op de la estructura
z [ O J invoca a la llamada semop para realizar una operación wait_sem sobre el semáforoO del conjunto
x. Como el semáforoO de x había sido puesto a 1 por el proceso B, esta operación pone aO el semáforo
O. A continuación el proceso C ejecuta la función printf que muestra por pantalla el mensaje
mensaje fgh
Posteriormente el proceso C tras asignar el valor 1 al elemento sem_num y el valor 1 al elemento
sem_op de la estructura z [1] invoca a la llamada semop para realizar una operación sobre el semáforo
1 del conjunto x. Como resultado de esta operación pone el semáforo 1 aO y despierta al proceso B que
estaba bloqueado en el semáforo. Qué proceso se ejecuta (B o C) depende del planificador. Supuesto
que se ejecuta el C, éste simplemente finaliza. Entonces se planifica el proceso B que ejecuta la función
printf, muestra por pantalla el mensaje
mensaje asd
y finaliza.
Solución Ejercicio 3.5
Al escribir la orden sl O sistemas_operativos_2 se comienza a ejecutar el programa sl O. Su­
póngase que a la ejecución de dicho programa se le asocia el proceso A.
En primer lugar se comprueba que el número de parámetros (b) introducidos por la línea de comandos
al invocar a s1 O es igual a 2. La comprobación es positiva los dos parámetros introducidos son s1 O y
sistemas_operativos_2.
En segundo lugar se invoca a la llamada al sistema pipe para crear una tubería sin nombre y se
comprueba si se ha producido algún error, es decir, devuelve el valor -l. Si pipe (pdf) se ha ejecutado
con éxito entonces se crea una tubería sin nombre y en pdf se habrán almacenado dos descriptores de
archivos. Para leer de la tubería hay que usar el descriptor almacenado en pdf [ O J , mientras que para
escribir hay que usar el descriptor almacenado en pdf [1] .
Si se produjese algún error durante la ejecución de pipe entonces se imprimiría en pantalla el mensaje
El: [mensaje]
donde [mensaje J hace referencia al mensaje asociado al identificador de error contenido en la variable
errno. A continuación se invocaría a la llamada al sistema exit para terminar la ejecución del proceso
A.
Si pipe se ha ejecutado con éxito entonces se invoca a la llamada al sistema fork para crear un
proceso hijo (proceso B). Esta llamada devuelve el valorO al proceso hijo y el PID de hijo al proceso
padre. Dicho valor, en cualquier caso, se almacena en la variable a. Será el planificador el que decida
que proceso se ejecuta a continuación el padre o el hijo.
Supongamos que se ejecuta primero el proceso padre hasta finalizar y luego el proceso hijo. Primero
cierra el archivo con descriptor pdf [ O J (asociado a las operaciones de lectura en la tubería) ya que
Soluciones completas de los ejercicios
385
no lo va usar. En segundo lugar invoca a la llamada al sistema write para escribir en el archivo con
descriptor pdf [1] (asociado a las operaciones de escritura en la tubería) los diez primeros bytes del
segundo parámetro introducido por la línea de órdenes, es decir, escribe en la tubería sistemas_o. En
tercer lugar cierra el archivo con descriptor pdf [1] , ya que no va escribir más en la tubería. En cuarto
lugar escribe en pantalla el texto
Mensaje
Y finalmente invoca a la llamada al sistema exit para finalizar.
A continuación se ejecuta el proceso hijo. En primer lugar cierra el archivo con descriptor pdf [1]
ya que no va escribir en la tubería. En segundo lugar ejecuta un bucle while, en cada pasada del bucle
se lee un byte de la tubería y se escribe en la pantalla. El bucle finaliza cuando ya no quedan más bytes
por leer en la tubería. En la pantalla se habrá mostrado el siguiente texto
sistemas o
En tercer lugar escribe en la pantalla un salto de línea. En cuarto lugar, cierra el archivo con descriptor
pdf [1] ya que no va a leer más en la tubería. En quinto lugar muestra en pantalla el texto
Mensaje
Y finalmente invoca a la llamada al sistema exit para finalizar.
Señalar que si se hubiese planificado el proceso hijo antes que el padre éste se hubiera quedado
bloqueado al intentar leer en una tubería vacía. Solo cuando el proceso padre escriba en la tubería el
proceso hijo será desbloqueado. En dicho momento será el planificador el que decida si se continúa con
la ejecución del padre o con la del hijo.
De acuerdo con la explicación anterior y dependiendo del orden de planificación de los procesos en
la pantalla se pueden llegar a visualizar dos posibles trazas de ejecución:
•
Traza 1:
Mensaje
sistema_o
Mensaje
•
Traza 2:
sistema_o
Mensaje
Mensaje
386
Ampliación de sistemas operativos
Solución Ejercicio 3.6
Al escribir la orden j08a & se comienza a ejecutar el programa j08a en segundo plano. Supóngase
que a la ejecución de dicho programa se le asocia el proceso A.
Al ejecutar el proceso A en primer lugar se invoca a la función de librería malloc para reservar
memoria para almacenar 9 caracteres. Si la función se ejecuta con éxito entonces en b se almacena un
puntero a la zona de memoria reservada. En caso contrario devuelve NULL.
En segundo lugar, se ejecuta nueve veces un bucle for. En cada ejecución del bucle se asigna el
carácter nulo 1\ o a los elementosO a 8 de la cadena de caracteres apuntada por el puntero b.
1
En tercer lugar se invocaría a la llamada al sistema mknod para crear en el directorio actual una
tubería con nombre o archivo PIFO de nombre asd con permisos de lectura y escritura para todos los
usuarios.
En cuarto lugar, se invocaría a la llamada al sistema open para abrir el archivo PIFO asd con permi­
sos de lectura y escritura para todos los usuarios. Si la llamada al sistema se ejecuta con éxito se almacena
el descriptor del archivo en la variable enterar.
En quinto lugar, se invocaría a la llamada al sistema read para leer 7 bytes del archivo PIFO asd y
copiarlos en el array de caracteres b. Puesto que la tubería está vacía (ya que no se disponen de datos que
hagan suponer lo contrario) el proceso A se bloqueará hasta que otro proceso escriba en la tubería.
Al escribir la orden j08b se comienza a ejecutar el programa j08b en primer plano. Supóngase que
a la ejecución de dicho programa se le asocia el proceso B.
En primer lugar el proceso B invoca a la llamada al sistema open para abrir el archivo asd con
permisos de lectura y escritura para todos los usuarios. Si la llamada al sistema se ejecuta con éxito se
almacena el descriptor del archivo en la variable entera r. Se va a suponer en lo que resta que se ha
podido abrir el archivo asd.
En segundo lugar invoca a la llamada al sistema wri te para escribir los 8 bytes de la cadena de
caracteres b en el archivo asd. Finalmente, el proceso B invoca a la llamada al sistema close para
cerrar el archivo y el proceso B finaliza.
Por otra parte, puesto que la tubería ya contiene datos el núcleo despierta al proceso A, cuando éste
vuelva a ser planificado para ejecución se podrá completar la llamada al sistema read, es decir, leer
7 bytes del archivo PIFO asd y copiarlos en el array de caracteres b. A continuación, se ejecutará la
función de librería printf que mostrará en la pantalla
Texto 1
Después se invocará a la llamada al sistema e lose para cerrar el archivo asd, Finalmente se invocará
a la llamada al sistema unlink para eliminar el archivo PIFO asd y el proceso A finalizará.
Conviene señalar que dependiendo del orden de planificación de los procesos, podría suceder que al
escribir el proceso B en la tubería se despertase al proceso A y esté fuese planificado para ser ejecutado
hasta su finalización. Una vez finalizado el proceso A se continuaría con la ejecución del proceso B.
Soluciones completas de los ejercicios
A.4.
387
Soluciones ejercicios capítulo 4
Solución Ejercicio 4.1
La modificación pedida consiste simplemente en cambiar MAP_SHARED por MAP_ PRIVATE en la
llamada al sistema mmap. Se puede comprobar que con este cambio el mapeado del archivo textol.txt
pasa a ser de tipo privado y en consecuencia las modificaciones que realice el proceso sobre el archivo no
pueden ser visualizadas por lo procesos que mapeen este archivo en su espacio de direcciones. Además
dichas modificaciones no son trasladadas al archivo en el disco duro. En consecuencia cuando finaliza la
ejecución del proceso asociado al programa prog42 el contenido del archivo sigue siendo el mismo.
Solución Ejercicio 4.2
La solución de este ejercicio depende del SOBUNIX y de la arquitectura del computador que se
utilicen. En este caso se ha utilizado OpenSolaris sobre una máquina virtual Oracle V M VirtualBox.
a) Supóngase que al ejecutar el comando prog42 & se ha creado un proceso A con PID=6659.
Supóngase además que cuando aparece en pantalla el mensaje
PID=6659 duerme 20 s
y se ejecuta el comando pmap 6659 aparece en la pantalla la salida que se muestra en la Figura
A.4.
Este comando muestra información sobre el espacio de direcciones virtuales del proceso A. La pri­
mera fila contiene el PID del proceso y el nombre de ruta relativa del programa que está ejecutando
6659:
prog42
08046000
8K rwx--
08050000
4K r-x--
/export/home/josema/prog43
08060000
8K rwx--
/export/home/josema/prog43
D1E30000
24K rwx--
D1E40000
1280K r-x--
D1F80000
28K rwx--
/usr/lib/libc/libc_hwcap1.so.1
D1F87000
8K rwx--
/usr/lib/libc/libc_hwcap1.so.1
D1F90000
4K rwx--
D1FAOOOO
4K rw---
[ anon ]
D1FBOOOO
4K rw---
[ anon ]
D1FBFOOO
180K r-x--
/lib/ld.so.1
D1FFCOOO
8K rwx--
/lib/ld.so.1
4K rwx--
/lib/ld.so.1
D1FFEOOO
total
[ stack l
[ anon ]
/usr/lib/libc/libc_hwcap1.so.1
[ anon l
1564K
Figura A.4- Salida del comando pmap 6659 del apartado a) del Ejercicio 4.2
388
Ampliación de sistemas operativos
el proceso. La última fila contiene el tamaño total en KiB del espacio de direcciones virtuales del
proceso, en este caso 1564 KiB. Cada una de las restantes filas contiene la siguiente información
sobre una determinada región del espacio de direcciones virtuales del proceso: dirección virtual de
inicio de la región, tamaño de la región en KiB, permisos de acceso y nombre de ruta absoluto del
archivo que se mapea en dicha región.
Por otra parte, se observa que en el espacio de direcciones virtuales del proceso A existen las
siguientes regiones: pila, código, datos, y librerías compartidas. Además existen definidas varias
regiones de memoria anónima [ anon ] , estas regiones serán utilizadas, por ejemplo, para alber­
gar las copias de las páginas de las regiones que hayan sido configuradas con un mapeado de tipo
de privado.
b) Supóngase además que cuando aparece en pantalla el mensaje
PID=6659 vuelve a dormir otros 20 s
y se ejecuta el comando pmap 6659 aparece en la pantalla la salida que se muestra en la Figura
A.5. Se observa que el tamaño del espacio del proceso A ha crecido en 8 KiB pasándose a ser
ahora de 1572 KiB. Estos 8 KiB adicionales provienen de la región de montículo ( [ heap l) que
se ha creado para albergar la reserva de memoria realizada con la función malloc.
6659:
prog42
08046000
8K rwx--
08050000
4K r-x--
/export/home/josema/prog43
08060000
8K rwx--
/export/home/josema/prog43
08062000
8K rwx--
D1E30000
24K rwx--
[ stack l
[ heap l
D1E40000
1280K r-x--
[ anon l
/usr/lib/libc/libc_hwcap1.so.1
D1F80000
28K rwx--
/usr/lib/libc/libc_hwcap1.so.1
D1F87000
8K rwx--
/usr/lib/libc/libc_hwcap1.so.1
D1F90000
4K rwx--
D1FA0000
4K rw---
[ anon l
[ anon l
[ a non l
!lib/ld. so.1
D1FB0000
4K rw---
D1FBFOOO
180K r-x--
D1FFC000
8K rwx--
!lib/ld.so.1
D1FFEOOO
4K rwx--
/lib/ld. so.1
total
1572K
Figura A.S- Salida del comando pmap 6659 del apartado b) del Ejercicio 4.2
Solución Ejercicio 4.3
El comando vmstat 5 2 finaliza su ejecución transcurridos 5·2 = 10 s y durante este tiempo mues­
tra cada 5 segundos información sobre el estado de la memoria y sobre ciertos eventos del sistema (carga
Soluciones completas de los ejercicios
389
de CPU, paginación, número de cambios de contexto, interrupciones de dispositivo, llamadas del sis­
tema, etc). Señalar que la información mostrada depende de la implementación que se realiza de este
comando en cada SOBUNIX.
Por ejemplo, supóngase que este comando se ejecuta en un sistema OpenSolaris y que la salida que
se muestra en la pantalla es la siguiente:
kthr
page
memory
r b w
swap
fau1ts
disk
cpu
free
re
o o o 391292 39676
2
7
o
o
1 2792 6 1 -2
o
o
241
283
220 12
4 85
1 o
9
80
o
o
o 1656 o 3
o
o
254
352
241 98
2
o 334500 36728
mf pi po fr de sr sO s1
o
in
sy
es us sy id
o
Señalar que existen dos líneas de datos numéricos, la primera línea se muestra cuando se lanza la
orden y la segunda línea cuando transcurren 5 s.
Si se ejecuta la orden man vmstat se puede conocer el significado de la información que se mues­
tra en cada columna de la salida. kthr contiene información sobre el número de hilos del núcleo en
diferentes estados, memory contiene información sobre el uso de memoria, page contiene información
sobre fallos de página y paginación, disk informa sobre el número de operaciones en disco por segundo,
faul ts informa sobre la tasa de trampas e interrupciones y cpu informa sobre el porcentaje promedio
de uso de los procesadores.
A.5.
Soluciones ejercicios capítulo 5
Solución Ejercicio 5.1
a) Esta llamada al sistema abre el archivo datos.txt con permisos de lectura y escritura (O_RDWR).
Además sitúa el puntero de lectura/escritura al final del archivo (o_APPEND).
b) Esta llamada al sistema abre el archivo prueba con permiso de solo lectura (o_RDONLY). Si el
archivo no estaba ya creado lo crea (o_CREAT) con la máscara de modo octal 0600.
Solución Ejercicio 5.2
La llamada al sistema o el comando unlink eliminan un enlace duro, es decir, una entrada de un
directorio. En este caso como el archivo únicamente tenía un enlace duro la aplicación de esta llamada
al sistema produce la eliminación del archivo.
Solución Ejercicio 5.3
En la Figura A.6 se muestra el código C del programa ejstat que hace uso de la llamada al sistema
stat para mostrar algunos de los atributos del archivo cuyo nombre de ruta debe pasarse como argu­
mento de entrada del programa. Por ejemplo si en un intérprete de comandos de un SOBUNIX se escribe
la orden
390
Ampliación de sistemas operativos
ejstat texto1.txt
en la pantalla aparecerían algunos de los atributos del archivo con nombre de ruta relativa texto1.txt,
supuesto que dicho archivo existe en el directorio de trabajo actual.
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
main(int argc, char *argv[ ] )
{
struct stat buffer;
int r;
if(argc==2)
{
r = stat(argv[l ] , &buffer);
if(r==-1) printf("\nError al ejecutar la llamada stat\n");
else
printf("\n**Información sobre el archivo
printf("Número nodo-i =
%s**\n", argv[l ] );
%:1. \n",buffer.st_ino);
printf("Número de enlaces duros =
printf("UID del propietario =
%:1.\n", buffer.st_nlink);
%:1.\n", buffer.st_uid);
printf("GID del grupo propietario =
printf("Tamaño en bytes =
%:1.\n", buffer.st_gid);
%:1.\n", buffer.st_size);
printf("Fecha y hora del último acceso =
%s\n",ctime(&buffer.st_atime));
Figura A.6- Código C del programa ejstat
Solución Ejercicio 5.4
Al escribir la orden j1o 25 wert.txt se comienza a ejecutar el programa j1o. Supóngase que a
la ejecución de dicho programa se le asocia el proceso A. En primer lugar se comprueba que el número
de parámetros (np) introducidos por la línea de comandos al invocar a j10 es igual a 3. La comprobación
es positiva los tres parámetros introducidos son j10, 25 y wert.txt.
En segundo lugar se invoca a la función atoi para convertir a número entero el segundo paráme­
tro (25) introducido por la línea de comandos. Dicho número se almacena en la posición de memoria
asociada a la variable entera x.
A continuación se invoca a la función malloc para reservar N bytes de memoria de forma dinámica
para x& (x-1) elementos de tipo carácter. x& (x-1) es el resultado de realizar la operación AND a nivel
Soluciones completas de los ejercicios
39 1
de bit entre x y x-1. Puesto que x= 25 = 1100 12 y x-1= 24 = 110002 , el resultado de la operación
AND es 1 1000 = 24.
Posteriormente se ejecuta un bucle for mientras la variable h sea menor o igual (x& (x-1) ) -2, es
decir, menor o igual a 22. En cada ejecución del bucle se asigna el carácter nulo '\o' al elemento h de la
cadena de caracteres apuntada por el puntero L.
Luego se invoca a la llamada al sistema open para abrir un archivo ya existente para leer y escribir.
El nombre del fichero es el tercer parámetro (pe [2 l ) de la orden introducida en la línea de comandos, es
decir, wert.txt. Supuesto que la llamada se ejecuta con éxito en la variable a se almacena el descriptor
del fichero.
A continuación se llama a la función try, que primero invoca a la llamada al sistema read para
leer los 15 primeros bytes (byte O a byte 14) del fichero wert.txt y almacenarlos en un espacio de
memoria cuya primera dirección está apuntada por el puntero L. A continuación muestra por pantalla los
15 caracteres leídos. De acuerdo con el contenido del fichero wert.txt mostrado en la Figura 5. 12 y
puesto que cada carácter ocupa 1 byte en la pantalla se muestra el siguiente texto:
"El sistema oper"
Cuando la función try finaliza se invoca la llamada al sistema lseek para desplazar 25 bytes a
partir de un determinado origen el puntero de lectura/escritura asociado al fichero con descriptor a. El
origen para realizar el desplazamiento queda establecido por el valor del resto de la división entera de 25
entre 2. Como el resto de dicha división es 1 lseek avanza 25 bytes desde la posición actual del puntero
de lectura/escritura. Como dicho puntero después de la última lectura se quedó apuntando al byte 15
entonces si lseek se ejecuta con éxito queda apuntando al byte 40.
A continuación se vuelve a llamar a la función try, que primero invoca a la llamada al sistema read
para leer los 15 bytes del fichero wert.txt a partir de la posición actual del puntero de lectura/escritura
(byte 40) y almacenarlos en un espacio de memoria cuya primera dirección está apuntada por el puntero
L. A continuación muestra por pantalla los 15 caracteres leídos. De acuerdo con el contenido del fichero
wert.txt y puesto que cada carácter ocupa 1 byte en la pantalla se muestra el siguiente texto:
"multiusuario y "
Finalmente, se invoca la llamada al sistema exit para finalizar la ejecución del proceso A devol­
viendo como estatus de salida para su proceso padre el valor 3.
Solución Ejercicio 5.5
El comando df proporciona información sobre la utilización del espacio en disco en los diferentes
sistemas de archivos montados en el sistema. Cuando se invoca sin opciones la primera columna de la
salida que se muestra en pantalla muestra el nombre de la partición tal como aparece en el directorio
1 dev, la segunda columna la capacidad total de la partición expresada en número de bloques de 1 KiB,
la tercera columna el número de bloques utilizados, la cuarta el número de bloques libres, la quinta
columna el porcentaje de bloques utilizados con respecto al número total de bloques y la sexta columna
el nombre de ruta del punto de montaje del sistema de archivos.
392
Ampliación de sistemas operativos
Señalar que el valor que se muestra en la tercera columna, es decir, el número de bloques utilizados
no incluye los bloques reservados por el núcleo para optimizar el funcionamiento de las rutinas que
operan sobre el disco. Típicamente el número de bloques reservados suele ser el 10% del total, aunque
este valor puede ser modificado.
A continuación se muestra, a modo de ejemplo, una posible salida del comando df:
Filesystem
1k-blocks
Used Available Use% Mount
/dev/hda2
2949060
2102856
696400
/dev/hda1
23302
2593
19506
75% 1
12% /boot
Aprovechando este ejemplo se puede comprobar que el número de bloques utilizados que se muestra
en la columna Used no incluye los bloques reservados por el núcleo. Por ejemplo para la partición
1 dev /hda2 se comprueba que 2102856+ 696400 = 2799256 que es menor que 2949060. El número de
bloques reservados por el núcleo en esta partición es igual a 2949060 - 2799256 = 149804, es decir, un
5,079% del número total de bloques.
Solución Ejercicio 5.6
El nodo-i de un archivo en un sistema UFS contiene, entre otros datos, la localización de los bloques
de datos del archivo. En concreto contiene 15 direcciones de bloques de disco de 32 bits cada. Las 12
primeras direcciones son las de los 12 primeros bloques de datos del archivo, también denominados
bloques directos. Las tres direcciones restantes localizan a un bloque de indirección simple, un bloque
de indirección doble y un bloque de indirección triple, respectivamente. En el caso de usar un tamaño de
bloque de 8 KiB, en un bloque pueden almacenarse
8 KiB
32 bits/dirección
3
21 bytes
. ,
1 .
4 bytes d1recc10n
=
.
11 .
2 direcciOnes
Con lo que el tamaño máximo de un archivo en teoría podría ser de
A.6.
Soluciones ejercicios capítulo 6
Solución Ejercicio 6.1
a) No es posible, el comando kill solo se puede usar para enviar señales a procesos no a hilos. El
envío de una determinada señal con kill afecta a todos los hilos del proceso no a un hilo concreto.
b) Para enviar señales a un hilo en Linux se puede usar la llamada al sistema tgkill o la función
pthread_kill de la librería Pthreads.
Soluciones completas de los ejercicios
393
Solución Ejercicio 6.2
a) Al contrario de lo que podría pensarse la invocación de la llamada al sistema clone con este bit
únicamente activado hace que la llamada no se ejecute con éxito y devuelva el valor -l.
b) Igual que el apartado anterior.
e) Igual que el apartado anterior.
d) La conclusión que se deduce es que si se desea usar la llamada al sistema clone para crear un
nuevo proceso ligero es necesario invocarla con los tres bits
CLONE_THREAD f CLONE_VM f CLONE_SIGHAND
activados.
Solución Ejercicio 6.3
Este comando en un sistema Linux muestra la siguiente información por cada proceso existente
en el sistema: identificador del proceso ( PID) , terminal de control (TTY) , información sobre su estado
(STAT ) , tiempo de uso del procesador (TIME) y nombre de ruta del programa (COMMAND ) cuya ejecución
ha generado el proceso. Señalar que en el caso de los hilos del núcleo en (COMMAND ) se muestra entre
corchetes el nombre de la rutina del núcleo que ejecuta.
A modo de ejemplo ilustrativo a continuación se reproducen las tres primeras líneas que muestra este
comando al ser ejecutado en un determinado sistema Linux:
PID TTY
STAT
TIME COMMAND
1 ?
Ss
0:00 /sbin/init
2 ?
S
0:00 [kthreadd)
3 ?
S
0:05 [ksoftirqd/O J
Solución Ejercicio 6.4
El comando top muestra información que se actualiza cada pocos segundos sobre el consumo de
recursos (memoria, CPU, etc) que realizan los procesos existentes en el sistema.
La salida por pantalla del comando top puede dividirse en dos partes (ver Figura A.7): la cabecera
y el listado de procesos. La cabecera consta de cinco líneas. En la primera línea se muestra, entre otras
datos, el tiempo que lleva arrancado el sistema, el número de usuarios conectados y la carga promedio.
En la segunda línea se muestra el número de tareas existentes en el sistema en los diferentes estados.
En la tercera línea se muestra información sobre el consumo de CPU. En la cuarta línea se muestra
información sobre el consumo de memoria. Finalmente en la quinta línea se muestra información sobre
el consumo de espacio en el área de intercambio.
El listado de procesos muestra varios datos sobre los procesos que se están ejecutando en el sistema,
entre ellos: su PID, el nombre del usuario al que está asociado, su prioridad, su consumo de CPU,
394
Ampliación de sistemas operativos
su consumo de memoria, su tiempo de ejecución y el nombre de ruta del programa cuyo código está
ejecutando el proceso. Señalar que el listado muestra ordenados a los procesos según su consumo de
CPU lo que puede resultar muy útil al administrador del sistema para detectar a aquellos procesos que
realizan un consumo excesivo de CPU.
top - 16:42:06 up 6 days,
Tasks: 168 total,
Cpu(s): 98.7%us,
7:11,
2 users,
load average: 11.06, 10.97, 9.16
4 running, 163 sleeping,
1.3%sy,
0.0%ni,
O.O%id,
O stopped,
O.O%wa,
1 zombie
O.O%hi,
Mero:
508000k total,
469740k used,
38260k free,
Swap:
522236k total,
44048k used,
478188k free,
O.O%si,
131824k cached
PID USER
PR
NI
VIRT
RES
SHR S
!!CPU
!IMEM
19330 josema
20
O
1700
248
196 R 17.6
0.0
4:10.24 ejemplo6_2
TIME+
COMMAND
19340 josema
20
O
1700
248
196 R 17.6
0.0
4:03.86 ejemplo6_2
19183 josema
20
O 10132
296
232 R
9.0
0.1
4:14.83 ejemplo6_1
19226 josema
20
O 10132
276
216 S
9.0
0.1
3:24.67 ejemplo6_1
19313 josema
20
O 10132
276
216 S
9.0
0.1
2:07.49 ejemplo6_1
19126 josema
20
O 10132
280
216 S
8.6
0.1
11:10.58 ejemplo6_1
19146 josema
20
O 10132
276
216 S
8.6
0.1
5:25.16 ejemplo6_1
19195 josema
20
O 10132
276
216 S
8.6
0.1
3:47.49 ejemplo6_1
19251 josema
20
O 10132
280
216 S
8.6
0.1
2:43.87 ejemplo6_1
20
O 76488
46m 7236 S
1.7
9.4
6:05.50 Xorg
1061 root
O.O%st
19184k buffers
1502 josema
20
O 95040
14m
10m S
1.0
3.0
1:37.97 gnome-terminal
1407 josema
20
O 73308
26m 6784 S
0.3
5.4
11:59.43 ubuntuone-syncd
19363 root
20
O
O
O S
0.3
0.0
0:00.32 kworker/0:1
19428 josema
20
O
2632 1168
864 R
0.3
0.2
0:00.03 top
20
O
3040 1648 1192 S
0.0
0.3
0:00.69 init
1 root
O
Figura A.7- Posible salida del comando top en un sistema Linux
Solución Ejercicio 6.5
a) La estructura de un sistema de archivos EXT2 establece que el mapa de bits de bloques de da­
tos existente en un grupo de bloques ocupa un único bloque. El tamaño de un bloque de 4 KiB
expresado en bits es igual a 32768 bits. Cada bit describe el estado de un bloque del grupo de
bloques, luego en un grupo de bloques pueden existir como máximo 32768 bloques de datos, o
equivalentemente 32 Kibloques.
Multiplicando por el tamaño de un bloque se obtiene finalmente que el tamaño máximo de un
grupo de bloques es igual a
4 (KiB/bloque)·32 Kibloques
=
128 MiB
b) El número de grupos de bloques en que se divide una partición se puede obtener dividiendo el
Soluciones completas de los ejercicios
395
tamaño de la partición por el tamaño de un grupo de bloques determinado en el apartado anterior:
32 GiB
_
128 (MiB/grupo)
- 256 grupos
e) El número de nodos-i que se pueden almacenar en un bloque se determina dividiendo el tamaño
de un bloque por el tamaño de un nodo-i, el cual de acuerdo a la sección 6.6.2 es igual a 128 bytes:
4 (KiB/bloque)
128 (B/nodo)
_
- 32 (nodos/bloque)
d) El nodo-i de un archivo en un sistema EXT2 contiene, entre otros datos, la localización de los
bloques de datos del archivo. En concreto contiene 15 direcciones de bloques de disco de 32 bits
cada. Las 12 primeras direcciones son las de los 12 primeros bloques de datos del archivo, también
denominados bloques directos. Las tres direcciones restantes localizan a un bloque de indirección
simple, un bloque de indirección doble y un bloque de indirección triple, respectivamente. En el
caso de usar un tamaño de bloque de 4 KiB, en un bloque pueden almacenarse
4 KiB
32 bits/dirección
212 bytes
--=---- =
---
4 bytes/dirección
210 direcciones
Con lo que el tamaño máximo de un archivo en teoría podría ser de
A.7.
Soluciones ejercicios capítulo 7
Solución Ejercicio 7.1
a) Esta orden almacena en el archivo listado. txt la salida del comando dir, el cual muestra
información sobre el contenido (archivos y subdirectorios) del directorio de trabajo actual. Señalar
que si el archivo no estaba creado entonces con esta orden se crea. Por otra parte si el archivo ya
estaba creado la información se almacena desde el comienzo del archivo por lo que su contenido
previo se borra.
b) Esta orden utiliza una tubería' 1' para pasar la salida del comando dir como entrada del comando
find 1 I listado El comando dir muestra información sobre el contenido (archivos y sub­
directorios) del directorio de trabajo actual. Por su parte el comando find 1 I 1 istado busca
en la entrada pasada aquellas líneas que contengan la cadena "listado" sin discriminar entre
mayúsculas y minúsculas (opción /I). Si encuentra alguna línea que contenga la palabra buscada
la muestra en la pantalla.
11
11•
11
11
e) Esta orden borra en el directorio de trabajo actual todos los archivos con la extensión . txt.
396
Ampliación de sistemas operativos
Solución Ejercicio 7.2
Se debe escribir la orden
attrib +R +H tabla.txt
Solución Ejercicio 7.3
El byteO de la cabecera del bloque tiene el valor 7 7 lo que significa que no es el último bloque de la
cadena de bloques de memoria. Los bytes 1 y 2 contienen el valor O O o O lo que significa que es un bloque
ocupado y que su puntero al bloque PSP esO. Finalmente los bytes 3 y 4 contienen el valor 0003 lo que
significa que el bloque contiene tres parágrafos.
Solución Ejercicio 7.4
a) En un sistema FAT- 12 se utilizan 12 bits para direccionar un cluster, luego el número total de
clusters que puede tener un volumen es 212 . Multiplicando el número de clusters por el tamaño de
un cluster y por el tamaño de un sector se obtiene el tamaño del volumen:
25
212 (clusters)·24 (sectores/cluster)-29 (bytes/sector) = 2 bytes = 32 MiB
b) En un sistema FAT- 12 la tabla de asignación de archivos tiene una entrada por cada cluster exis­
tente en el volumen, luego de acuerdo con el apartado anterior tendrá 212 entradas. Por otra parte
cada entrada debe ser capaz de almacenar la dirección de un cluster luego debe tener un tamaño
mínimo de 12 bits. El tamaño de la tabla de asignación de archivos de un sistema FAT- 12 se obtiene
multiplicando el número de entradas de la tabla por el tamaño de una entrada:
2
12
(entradas)· 12 (bits/entrada) = 48 Kib = 6 KiB
Solución Ejercicio 7.5
a) En un sistema de archivos FAT- 12 se utilizan 12 bits para especificar la dirección de un cluster.
Luego el espacio posible de direcciones consta de 212 = 4096 direcciones. Sin embargo, no todas
las direcciones se encuentran disponibles para especificar los siguientes clusters donde se alojan los
datos de un archivo. De acuerdo con la sección 7.6. 1 siete direcciones (FFO- FF6) están reservadas
para clusters utilizados por estructuras del sistema de archivos, una dirección (FF7) está reservada
para especificar que un cluster está defectuoso, una dirección (000) está reservada para especificar
que un cluster está libre y 8 direcciones (FF8-FFF) están reservadas para especificar el final de un
archivo o directorio.
Luego hay un total de 17 direcciones reservadas, lo que dejaría un total de 4096 - 17 = 4079
direcciones disponibles para especificar los siguientes clusters donde se alojan los datos de un
archivo.
Soluciones completas de los ejercicios
397
Por lo tanto, un archivo como máximo puede ocupar 4080 clusters, el cluster del primer bloque,
que se direcciona en la entrada del directorio asociada al archivo, y 4079 en la FAT. Como cada
bloque ocupa 2 KiB, el tamaño máximo que puede tener un archivo es:
4080·2 KiB = 8 160 KiB = 7,97 MiB
b) En un sistema FAT- 12 una entrada de un directorio ocupa 32 bytes. El número de entradas de
directorio que caben en un cluster de 2 KiB se calcula de la siguiente forma:
2 (KiB/cluster)
211 (bytes/cluster)
= s
= 64 (entradas/cluster)
32 (bytes/entrada)
2 (bytes/entrada)
e) El número de segundos que tiene un día se calcula de la siguiente forma:
24 (horas/dia)·60 (minutos/hora)·60 (segundos/minuto)
=
86400 segundos
En la sección 7.6.2 se indica que el campo hora de una entrada de un directorio tiene un tamaño de
2 bytes = 16 bits, con los cuales se pueden codificar 216 = 65536 segundos. La precisión se puede
determinar de la siguiente forma:
ceil
A.S.
( �����)
= ceil(l,32) = 2 segundos
Soluciones ejercicios capítulo 8
Solución Ejercicio 8.1
a) La prioridad base de un proceso Pbp es función de la clase de planificación a la que pertenece el
proceso. Por defecto la prioridad base de un proceso que pertenece a la clase de planificación alta
es Pbp = 13.
b) La prioridad base de un hilo Pbh es función de la clase de planificación a la que pertenece el proceso
al que está asociado el hilo y de la prioridad relativa del hilo Pr respecto a Pbp· Cuando la prioridad
relativa Pr se configura al valor debajo de normal (Pr = - 1) entonces la prioridad base del hilo se
calcula mediante la siguiente expresión:
Pbh = Pbp+ Pr
Sustituyendo valores en la expresión anterior y operando se obtiene finalmente que
Pbh = 13 - 1 = 12
e) Por defecto la prioridad actual del hilo Pa es igual a la prioridad base del hilo Pbh· Luego de
acuerdo con el apartado anterior Pa=12.
398
Ampliación de sistemas operativos
Solución Ejercicio 8.2
a) Esta orden crea en el directorio de trabajo actual un enlace duro de nombre enlacel. txt al
archivo \trabajo\listado.txt.
b) Esta orden crea en el directorio de trabajo actual un enlace simbólico de nombre fotos al direc­
torio e: \imagenes\fotos\camara.
Solución Ejercicio 8.3
La siguiente secuencia de órdenes en un intérprete cmd.exe de Windows permite ilustrar que un
archivo en NTFS puede constar de múltiples flujos de datos:
echo Este es el primer flujo de datos del archivo > prueba.txt
echo Este es el segundo flujo de datos > prueba.txt:flujo2.txt
notepad prueba.txt
notepad prueba.txt:flujo2.txt
Solución Ejercicio 8.4
La información relativa a la localización de las series del atributo de datos del archivo que se al­
macena en la entrada asociada al archivo en la MFT del volumen es la que se muestra en la siguiente
tabla:
Cluster Virtual Bv
Cluster Lógico BL
Número de clusters N
o
3
7
9
61
90
85
1 12
3
4
2
1
Solución Ejercicio 8.5
La información relativa a la localización de las series del atributo de datos del archivo que se al­
macena en la entrada asociada al archivo en la MFT del volumen es la que se muestra en la siguiente
tabla:
Cluster Virtual Bv
Cluster Lógico BL
Número de clusters N
o
8
16
32
40
40
o
50
95
o
8
8
16
8
8
Soluciones completas de los ejercicios
399
Señalar que las entradas con BL = O indican que los clusters virtuales correspondientes no tienen
asignado espacio físico puesto que han desaparecido al ser comprimidos. Windows necesita mantener
esta información para poder realizar la descompresión del archivo.
Solución Ejercicio 8.6
Entre las herramientas software más conocidas para analizar el funcionamiento y el rendimiento del
sistema operativo Windows se encuentran las siguientes:
•
•
•
Herramientas que se distribuyen conjuntamente con Windows. Como el administrador de tareas,
el monitor de recursos y el control de servicios.
Herramientas de depuración para Windows (debugging tools for Windows) de Microsoft. Como el
depurador del núcleo o la lista de tareas.
Herramientas de Windows Sysinternals. Como el explorador de procesos y el monitor de procesos.
Bibliografía
[Bach,
1986] J. M. Bach, The Design of the UNIX Operating System, Prentice-Hall, 1986.
[Bonwick, 1994] J. Bonwick. The Slab Allocator: An Object-Caching Kernel Memory Allocator,
Proceedings of the Summer 1994 USEN/X Technicaleonference, Jun. 1994, pp. 87-94.
[Bovet y Cesati,
O'Reilly, 2005.
[Cooper,
2005] D. P. Bovet y M. Cesati, Understanding the Linux Kernel (3rd Edition),
2002] J. Cooper, Special Edition Using MS-DOS 6. 22 (3rd Edition), Que, 2002.
[Cormen et al.,
2009] T. H. Cormen, C. E. Leiserson, R. L. Rivest y C. Stein, Introduction to
Algorithms (9th Edition), MIT Press, 2009.
[Díaz et al., 201 1] J. M. Díaz, D. Chaos, R. Muñoz y J. Aranda, Fundamentos Básicos de los
Sistemas Operativos, Sanz y Torres, 20 11.
[Dijkstra, 1965] E. Dijkstra, "Co-operating Sequential Processes", Programming Languages, Aca­
demic Press, 1965.
[Duncan,
1988.
1988] R. Duncan, MS-DOS Encyclopedia: Versions 1. 0 Through 3. 2, Microsoft Press,
[Duncan, 1988b] R. Duncan, Advanced MS-DOS Programming: The Microsoft Guide for As­
sembly Language ande Programmers, Microsoft Press, 1988.
[Gottfried,
[Hart,
2005] B. S. Gottfried, Programación ene (2° Edición), McGraw-Hill, 2005.
2010] J. M. Hart, Windows System Programming (4th Edition) (Addison-Wesley Microsoft
Technology Series), Addison-Wesley, 2010.
[Kemighan y Ritchie,
Prentice Hall, 199 1.
1991] B. W. Kernighan y D. Ritchie, El Lenguaje de Programación e,
[Love, 2010] R. Love. Linux Kernel Development (3rd Edition), Addison-Wesley Educational Pu­
blishers Inc, 20 10.
401
402
Ampliación de sistemas operativos
[Love et al.,
2005] P. Love, J. Merlino, C. Zimmerman, J. C. Reed y P. Weinstein. Beginning Unix
(Programmer to Programmer), Wiley, 2005.
[Márquez,
2004] F. Márquez, UNIX. Programación Avanzada (3° Edición), Ra-Ma, 2004.
[Mathur et al., 2007] A. Mathur, M. Cao, S. Bhattacharya, A. Dilger, A. Tomas y L. Vivier, " The
New ext4 Filesystem: Current Status And Future Plans", Proceedings of the Linux Symposium,
vol.2, pp.2 1-33, junio 2007, Ottawa, Ontario (Canada).
[Mauerer,
2008.
2008] W. Mauerer, Professional Linux Kernel Architecture, John Wiley & Sons Ltd,
[McDougall y Mauro,
Hall, 2006.
[McHoes y Flynn,
2006] R. McDougall y J. Mauro, Solaris Internals, 2nd Edition, Prentice
2010] A. McHoes e l. M. Flynn, Understanding Operating Systems (6th Edi­
tion), Course Technology, 20 10.
[Podanoffsky,
1994] M. Podanoffsky, Dissecting DOS: A Code-Level Look at the DOS Operating
System, Addison-Wesley, 1994.
[Richter y Nasarre,
2007] J. M. Richter y C. Nasarre, Windows via C/C++ (Pro - Developer),
Microsoft Press, 2007.
[Ritchie y Thompson,
1974] D. M. Ritchie y K. Thompson, "The UNIX Timesharing System",
Communications of the Association for Computing Machinery, vol. 17, pp. 365-375, julio 1974.
[Russinovich et al.,
2009] M. Russinovich, D. A. Solomon y A. Ionescu, Windows@ Internals:
Including Windows Server 2008 and Windows Vista, Fifth Edition (Pro Developer), Microsoft
Press, 2009.
[Silberschatz et. al, 2002] A. Silberschatz, P. B. Galvin y G. Gagne, Sistemas Operativos (6a
Edición), Limusa Wiley, 2002.
[Stallings, 2005] W. Stallings, Sistemas Operativos: Aspectos Internos y Principios de Diseño (5a
Edición), Pearson Educación, 2005.
[Tanenbaum,
2009] A. S. Tanenbaum, Sistemas Operativos Modernos (3° Edición), Pearson­
Prentice Hall, 2009.
[Vahalia,
1995] U. Vahalia, UNIX Internals: The New Frontiers, Prentice Hall, 1995.
,
Indice alfabético
A
Á rea
Administrador
de memoria, 328
de objetos, 3 1 1
Afinidad del procesador, 324
de intercambio, 174
de programas transitorios, 28 1, 286
de usuario, 5 1
Arena, 286
Array
de descriptores de página, 253
de referencias a estructuras anon, 157
Asignación índice, 348
Asignador
a nivel de página, 172
de la memoria del núcleo, 172, 178
slab, 179, 258
Atributo
no residente, 345
residente, 345
Atributos del archivo, 189, 289
AIX, 4, 5
Alarm, 68
Alarmas, 68
Algoritmo
buddy, 254, 257
CFS, 248
del último ajuste, 286
del mejor ajuste, 286
del primer ajuste, 286
del reloj con dos manecillas, 169
LRU, 169, 18 1
PFRA, 259
Alias, 13
Almquist shell, 8
Apuntador, 14
Á rbol
de directorios, 289
rojo-negro, 249
Archivo
binario, 188
de registro, 343
mapeado en memoria, 149
ordinario, 188
regular, 188
de páginas, 339
de solo-añadir, 267
inmutables, 267
B
Base de datos del distribuidor, 322
Bind, 224
BIOS, 276
Bit pegajoso, 28
Bloque
de arranque, 264
de control del archivo, 287, 349
de control del flujo, 349
de control del proceso, 3 15
EPROCESS, 315
ETHREAD, 3 16
KPROCESS, 315
KTHREAD, 3 15
W32PROCESS, 315
403
404
Ampliación de sistemas operativos
W32THREAD, 3 16
Bloques buddies, 258
Bloques directos, 2 10, 392, 395
Bonus, 247
Bourne shell, 8
Bourne-Again shell, 8
Brk, 145
BSD, 3
BSD 4.3, 96
Buffering, 294
Buffers índices, 348
Clone, 239
Clase, 193
CloseHandle, 339
Cluster, 290, 341
Código
de finalización o retorno, 284
reentrante, 1 10
Colas
de prioridad, 95
de mensajes, 1 19, 124
de tareas activas, 243
hash, 2 12
e
Com, 283
e shell, 8
Comando
Caché
externo, 14
de búsqueda de nombres en directorios, 262
interno, 14
de buffers de bloques de disco, 2 19, 294
Command.com, 279
de nombres en directorios, 208
Comodines, 11
de páginas, 220
Conectores, 135, 222
del sistema, 305
Conjunto de trabajo de un proceso, 335
Callouts, 96
Connect, 224
Cambios de contexto, 94
Contexto hardware salvado, 5 1
Canal
Copiar a l escribir, 62, 148, 156, 160
de dormir, 1 16
Copy_process(), 240
de espera, 1 16
CP/M, 274
Capa
Creat, 192
anónima, 157
Create, 198
H AT, 164
CreateDirectory, 340
nodo virtual/sistema de archivo virtual, 24, 202 CreateFile, 339
swapfs, 174
Credenciales, 50
V FS, 262
Cuotas, 68, 10 1
Cerrojo, 1 1 1
D
Cerrojo
exclusivo, 1 13
Datagrama, 223
lector 1 escritor, 1 13
Dato de reanálisis, 343
mutex, 1 13
DeleteFile, 340
Chdir, 196
Demanda de página, 328
Chown, 28
Demonio de páginas, 170
Clases de planificación, 95, 247
Descriptor
de archivo, 24, 190
Claves raíz, 308
Cliente X, 19
de direcciones virtuales, 33 1
Índice alfabético
de grupo, 264
de nodo, 254
de página, 253
de zona, 254
del objeto, 3 1 1
del proceso, 234
Despachador de llamadas al sistema, 308
Despertar, 1 16
Df, 201
Diario, 267
Diario de cambios, 343
Directorio
de páginas, 332
de páginas global, 256
Dispadmin, 103
Dispositivo
cero, 2 16
nulo, 2 16
Distribuciones de Linux, 233
Distribuidor o despachador del núcleo, 323
DLL, 304
Do_fork(), 240
Dormir, 116
Driver
del dispositivo, 2 16, 220
del segmento, 153
del sistema de archivos, 340
instalable, 279, 294
residente, 276, 294
Dup, 19 1
Dup2, 19 1
E
EGID, 32
Enlaces
duros, 197, 343
simbólicos, 198
simbólicos rápidos, 267
Entorno, 60
Entorno
de escritorio, 2 1
del proceso, 16
Entradas de tamaño variable, 265
Env, 16
Ermo, 23
Escáner de paginas, 170
Espacio de nombres, 3 1 1
Estado
de un proceso, 50
no señalado, 325
señalado, 325
Estatus de salida, 63, 365
EUID, 32
Eventos, 325, 326
Excepciones, 68, 294
Exe, 283
Exec, 51, 54, 60, 159
Exit, 63, 159
Exit(), 64
Export, 16
EXT, 263
EXT2, 263
EXT3, 267
EXT4, 268
Extend, 268
Extensión de dirección física, 332
F
Factor de decadencia, 96
Fallo
de página, 144, 163, 165, 334
de página duro, 335
de página suaves, 335
de protección, 162
Fcntl, 194
FFS, 202
PIFOs, 135
Fork, 56, 159, 160, 239
Fragmentos de archivos, 268
FreeBSD, 4
Fsck, 20 1
Ftok, 1 19, 126
405
406
Ampliación de sistemas operativos
Función de envoltura o redireccionamiento, 22
Funciones del sistema, 277
G
Gestor
de archivos, 22
de control de servicios, 303
de los conjuntos de trabajo, 335
de ventanas, 22
GetFileAttributes, 340
Getpgid, 79
Getpgrp, 79
Getpid, 58
Getppid, 58
Getsid, 80
GID, 25
GNU, 4
Grupo
de hilos, 234
de procesos, 79
propietario, 28
H
Hilo de puesta de página a cero, 338
Hilos, 46
Hilos
de control, 46
de usuario, 47
del núcleo, 47, 240
HP-UX, 4, 5
1
Identificador de grupo, 25
de grupo de hilos, 236
de grupo de tareas, 235
de grupo efectivo, 32
de la clase de planificación, 100
de sesión, 80
de tarea, 235
de usuario, 25
de usuario efectivo, 32
del grupo de procesos, 79
del hilo, 235
del proceso, 50
numérico del proceso ligero, 82
Identificadores
efectivos, 32
reales, 26
Init, 64
Instrucción comprobar y configurar, 1 1 1
Intérprete de comandos, 7 , 279
Interfaz
de línea de comandos, 279
IFS, 289
Inversión de prioridad, 99
Ipcrm, 128, 133
Ipcs, 128, 133
Issig(), 73
J
Joumal, 267
K
Kill, 68, 71
Kom shell, 8
L
Ladrón de páginas, 170
Latencia de despacho, 103
Libe, 22
Librería
e estándar, 22
de enlace dinámico, 304
de hilos, 47, 76
Líder
de la sesión, 80
del grupo, 79
Link, 198
Linux, 4, 5, 232
Lista
de atributos, 345
de marcos de página activos, 259
de marcos de página inactivos, 259
de marcos de página libres, 167
Índice alfabético
de marcos en standby, 337
de marcos inicializados aO, 337
de marcos libres, 337
de marcos modificados, 337
de nodos-im libres, 212
de procesos, 236
de tareas, 236
Listas LRU, 259
Listen, 224
Llamadas
a procedimientos locales avanzados, 305
a procedimientos remotos, 328
a procedimientos remotos avanzados, 328
al sistema, 22
Llave, 308
Llave IPC, 119
Lockf, 194
Ls, 189
Lseek, 24, 148, 193
LSI, 274
M
Mac OS X, 4, 5
Mailslots, 328
Malloc, 145
Manejador
de archivo, 288
de fallos de página, 165
de la interrupción, 216, 222
de la señal, 69
de llamadas al sistema, 22
Mapa de intercambio, 174
Marcos bloqueados, 167
Máscara
de modo, 27
simbólica, 29
Mecanismos IPC, 119
Memoria
anónima, 156
compartida, 119, 129
local, 252
MINIX, 4, 5
Mkdir, 197, 198
Mkfifo, 135
Mkfs, 200
Mknod, 135
Mmap, 149
MMU, 161
Mnttab, 200
Modelo de drivers de Windows, 352
Modificadores, 279
Monitor
de procesos, 3 10
de referencia de seguridad, 3 13
Monotarea, 283
Montículo, 146
Mount, 200
MS-DOS, 274
Msgctl, 126
Msgget, 125
Msgrcv, 125
Msgsnd, 125
Mtab, 200
MULTICS, 2
Munmap, 150
Mutex, 113
Mutexes, 325
N
NetBSD, 4
Netware, 4
Nice, 95, 97, 242, 246
Nivel
de petición de interrupción, 354
de prioridad de la interrupción, 221
pasivo, 354
Nodo
índice, 204
sombra, 219
virtual, 24, 191, 203
Nodo-im, 212
Nodos de memoria, 252
407
408
Ampliación de sistemas operativos
NTFS, 341
Número
de archivo, 345
Número
de dispositivo, 2 18
de dispositivo mayor, 2 17
de dispositivo menor, 217
de secuencia, 345
o
Objeto
anónimo, 153
de archivo abierto, 24, 190
de archivo mapeado, 332
de datos, 152
del núcleo, 3 1O
dispositivo, 353
driver, 35 1, 353
sección, 328
Objetos del distribuidor, 325
Open, 24, 34, 148, 190, 193
OpenBSD, 4
OpenServer, 4
OpenSolaris, 4
p
Página anónima, 155
Paginación por demanda, 144
Paquete de petición de E/S, 35 1
Parámetros de planificación, 243
Párrafo, 286
Particionamiento dinámico, 286
Passwd, 32
Pause, 69
PEB, 3 14
PGID, 79
PID, 50
Pila
de usuario, 5 1, 146
del núcleo, 51, 53, 234, 238
Pipe, 134
Planificador
central, 247, 248
de memoria, 17 1
0(1), 242
Pmap, 8 1, 147
POSIX, 5
Primer plano, 14
Priocntl, 95, 105
Prioridad
actual del hilo, 321
base del hilo, 320
base del proceso, 320
de usuario, 105
dinámica, 245, 247
en modo usuario, 105
estática, 245
relativa del hilo, 320
Procesadores virtuales, 47
Proceso, 46
Proceso
hijo, 56
inicial, 64
intercambiador, 171
monohilo, 47
multihilo, 47
padre, 56
TSR, 284
del sistema, 240
ligero, 47
Procfs, 50
Programa
de acceso, 33
de login, 33
transitorio, 28 1
Protocolo X, 20
Prstat, 83
Ps, 8 1-83
Pseudodispositivos, 216
Pseudoterminales, 79
Psig(), 73
Índice alfabético
Pthreads, 47, 76
Ptrace, 234
Punto
de montaje, 200
de reanálisis, 343
R
Raíz índice, 348
Read, 23, 148, 193
ReadFile, 340
Readv, 224
Recv, 224
Recvfrom, 224
Recvmsg, 224
Redireccionamiento de la E/S, 12
Reemplazamiento de páginas, 168
Referencia del archivo, 345
Región de texto, 145
Regiones de memoria compartida, 146
Registro
de archivo, 345
de archivo base, 345
de estado del procesador, 222
por diario, 2 10, 267
RemoveDirectory, 340
Rename, 209
Reserva retrasada de espacio, 268
Resumen de preparados, 322
Rmdir, 197
Root, 25
Runqueue, 243
S
S5FS, 202
S_ISGID, 28
S_ISUID, 28
S_ISV TX, 28
Símbolo del sistema, 275
Sbrk, 145
Sched_setparam, 242
Sched_setscheduler, 242
Sched_yield, 245
SCO Xenix, 3
Señales, 67, 1 19, 133
Secciones, 9
Segmento, 152
Segundo plano, 14
Semáforo
binario, 1 13, 325
con contador, 114
general, 114
Semáforos, 119, 120, 325
Semctl, 12 1
Semget, 120
Semop, 120
Send, 224
Sendmsg, 224
Sendsig(), 73
Sendto, 224
Serie, 345
Servicios, 303
Servicios del sistema, 307
Servidor X, 19
Sesión, 80
Set, 15
SetCurrentDirectory, 340
SetFilePointer, 340
Setpgid, 80
Setpgrp, 80
Setpriority, 242, 246
Setsid, 80
Shell, 7
Shell script, 17
Shmat, 129
Shmctl, 130
Shmdt, 130
Shmget, 129
SID, 80
Sigaction, 69
Sigblock, 69
Sigmask, 69
409
410
Ampliación de sistemas operativos
Signal, 69
T
Sigpause, 69
Tabla
de archivo del sistema, 288
de archivos, 288
de colas de mensajes, 125
de descriptores, 3 1 1
d e descriptores de archivos, 24, 190
de descriptores de grupo, 264
de despacho, 103
de despacho de llamadas al sistema, 308
de llamadas al sistema, 22
de manejadores de archivos, 288
de montaje, 200
de nodos-i, 262
de página, 16 1
de página prototipo, 336
de procesos, 49
de conmutación, 22 1
Tarea, 233
Tareas
convencionales, 241
de tiempo compartido, 241
de tiempo real, 242
Task_struct, 234
TEB, 3 15
TENEX C shell, 8
Terminal serie, 79
Terminales emulados, 79
TGID, 236
Thread_info, 234
Tipo
del mensaje, 124
del objeto, 3 10
Top, 393
Trabajo, 14
Trampa, 22, 308
Transacciones atómicas, 343
Tuberías, 13, 1 19, 134
Tuberías
con nombre, 135
Sigsend, 68
Sigsetmask, 69
Sigsuspend, 69
Sigvec, 69
Sistema
buddy, 179
de archivos de procesos, 8 1
de archivos extendido, 263
de archivos virtual, 202, 206
de paginación, 172
de ventanas, 19
X Window, 19
Socket, 222
Solaris, 4, 5, 99
Source, 17
Spinlocks, 1 1 1, 325
Spooling, 292
Stat, 193, 194
STREAMS, 132, 135
Strsignal, 73
SUA, 304
Subárboles, 308
Subintérprete, 18
Subllave, 308
Subsistema
de administración de memoria, 144
de E/S, 2 16, 2 19, 35 1
de entorno, 304
SunOS, 4
Superbloque, 209
SuperFetch, 335
Superusuario, 25
SUS, 5
Swapfs, 174
Symlink, 198
Syscall(), 22
System V, 3
Índice alfabético
sin nombre, 134
Turno rotatorio, 245
Turnstile, 117
Type, 14
u
UID, 25
Umount, 200
Unalias, 13
Unidad de gestión de memoria, 144
UnixWare, 4
Unlink, 199
Unset, 16
V
Valor amable, 97, 246
Variable
de entorno, 16, 60
del intérprete de comandos, 15
V fork, 62, 239
V FS, 202
Violación de acceso, 33 1
V M, 152
w
Wait, 65
Wait3, 65
Wait4, 65, 234, 235
Waitid, 65
Waitpid, 65, 234, 235
Widgets, 2 1
Widgets toolkits, 2 1
Windows, 300
Windows NT, 30 1
W rite, 23, 148, 193
W riteFile, 340
W ritev, 224
X
X Toolkit Intrinsics, 2 1
Xenix, 3
Xlib, 20
z
Z shell, 8
ZFOD, 156
Zona roja, 177
Zonas, 253
411
