Sistema So Perati Vos

Instituto Tecnológico de Apizaco
Departamento de Sistemas y Computación
Ingeniería en Tecnologías de la Información y Comunicaciones
Sistemas Operativos I
M. en C. Nicolás Alonzo Gutiérrez
Apizaco Tlax. Enero del 2018

Índice general
Índice general I
Índice de tablas XI
Índice de figuras XIII
Introducción XVII
1. Introducción a los Sistemas Operativos 1

1.1. Definición, y concepto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1. Definiciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1.1. Tipos de usuarios de un sistema operativo . . . . . . . . . . 3
1.1.1.2. Arquitectura de una Computadora . . . . . . . . . . . . . . . 7
1.1.1.3. Proceso de arranque de una computadora . . . . . . . . . . . 16
1.2. Funciones y características . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.2.1. Administración de procesos . . . . . . . . . . . . . . . . . . . . . . . 18
1.2.1.1. Concepto de proceso . . . . . . . . . . . . . . . . . . . . . . 18
1.2.1.2. Planificación de procesos . . . . . . . . . . . . . . . . . . . 19
1.2.1.3. Operaciones sobre procesos . . . . . . . . . . . . . . . . . . 20
1.2.2. Planificación de CPU . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.2.2.1. Planificador a corto plazo. . . . . . . . . . . . . . . . . . . . 21
1.2.2.2. Planificador a largo plazo. . . . . . . . . . . . . . . . . . . . 21
1.2.3. Administrador de memoria . . . . . . . . . . . . . . . . . . . . . . . . 22
1.2.3.1. Funcionamiento básico de la memoria . . . . . . . . . . . . 22
1.2.3.2. Reasignación de direcciones . . . . . . . . . . . . . . . . . . 23
1.2.3.3. Espacio de direcciones lógico y físico . . . . . . . . . . . . . 24
1.2.3.4. Memoria virtual . . . . . . . . . . . . . . . . . . . . . . . . 24
1.2.3.5. Asignación de memoria contigua . . . . . . . . . . . . . . . 24
I
II ÍNDICE GENERAL
1.2.3.6. Asignación de memoria por páginas . . . . . . . . . . . . . 25

1.2.4. Administrador de dispositivos . . . . . . . . . . . . . . . . . . . . . . 26
1.2.5. Administrador del sistema de archivos . . . . . . . . . . . . . . . . . . 28
1.3. Evolución histórica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
1.3.1. Historia de los sistemas operativos . . . . . . . . . . . . . . . . . . . . 31
1.3.2. Evolución de los Sistemas Operativos . . . . . . . . . . . . . . . . . . 34
1.3.2.1. Sistemas dedicados . . . . . . . . . . . . . . . . . . . . . . 34
1.3.2.2. Sistemas por lotes . . . . . . . . . . . . . . . . . . . . . . . 35
1.3.2.3. E/S compartida . . . . . . . . . . . . . . . . . . . . . . . . 35
1.3.2.4. Entornos de tiempo compartido . . . . . . . . . . . . . . . . 37
1.4. Clasificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
1.4.1. Sistemas por lotes sencillos . . . . . . . . . . . . . . . . . . . . . . . 38
1.4.2. Sistemas por lotes multiprogramados . . . . . . . . . . . . . . . . . . 39
1.4.3. Sistemas de tiempo compartido . . . . . . . . . . . . . . . . . . . . . 39
1.4.4. Sistemas operativos de red . . . . . . . . . . . . . . . . . . . . . . . . 40
1.4.4.1. El modelo cliente servidor . . . . . . . . . . . . . . . . . . . 40
1.4.5. Sistemas de computadora personal . . . . . . . . . . . . . . . . . . . . 42
1.4.6. Sistemas operativos de computadoras de bolsillo . . . . . . . . . . . . 43
1.4.7. Sistemas paralelos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
1.4.8. Sistemas distribuidos . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
1.4.8.1. Ventajas de los SD con respecto a los centralizados: . . . . . 44
1.4.8.2. Desventajas de los sistemas distribuidos . . . . . . . . . . . 45
1.4.9. Sistemas operativos multiprocesadores . . . . . . . . . . . . . . . . . 45
1.4.10. Sistemas de tiempo real . . . . . . . . . . . . . . . . . . . . . . . . . 45
1.5. Estructura: niveles o estratos de diseño . . . . . . . . . . . . . . . . . . . . . . 46
1.5.1. Estructura única . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
1.5.2. Estructura por niveles . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
1.6. Núcleo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
1.6.1. Kernel Modular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
1.6.2. Análisis de los Sistemas Operativos más Comerciales . . . . . . . . . . 54
1.6.3. GNU/Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
1.6.3.1. Breve historia de GNU/Linux . . . . . . . . . . . . . . . . . 55
1.6.3.2. El núcleo de Linux . . . . . . . . . . . . . . . . . . . . . . . 56
1.6.3.3. El Sistema GNU/Linux . . . . . . . . . . . . . . . . . . . . 57
1.6.3.4. Distribuciones más Importantes de GNU/Linux . . . . . . . 57
1.6.4. Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
ÍNDICE GENERAL III
1.6.5. MacOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
1.6.5.1. La fundación UNIX: el kernel Darwin y BSD . . . . . . . . 63
1.6.6. Windows 2003 Server . . . . . . . . . . . . . . . . . . . . . . . . . . 65
1.6.6.1. Un poco de historia . . . . . . . . . . . . . . . . . . . . . . 65
1.6.6.2. Características importantes . . . . . . . . . . . . . . . . . . 67
1.6.7. Consideraciones finales . . . . . . . . . . . . . . . . . . . . . . . . . . 68
1.7. Problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
1.8. Lecturas adicionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
2. Administración de procesos y del procesador 73

2.1. Concepto de proceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
2.2. Estados y transiciones de un proceso. . . . . . . . . . . . . . . . . . . . . . . . 74
2.2.1. El Estado de Suspendido . . . . . . . . . . . . . . . . . . . . . . . . . 78
2.2.2. El bloque de control de procesos . . . . . . . . . . . . . . . . . . . . . 79
2.2.2.1. Relaciones entre procesos . . . . . . . . . . . . . . . . . . . 80
2.2.2.2. Operaciones sobre los procesos . . . . . . . . . . . . . . . . 80
2.3. Procesos ligeros: Hilos o hebras . . . . . . . . . . . . . . . . . . . . . . . . . 83
2.3.1. Ventajas de la programación multi hilo . . . . . . . . . . . . . . . . . 84
2.3.2. Implementación de hilos en GNU/Linux . . . . . . . . . . . . . . . . . 84
2.3.3. Consideraciones finales . . . . . . . . . . . . . . . . . . . . . . . . . . 86
2.3.3.1. Eliminación de hilos . . . . . . . . . . . . . . . . . . . . . . 87
2.4. Concurrencia y secuenciabilidad . . . . . . . . . . . . . . . . . . . . . . . . . 87
2.4.1. Definiciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
2.4.2. Principios generales de la concurrencia . . . . . . . . . . . . . . . . . 89
2.4.3. La sección crítica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
2.4.4. Exclusión mutua; solución por hardware y software . . . . . . . . . . . 90
2.4.4.1. Inhabilitación de interrupciones . . . . . . . . . . . . . . . . 91
2.4.4.2. Instrucciones especiales de hardware . . . . . . . . . . . . . 91
2.4.4.3. Propiedades de las soluciones con instrucciones de máquina . 94
2.4.5. Semáforos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
2.4.5.1. Algoritmo para un semáforo binario . . . . . . . . . . . . . 98
2.4.6. Monitores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
2.4.6.1. Monitores con Señales . . . . . . . . . . . . . . . . . . . . . 100
2.4.6.2. Monitores con Notificación y Difusión . . . . . . . . . . . . 101
2.4.7. Paso de mensajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
2.4.7.1. Operaciones típicas de los mensajes . . . . . . . . . . . . . . 103
IV ÍNDICE GENERAL
2.4.7.2. Comunicación y sincronización interprocesos con mensajes . 107

2.4.7.3. Envío de señales de interrupción con mensajes . . . . . . . . 109
2.4.8. Concurrencia e interbloqueo (deadlock) . . . . . . . . . . . . . . . . . 109
2.4.9. Principios del interbloqueo . . . . . . . . . . . . . . . . . . . . . . . . 110
2.4.10. Acciones a realizar ante un interbloqueo . . . . . . . . . . . . . . . . . 112
2.4.11. Recursos reutilizables y consumibles del sistema . . . . . . . . . . . . 112
2.4.11.1. Prevención de interbloqueos . . . . . . . . . . . . . . . . . . 113
2.4.11.2. Evitar interbloqueos . . . . . . . . . . . . . . . . . . . . . . 115
2.4.11.3. Detección y recuperación de interbloqueos . . . . . . . . . . 120
2.5. Niveles, objetivos y criterios de planificación . . . . . . . . . . . . . . . . . . 122
2.5.1. Planeación de trabajos . . . . . . . . . . . . . . . . . . . . . . . . . . 122
2.5.2. Conceptos básicos de planificación . . . . . . . . . . . . . . . . . . . 122
2.5.2.1. Ciclos de CPU y ciclos de entrada/salida . . . . . . . . . . . 123
2.5.3. Niveles de planificación . . . . . . . . . . . . . . . . . . . . . . . . . 123
2.5.3.1. Planificación apropiativa . . . . . . . . . . . . . . . . . . . 123
2.5.4. Objetivos y criterios de planificación . . . . . . . . . . . . . . . . . . . 124
2.6. Técnicas de administración del planificador . . . . . . . . . . . . . . . . . . . 125
2.6.1. Tipos de planeación . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
2.6.1.1. Planificador a largo plazo . . . . . . . . . . . . . . . . . . . 125
2.6.1.2. Planificador a mediano plazo . . . . . . . . . . . . . . . . . 126
2.6.1.3. Planificador a corto plazo . . . . . . . . . . . . . . . . . . . 126
2.6.1.4. First In First Out (FIFO) . . . . . . . . . . . . . . . . . . . . 128
2.6.1.5. Round Robin (RR) . . . . . . . . . . . . . . . . . . . . . . . 130
2.6.1.6. Shortest Job First (SJF) . . . . . . . . . . . . . . . . . . . . 132
2.6.1.7. Shortest Remaining Time (SRT) . . . . . . . . . . . . . . . 133
2.6.1.8. Highest Response Ratio Next (HNR) . . . . . . . . . . . . . 134
2.6.2. Multiprocesamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
2.6.3. Conceptos básicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
2.6.3.1. multiprocesador . . . . . . . . . . . . . . . . . . . . . . . . 135
2.6.4. Paralelismo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
2.6.5. Paralelismo por hardware . . . . . . . . . . . . . . . . . . . . . . . . 137
2.6.5.1. Paralelismo por software . . . . . . . . . . . . . . . . . . . 138
2.6.6. Sistemas multiprocesamiento . . . . . . . . . . . . . . . . . . . . . . 140
2.6.6.1. Ventajas de los sistemas multiprocesadores . . . . . . . . . . 141
2.6.6.2. Clasificación de los sistemas multiprocesadores . . . . . . . 142
2.6.7. Organización del multiprocesador . . . . . . . . . . . . . . . . . . . . 143
ÍNDICE GENERAL V
2.6.7.1. Sistemas orientados a bus. . . . . . . . . . . . . . . . . . . . 144

2.6.7.2. Sistemas de Barras Cruzadas e Interruptores . . . . . . . . . 145
2.6.7.3. Hipercubos . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
2.6.7.4. Sistemas basados en conmutadores multietapa . . . . . . . . 148
2.6.8. Sistemas operativos del multiprocesador . . . . . . . . . . . . . . . . . 149
2.6.8.1. Supervisores separados . . . . . . . . . . . . . . . . . . . . 150
2.6.8.2. Maestro/Esclavos . . . . . . . . . . . . . . . . . . . . . . . 150
2.6.8.3. Simétrico . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
2.7. Problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
3. Administración de Memoria 157

3.1. Política y filosofía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
3.1.1. Organización de la memoria . . . . . . . . . . . . . . . . . . . . . . . 158
3.1.2. Administrador de la memoria . . . . . . . . . . . . . . . . . . . . . . 159
3.1.3. Jerarquía de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . 161
3.1.4. Estrategias para la administración de la memoria . . . . . . . . . . . . 162
3.1.5. Multiprogramación con particiones fijas y variables . . . . . . . . . . . 163
3.1.5.1. Particiones fijas. . . . . . . . . . . . . . . . . . . . . . . . . 163
3.1.5.2. Particiones variables. . . . . . . . . . . . . . . . . . . . . . 164
3.2. Memoria real . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
3.2.1. Administración de la memoria con mapa de bits . . . . . . . . . . . . . 166
3.2.2. Administración de la memoria con listas enlazadas . . . . . . . . . . . 167
3.3. Organización de la memoria virtual . . . . . . . . . . . . . . . . . . . . . . . . 168
3.4. Administración de la memoria virtual . . . . . . . . . . . . . . . . . . . . . . 170
3.4.1. Paginación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
3.4.1.1. Paginación fija . . . . . . . . . . . . . . . . . . . . . . . . . 173
3.4.1.2. Paginación bajo demanda . . . . . . . . . . . . . . . . . . . 178
3.4.2. Segmentación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
3.4.2.1. Soporte de hardware . . . . . . . . . . . . . . . . . . . . . . 181
3.4.3. Algoritmos de sustitución de páginas . . . . . . . . . . . . . . . . . . 183
3.4.3.1. Sustitución simple de páginas . . . . . . . . . . . . . . . . . 184
3.4.3.2. Sustitución de páginas First input First Output . . . . . . . . 185
3.4.3.3. Sustitución óptima de páginas . . . . . . . . . . . . . . . . . 185
3.4.3.4. Sustitución LRU . . . . . . . . . . . . . . . . . . . . . . . . 186
3.4.3.5. Sustitución por contadores . . . . . . . . . . . . . . . . . . 187
VI ÍNDICE GENERAL
3.4.3.6. Algoritmos de búfer de páginas . . . . . . . . . . . . . . . . 187

3.4.4. Aspectos de diseño para el sistema . . . . . . . . . . . . . . . . . . . . 188
3.4.5. Liberación de páginas . . . . . . . . . . . . . . . . . . . . . . . . . . 189
3.5. Problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
4. Administración de Entrada/Salida 193

4.1. Dispositivos y manejadores de dispositivos . . . . . . . . . . . . . . . . . . . . 193
4.1.1. Dispositivos de I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
4.1.2. manejadores de dispositivos . . . . . . . . . . . . . . . . . . . . . . . 196
4.2. Mecanismos y funciones de los manejadores de dispositivos . . . . . . . . . . 198
4.2.1. Objetivos de los manejadores de entrada/salida . . . . . . . . . . . . . 199
4.2.2. Manejadores de interrupciones . . . . . . . . . . . . . . . . . . . . . . 200
4.2.2.1. Sondeo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
4.2.2.2. Interrupciones . . . . . . . . . . . . . . . . . . . . . . . . . 202
4.2.3. Manejador de dispositivos . . . . . . . . . . . . . . . . . . . . . . . . 205
4.3. Estructuras de datos para manejo de dispositivos . . . . . . . . . . . . . . . . . 207
4.3.1. Planificación de Entrada/Salida . . . . . . . . . . . . . . . . . . . . . 207
4.3.2. Almacenamiento en búfer . . . . . . . . . . . . . . . . . . . . . . . . 208
4.3.3. Almacenamiento en caché. . . . . . . . . . . . . . . . . . . . . . . . . 208
4.3.4. Administración de colas . . . . . . . . . . . . . . . . . . . . . . . . . 209
4.3.5. Tratamiento de errores . . . . . . . . . . . . . . . . . . . . . . . . . . 209
4.3.6. Espacio del usuario para software de I/O . . . . . . . . . . . . . . . . 210
4.4. Operaciones de Entrada/Salida . . . . . . . . . . . . . . . . . . . . . . . . . . 211
4.4.1. Discos RAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
4.4.2. Discos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
4.4.2.1. Hardware de discos . . . . . . . . . . . . . . . . . . . . . . 213
4.4.2.2. Software para discos . . . . . . . . . . . . . . . . . . . . . . 218
4.4.3. Relojes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
4.4.3.1. Hardware de relojes . . . . . . . . . . . . . . . . . . . . . . 224
4.4.3.2. Software reloj . . . . . . . . . . . . . . . . . . . . . . . . . 226
4.4.3.3. Manejador del reloj . . . . . . . . . . . . . . . . . . . . . . 226
4.4.4. Terminales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
4.4.4.1. Hardware de terminales . . . . . . . . . . . . . . . . . . . . 227
4.4.4.2. Terminales que se ciñen a la norma RS-232 . . . . . . . . . . 228
4.4.4.3. Manejadores . . . . . . . . . . . . . . . . . . . . . . . . . . 237
ÍNDICE GENERAL VII
4.5. Problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

5. Sistemas de archivos 251

5.1. Concepto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
5.1.1. Operaciones con los archivos . . . . . . . . . . . . . . . . . . . . . . . 253
5.1.2. Jerarquía de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
5.2. Noción de archivo real y virtual . . . . . . . . . . . . . . . . . . . . . . . . . 256
5.2.1. Tipos de archivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
5.2.2. Archivos de texto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
5.2.3. Archivos binarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
5.2.4. Interfase con el usuario . . . . . . . . . . . . . . . . . . . . . . . . . . 261
5.3. Componentes de un sistema de archivos . . . . . . . . . . . . . . . . . . . . . 261
5.3.1. Llamadas al sistema (systemcalls) . . . . . . . . . . . . . . . . . . . . 262
5.3.2. Interfaz de la biblioteca estándar . . . . . . . . . . . . . . . . . . . . . 263
5.3.2.1. Fopen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
5.3.2.2. Fread . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
5.3.2.3. Fwrite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
5.3.2.4. Fclose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
5.3.2.5. Entrada/salida de caracteres con la biblioteca estándar . . . . 264
5.3.3. Tipos de interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
5.3.4. Interfaz de usuario modo consola . . . . . . . . . . . . . . . . . . . . 265
5.3.5. Interfaz de usuario modo gráfico . . . . . . . . . . . . . . . . . . . . . 268
5.3.5.1. Interfaz para el programador . . . . . . . . . . . . . . . . . 268
5.3.6. Lenguaje de comunicación y pipelines o conductos . . . . . . . . . . . 270
5.4. Organización lógica y física . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
5.4.1. Organización lógica . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
5.4.2. Organización física . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
5.5. Mecanismos de acceso a los archivos . . . . . . . . . . . . . . . . . . . . . . . 274
5.5.1. Métodos de Acceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
5.5.2. Acceso secuencial . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
5.5.3. Acceso directo o aleatorio. . . . . . . . . . . . . . . . . . . . . . . . . 275
5.5.4. Acceso a archivos por índice . . . . . . . . . . . . . . . . . . . . . . . 277
5.6. Manejo de espacio en memoria secundaria . . . . . . . . . . . . . . . . . . . . 278
5.6.1. Implementación de archivos . . . . . . . . . . . . . . . . . . . . . . . 278
5.6.2. Servidor de archivos . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
VIII ÍNDICE GENERAL
5.6.2.1. Servidor de archivos . . . . . . . . . . . . . . . . . . . . . . 289

5.6.2.2. Servidor de aplicaciones . . . . . . . . . . . . . . . . . . . . 290
5.6.2.3. Servidor de bases de datos . . . . . . . . . . . . . . . . . . . 291
5.6.2.4. Servidor de páginas WEB . . . . . . . . . . . . . . . . . . . 291
5.6.3. Seguridad en los archivos . . . . . . . . . . . . . . . . . . . . . . . . . 292
5.6.3.1. Seguridad en el acceso a los archivos y directorios . . . . . . 293
5.7. Modelo jerárquico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
5.8. Mecanismos de recuperación en caso de falla . . . . . . . . . . . . . . . . . . 299
5.8.1. Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
5.8.2. Consistencia del sistema de archivos . . . . . . . . . . . . . . . . . . . 302
5.9. Problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
6. Protección y Seguridad 309

6.1. Conceptos y objetivos de protección . . . . . . . . . . . . . . . . . . . . . . . 312
6.1.1. Conceptos fundamentales de seguridad . . . . . . . . . . . . . . . . . 312
6.1.1.1. Seguridad física . . . . . . . . . . . . . . . . . . . . . . . . 313
6.1.1.2. Seguridad lógica . . . . . . . . . . . . . . . . . . . . . . . . 314
6.1.2. Vigilancia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
6.2. Funciones del sistema de protección . . . . . . . . . . . . . . . . . . . . . . . 316
6.2.1. Fundamentos de la protección . . . . . . . . . . . . . . . . . . . . . . 317
6.3. Implantación de Matriz de acceso . . . . . . . . . . . . . . . . . . . . . . . . 318
6.4. Protección basada en el lenguaje . . . . . . . . . . . . . . . . . . . . . . . . . 319
6.5. Concepto de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
6.5.1. Clasificaciones de la seguridad . . . . . . . . . . . . . . . . . . . . . . 321
6.5.1.1. Seguridad por hardware . . . . . . . . . . . . . . . . . . . . 321
6.5.1.2. Seguridad por software . . . . . . . . . . . . . . . . . . . . 321
6.6. Validación y amenazas al sistema . . . . . . . . . . . . . . . . . . . . . . . . . 322
6.6.1. Validación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
6.6.1.1. Validación de usuarios . . . . . . . . . . . . . . . . . . . . . 322
6.6.1.2. Dominios . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
6.6.1.3. Listas de control de acceso . . . . . . . . . . . . . . . . . . 326
6.6.1.4. Sistemas basados en la confianza . . . . . . . . . . . . . . . 327
6.6.1.5. Auditoría . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
6.6.1.6. Controles de acceso . . . . . . . . . . . . . . . . . . . . . . 331
6.6.1.7. Seguridad del núcleo . . . . . . . . . . . . . . . . . . . . . 333
ÍNDICE GENERAL IX
6.6.2. Amenazas al sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 334

6.6.2.1. Ataques internos . . . . . . . . . . . . . . . . . . . . . . . . 334
6.6.2.2. Ataques externos . . . . . . . . . . . . . . . . . . . . . . . 336
6.6.2.3. Penetración al S.O . . . . . . . . . . . . . . . . . . . . . . . 340
6.7. Cifrado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
6.7.1. Principios básicos de cifrado . . . . . . . . . . . . . . . . . . . . . . . 346
6.7.2. Cifrado tradicional . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
6.7.3. La norma de cifrado de datos (DES, Data encryption estándar) . . . . 349
6.7.4. cifrado con clave pública . . . . . . . . . . . . . . . . . . . . . . . . . 350
6.7.5. El algoritmo Rivest, Shamir, Adelman o RSA . . . . . . . . . . . . . . 351
6.7.6. Verificación de identidad . . . . . . . . . . . . . . . . . . . . . . . . . 353
6.7.7. Firmas digitales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
6.8. Medición del desempeño (performance) de los SO, monitoreo y evaluación . . 354
6.8.1. Aspectos a considerar en el desempeño . . . . . . . . . . . . . . . . . 354
6.8.1.1. ¿Qué debe optimizarse? . . . . . . . . . . . . . . . . . . . . 354
6.8.1.2. Equilibrio espacio-velocidad . . . . . . . . . . . . . . . . . 355
6.8.1.3. Medición del desempeño . . . . . . . . . . . . . . . . . . . 355
6.8.2. Monitoreo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
6.8.2.1. Utilerías del sistema para visualizar los logs . . . . . . . . . 358
6.8.3. Evaluación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
6.8.3.1. Costo total de propiedad . . . . . . . . . . . . . . . . . . . . 360
6.9. Problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
Bibliografía 369
Índice alfabético 378

X ÍNDICE GENERAL
Índice de tablas
2.1. Representación de estados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
4.1. Puertos de E/S más comunes en una PC . . . . . . . . . . . . . . . . . . . . . 197

4.2. Vector de interrupciones para los procesadores i386 . . . . . . . . . . . . . . . 204
4.3. Velocidades de transmisión de una UART actual . . . . . . . . . . . . . . . . . 230
5.1. Extensiones más comunes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

5.2. Una entrada de directorio tradicional de UNIX, GNU/Linux . . . . . . . . . . 293
5.3. Rutas absolutas en UNIX/Linux, Windows y MULTICS . . . . . . . . . . . . . 296
5.4. Ejemplos de rutas relativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
XI
XII ÍNDICE DE TABLAS
Índice de figuras
1.1. Componentes de una Arquitectura Von Newmann . . . . . . . . . . . . . . . . 7

1.2. Componentes principales de la Unidad Central de Proceso . . . . . . . . . . . 7
1.3. Dispositivos de almacenamiento masivo . . . . . . . . . . . . . . . . . . . . . 11
1.4. Conformación de pistas y sectores en un plato de disco . . . . . . . . . . . . . 30
1.5. a) Un sistema con E/S en línea b) E/S fuera de línea . . . . . . . . . . . . . . . 36
1.6. Un sistema multiusuario típico . . . . . . . . . . . . . . . . . . . . . . . . . . 37
1.7. Estructura de la memoria de un sistema por lotes . . . . . . . . . . . . . . . . 38
1.8. Flujo de datos en el spooling . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
1.9. Estructura de la memoria en un sistema de multiprogramación . . . . . . . . . 40
1.10. Estructura del MS-DOS de Microsoft . . . . . . . . . . . . . . . . . . . . . . 47
1.11. Arquitectura lógica del núcleo de GNU/Linux . . . . . . . . . . . . . . . . . . 49
1.12. Arquitectura parte 2: La capa del Sistema y de red . . . . . . . . . . . . . . . . 50
1.13. Arquitectura parte 3: almacenamiento, memoria y procesamiento . . . . . . . . 51
1.14. Arquitectura parte 4: La capa de Interfaz Humana . . . . . . . . . . . . . . . . 52
1.15. Organización por niveles de un sistema operativo . . . . . . . . . . . . . . . . 53
2.1. Diagrama de estados de un proceso . . . . . . . . . . . . . . . . . . . . . . . . 76

2.2. Los estados de un proceso más el estado de espera . . . . . . . . . . . . . . . . 97
2.3. Estructura general de un monitor . . . . . . . . . . . . . . . . . . . . . . . . . 99
2.4. Estado del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
2.5. Ubicación de los planificadores . . . . . . . . . . . . . . . . . . . . . . . . . . 128
2.6. Tiempos totales de ejecución de los procesos . . . . . . . . . . . . . . . . . . 129
2.7. Tiempos totales de ejecución de los procesos . . . . . . . . . . . . . . . . . . 129
2.8. Funcionamiento del algoritmo Round Robin . . . . . . . . . . . . . . . . . . . 130
2.9. Organización para ejecutar los cuatro procesos con SJF . . . . . . . . . . . . . 133
2.10. Placa base para cuatro CPU’s . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
2.11. Organización de un sistema multiprocesador orientado a bus . . . . . . . . . . 144
XIII
XIV ÍNDICE DE FIGURAS
2.12. Conexión mediante barra cruzada . . . . . . . . . . . . . . . . . . . . . . . . 146

2.13. Hipercubo con ocho nodos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
2.14. Conexiones entre procesadores . . . . . . . . . . . . . . . . . . . . . . . . . . 148
3.1. Disposición general de la memoria física . . . . . . . . . . . . . . . . . . . . . 158

3.2. Distribución con particiones fijas . . . . . . . . . . . . . . . . . . . . . . . . . 164
3.3. Disposición general de la memoria física . . . . . . . . . . . . . . . . . . . . . 166
3.4. Manejo de memoria con listas ligadas . . . . . . . . . . . . . . . . . . . . . . 167
3.5. Organización de la memoria virtual . . . . . . . . . . . . . . . . . . . . . . . . 172
3.6. Estructura general de un sistema de paginación . . . . . . . . . . . . . . . . . 173
3.7. Compartición de código mediante páginas . . . . . . . . . . . . . . . . . . . . 177
3.8. Organización de segmentación . . . . . . . . . . . . . . . . . . . . . . . . . . 182
4.1. Arquitectura de bus clásica en una PC . . . . . . . . . . . . . . . . . . . . . . 196

4.2. Estructura de Entrada/Salida de un kernel . . . . . . . . . . . . . . . . . . . . 206
4.3. Ubicación de un disco RAM en memoria . . . . . . . . . . . . . . . . . . . . . 212
4.4. Vista interna de un disco duro . . . . . . . . . . . . . . . . . . . . . . . . . . 214
4.5. Divisiones lógicas de un disco . . . . . . . . . . . . . . . . . . . . . . . . . . 215
4.6. Onda típica de un ciclo de reloj . . . . . . . . . . . . . . . . . . . . . . . . . . 225
4.7. Vista de los conectores DB25 . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
4.8. Asignación de conexiones en el DB25 . . . . . . . . . . . . . . . . . . . . . . 229
4.9. Asignación de pines en el DB9 . . . . . . . . . . . . . . . . . . . . . . . . . . 229
4.10. Una configuración típica de terminales . . . . . . . . . . . . . . . . . . . . . . 230
4.11. Una sesión típica de terminal . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
5.1. Componentes y funciones del Sistema de archivos . . . . . . . . . . . . . . . . 262

5.2. Sesión gráfica de KDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
5.3. Componentes típicos de un sistema de archivos . . . . . . . . . . . . . . . . . 271
5.4. Vista de usuario del sistema de archivos . . . . . . . . . . . . . . . . . . . . . 273
5.5. Organización del sistema de archivos en UNIX/Linux . . . . . . . . . . . . . . 273
5.6. Archivo de acceso secuencial . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
5.7. Ejemplo de archivo índice y archivo relativo . . . . . . . . . . . . . . . . . . . 277
5.8. Fragmentación del disco con el almacenamiento secuencial . . . . . . . . . . . 279
5.9. Uso de listas ligadas de bloques de disco . . . . . . . . . . . . . . . . . . . . . 280
5.10. Tabla de Asignación de Archivos . . . . . . . . . . . . . . . . . . . . . . . . . 281
5.11. Estructura de un nodo-i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
5.12. Implementación de directorio con entradas de archivo fijas . . . . . . . . . . . 284
ÍNDICE DE FIGURAS XV
5.13. Implementación de directorios con nodos-i . . . . . . . . . . . . . . . . . . . . 284

5.14. Estructura de directorios incorporados . . . . . . . . . . . . . . . . . . . . . . 286
5.15. Uso de heap de entradas de directorio . . . . . . . . . . . . . . . . . . . . . . 287
5.16. Ejemplo de directorio tipo árbol . . . . . . . . . . . . . . . . . . . . . . . . . 296
6.1. Matriz de acceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318

6.2. Definiciones de Dominios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
6.3. Uso de las listas de control de acceso . . . . . . . . . . . . . . . . . . . . . . . 327
6.4. Implementación de un monitor de referencias . . . . . . . . . . . . . . . . . . 329
6.5. Control de acceso basado en roles . . . . . . . . . . . . . . . . . . . . . . . . 332
6.6. Un modelo sencillo de un sistema de criptografía . . . . . . . . . . . . . . . . 347
XVI ÍNDICE DE FIGURAS
Introducción
X isten muchos libros que hablan sobre los sistemas operativos. La mayoría traen más in-
E formación de la que puede ser tratada en un curso de seis meses. En este libro se trató de
incluir aquella información que se consideró más importante para poder concluir el curso en el
tiempo señalado. No se pretende la substitución de la investigación por parte del alumno sobre
los temas de la materia, si no más bien, proporcionar un marco que ubique al estudiante para
que de ser necesario y a partir de ello tenga una idea clara de los conceptos clave y luego dirigir
su búsqueda en otras fuentes informativas.
Es importante recalcar que es obligatorio para el alumno y el docente profundizar hasta
donde sea necesario en otras fuentes de información sobre los temas analizados en este libro
para una mayor comprensión.
También es muy importante que el alumno haya cursado las materias básicas de programa-
ción I y II, incluyendo estructuras de datos y manejo de archivos. Sin estas bases sería muy
difícil dar seguimiento a las ideas subyacentes de diseño de un sistema operativo.
Existen muchos temas en los que se recomienda encarecidamente que el alumno haga progra-
mas breves en donde simule las estructuras utilizadas por el sistema operativo para las distintas
estrategias de implementación de los módulos del sistema.
Al mismo tiempo que se enseña la teoría se recomienda también poner ejemplos sobre el uso
de las interfaces o instrucciones que están directamente involucradas con el tema. En la mayoría
de las unidades se incluyen algunas instrucciones que pueden ser probadas ya sea en un sistema
operativo UNIX/Linux o en Windows.
La estructura general del libro es la que propone el programa de la materia de sistemas opera-
tivos I. Refiérase el lector al temario y actividades propuestas para complementar su aprendizaje.
En el anexo I se hace una transcripción del temario propuesto, las actividades complementa-
rias y las prácticas que deben de llevarse a cabo.
A continuación daremos un breve bosquejo del contenido del libro. En la introducción se
explica el contenido del libro para una referencia rápida.
En el capítulo 1 se hace una introducción general a los sistemas operativos. Se hacen defini-
XVII
XVIII ÍNDICE DE FIGURAS
ciones básicas. Se hace una descripción detallada de los tipos de usuario que que interactúan con
un sistema operativo. Aquí el alumno debe de identificar claramente a estos usuarios y reconocer
las necesidades de cada uno de ellos.
Es muy importante conocer la arquitectura general de la computadora incluyendo sus princi-
pales componentes. En este capítulo se recomienda que el alumno haga una investigación acerca
de todos los periféricos que existen actualmente, de preferencia incluyendo precios caracterís-
ticas y principios de funcionamiento, así como el tipo de interfaz de hardware que manejan a
nivel conceptual. Se trata también de forma general el proceso de arranque de la computadora.
Desde la configuración de la BIOS para seleccionar el dispositivo de arranque, la lectura del
Registro Maestro de Arranque o MBR, la carga del sistema operativo en sí, la inicialización del
vector de interrupciones hasta la puesta en marcha de las interfaces de usuario, que en su forma
más simple puede ser una línea de comando o hasta la más compleja: una interfaz gráfica con
un conjunto completo de ventanas. Todo esto será analizado en la sección 1.1.
Para entender cómo se ha llegado hasta los actuales sistemas operativos, se hace una breve
remembranza de la historia de las computadoras y de los sistemas operativos. Ambas han estado
siempre muy ligados, ya que a medida que se ha mejorado el hardware en esa misma proporción,
aunque más lento, ha sido también el desarrollo de los sistemas operativos. En la actualidad, y
creo que ha sido así durante mucho tiempo, el software no ha podido aprovechar completamente
el hardware nuevo. El sistema operativo por tanto, no es la excepción, al ser el encargado de
manejar todo el hardware si éste no es capaz de manejarlo es muy improbable que lo hagan las
aplicaciones.
Se dedica también una sección en 1.3 a la evolución de los sistemas operativos, poniendo
ejemplos de los principales competidores que existen en la actualidad. Debe quedar claro que
la visión aquí expuesta puede cambiar dentro de algunos años debido al gran avance que hay
en estas áreas. Se empieza analizando cómo es que surgieron los primeros sistemas operativos
dedicados, la necesidad de agrupar las tareas por lotes. La separación de la ejecución de las
aplicaciones con tiempo de CPU de aquellas con operaciones de entrada salida, hasta llegar a
los actuales sistemas de tiempo compartido o sistemas de multiprogramación que permiten hacer
un uso más eficiente del tiempo de CPU y de las tremendas capacidades de las computadoras de
hoy en día.
En los subsistemas de un sistema operativo que se analizarán en la sección 1.2 se da una
introducción general de los componentes principales y que forman parte de mucho material de
este libro. El primer tema es el relacionado con la administración de procesos. Un proceso es
la unidad básica de trabajo del sistema operativo. Cuando el sistema lee un programa de disco,
éste lo transforma en un proceso, le proporciona los recursos que necesita, lo coloca en memoria
y empieza su ejecución. El sistema puede entonces crear, suspender o “matar” a un proceso de
ÍNDICE DE FIGURAS XIX
acuerdo a las directivas impuestas por el propio sistema operativo. La planificación de la CPU es
el módulo que se encarga de proporcionar el tiempo de ejecución que corresponde a cada proceso
dentro del sistema. Existen dos técnicas generales: el planificador a corto plazo y el planificador
a largo plazo. Ambos tienen ventajas y desventajas. La mayoría de los sistemas actuales usan
la técnica de tiempo compartido con prioridades que también se analizan en el libro. El otro
aspecto importante es acerca de la administración de memoria, terminando con la administración
de dispositivos de entrada salida y con el administrador de sistemas de archivos. Se da una
descripción de los tipos de estructura de sistemas operativos más importantes: micronúcleos
y kernel modular, con dos enfoques: estructura única o estructura por niveles. Se termina el
capítulo con un análisis de los sistemas operativos más comerciales. Se recomienda que en
este punto los alumnos actualicen la información proporcionada de forma que sean capaces de
observar los cambios de características en las nuevas versiones de sistemas operativos.
En el capítulo 2 entramos a discutir todos los aspectos relacionados con los procesos, sus
definiciones, tipos de procesos: procesos e hilos, el problema de concurrencia que implica el
acceso simultáneo al mismo recurso por dos o más procesos. Los conceptos de sección crítica,
cómo debe de solucionarse el problema de la exclusión mutua, los métodos de organización
usando semáforos, monitores o paso de mensajes.
Se proporciona también las definiciones de concurrencia e interbloqueo, las condiciones que
deben de cumplirse para que exista el interbloqueo y también se dan algunas soluciones para
evitarlo, que obviamente, es impidiendo al menos una de las condiciones, pero no obstante, la
implementación de alguna de estas soluciones no es un problema trivial.
En el capítulo 2.5 se analizan los aspectos relacionados con la administración del tiempo
de la CPU. Básicamente existen dos enfoques: la planificación apropiativa y la planificación no
apropiativa. En la planificación no apropiativa, el sistema operativo asigna un proceso a la CPU
y a partir de ahí no puede recuperar el control hasta que el proceso lo ceda voluntariamente al
sistema operativo. En la planificación apropiativa el sistema operativo puede quitarle al proceso
la CPU en el momento en que sea necesario. Se analizan también varias técnicas de planificación
interesantes desde el punto de vista teórico y otras que han sido implementadas exitosamente en
algunos sistemas operativos actuales. En este capítulo se da una introducción básica a los siste-
mas operativos de multiproceso. Se hace un breve análisis de una arquitectura multiprocesador y
se analizan algunos conceptos de paralelismo. También se analizan las ventajas de los sistemas
de multiprocesamiento, su clasificación, la forma en que se organiza un sistema multiprocesador
para terminar con un análisis sobre los sistemas operativos que soportan múltiples procesadores.
En el capítulo 3 se hace un revisión de las técnicas de manejo de memoria. Se empieza
con una discusión acerca del administrador de memoria, luego se ven las técnicas de manejo
de memoria real, la memoria virtual que incluye las técnicas de paginación, segmentación y
XX ÍNDICE DE FIGURAS
los algoritmos de sustitución de páginas, con algunos aspectos para el diseño del sistema y las
formas de implementación de liberación de páginas.
En el capítulo 4 se definen los principios básicos del hardware de entrada salida. También
se analizan los principios del software de entrada salida, conocidos como controladores. Se
recalca la diferencia entre la tarjeta controladora del dispositivo y el manejador o driver de la
tarjeta controladora que viene a ser el software que debe de cargar el sistema operativo para
poder manipular ese dispositivo. Se ven también las técnicas utilizadas por algunos sistemas
operativos para mantener una interfaz estándar que es independiente del dispositivo, de forma
tal que es posible usar esta interfaz para manejar a la mayoría de ellos con pocas llamadas al
sistema.
Se describe la forma de implementar un disco RAM y cómo se accede a los discos presentes
en el sistema, definiendo primeramente el hardware de discos y luego el software de éste para
su control. Se explican los algoritmos para la planificación del disco.
En los sistemas de tiempo compartido es muy importante el control del reloj. Toda compu-
tadora tiene un reloj que el sistema operativo puede usar para poder planificar el tiempo que debe
asignarse a cada proceso. También es una forma de implementar la planificación apropiativa, de
manera que la ejecución de algún proceso sea suspendida cada cierto tiempo de forma tal que
el sistema operativo pueda tomar el control de la computadora y verificar si el proceso continúa
ejecutándose o se asigna la CPU a otro proceso. Se termina el capítulo con una descripción del
manejo de terminales, haciendo una descripción del hardware y software utilizado para su con-
trol. Se hace hincapié en los manejadores de teclado y de vídeo que son casos particulares de
las terminales y que muchas veces se tratan como si lo fueran. Aunque en realidad un sistema
de terminal se compone precisamente de un monitor y de un teclado. Las terminales actuales
incluyen también un ratón, no obstante esto no cambia en mucho el enfoque de las antiguas
terminales en cuanto a su manejo como dispositivos seriales lentos.
En el capítulo 5 se da la definición de archivo, se describen las operaciones que pueden
hacerse en un archivo y también se describe a un archivo como un componente más dentro de la
jerarquía de datos visto desde la perspectiva de los lenguajes de programación. Pasamos después
a explicar las formas más comunes que usan los sistemas operativos para la implementación del
sistema de archivos. La primera clasificación que se usa son la de los archivos de texto y los
archivos binarios. Los archivos texto son una forma simple de compartir datos entre diferentes
plataformas. La mayoría de los programadores y las aplicaciones pueden trabajar con este tipo de
archivo. Es necesario cambiar algunos caracteres especiales para que cada plataforma pueda leer
correctamente las líneas de estos archivos. Es normal que un sistema UNIX/Linux use solamente
un caracter para representar la nueva línea y el retorno de carro mientras que un sistema basado
en MS-DOS o Windows se usen dos caracteres distintos: uno para la nueva línea y otro para
ÍNDICE DE FIGURAS XXI
el retorno de carro. Por lo demás el texto es completamente legible. Los archivos binarios, en
cambio no pueden ser visualizados por algún editor de texto normal. Estos archivos pueden
representar programas ejecutables, imágenes o números, por lo tanto no es posible tratarlos
como archivos de texto. Si el usuario aún después de saber esta diferencia intenta usar un editor
de texto común o alguna utilería del sistema operativo que espera un archivo de texto para
mostrar su contenido, los resultados pueden no ser los que esperaba. En algunas ocasiones el
intentar mostrar un archivo binario en alguna terminal puede hacer que ésta se bloquee, debido
a que la terminal intentará interpretar algunos caracteres no imprimibles como órdenes.
Otro aspecto es en el manejo de archivos es comprender la importancia de la interfase con el
usuario, que incluye la forma mediante la cual el usuario puede acceder a sus datos dentro del
archivo. Con estas herramientas pasamos entonces al diseño del sistema de archivos explicando
las diferentes técnicas que se usan para implementar un sistema de archivos real. Se explican
también algunas modalidades de clientes especiales que atiende el servidor de archivos. Debido
a que este nombre es general, se hace una clasificación más específica acerca de los diferentes
servidores que un usuario puede encontrar en la red.
El respaldo de datos es un tema que debe ser recalcado a nuestros estudiantes, puesto que
permite recuperar el sistema después de algún tipo de desastre. Por desgracia a nivel de compu-
tación personal no está tan difundido el respaldo de información. A nivel empresarial es decidi-
damente necesario implementar alguna técnica de respaldo de información. La más común es la
estrategia de respaldo incremental de información.
Otro punto importante es la forma mediante la cual se implementa la seguridad en los archi-
vos, ya sea mediante un campo de atributos en su forma más simple o hasta el uso de listas de
acceso que almacenan a los usuarios y las operaciones que tienen autorizado efectuar sobre el
archivo o directorio.
Se analizan también las llamadas al sistema implementadas para el manejo de archivo y
dispositivos y de acuerdo a las interfases proporcionadas por el sistema operativo para cada tipo
de usuario. Se termina el capítulo con una explicación del lenguaje de comunicación utilizado
por el sistema operativo en línea de comandos y la forma en que se comunican las utilerías y
muchos programas por medio de tuberías.
En el capítulo 6 se analizan las técnicas de implementación y uso para la medición del
desempeño de los sistemas operativos. Se hace una descripción acerca de cómo implementar
los mecanismos de seguridad mínimos de forma que el estudiante aprenda cuáles son los reque-
rimientos de seguridad con los que debe contar cualquier sistema operativo que se encuentre
conectado en la red o incluso en una oficina al que tienen acceso varias personas. Se analizan
también las técnicas de auditoría control de acceso, seguridad por hardware o software, cripto-
grafía y algunas técnicas comunes para comprometer la integridad del sistema operativo.
XXII ÍNDICE DE FIGURAS
Como notas finales quisiera agradecer al Instituto Tecnológico de Apizaco por su apoyo
incondicional para el desarrollo de este proyecto, a la Academia de Sistemas y Computación, al
Centro de información, a la Internet, red de redes que gracias a ella, se puede despejar una duda
en menos de un minuto mediante una buena búsqueda, gracias a las miles de comunidades de
software libre existentes a nivel mundial que desinteresadamente aportan mucho de su tiempo
para que podamos hacer uso de un sistema operativo espectacular y que si lo deseamos podemos
desentrañar todos sus secretos con el código fuente frente de nosotros. Es una oportunidad que
ni nosotros ni nuestros estudiantes deben desaprovechar.
Por último para no herir susceptibilidades quiero agradecer también a todos aquellos que
directa o indirectamente intervinieron para que este trabajo se hiciera realidad.
Ojalá también este libro sea la base para futuros trabajos y como toda obra humana, el
escrito actual puede aún mejorarse de innumerables formas. Cualquier sugerencia o aportación
será bienvenida.
Espero también que nuestros alumnos hagan uso intensivo de este material como una guía
dentro de su aprendizaje, que al final es el objetivo principal de esta y de todas las obras del ser
humano.
Capítulo 1
Introducción a los Sistemas Operativos
N la actualidad, la mayoría de nosotros hemos tenido contacto, de alguna u otra forma,

E con un sistema operativo. En los dispositivos que usamos cotidianamente puede que exista
dentro de éste uno pequeño o uno que pueda observarse fácilmente, tal como en las compu-
tadoras personales. Si hablamos de los dispositivos usados en el hogar encontramos teléfonos
celulares, con diferentes funciones incluso el acceso a internet, asistentes digitales personales
o PDA’s que pueden sincronizarse con nuestra computadora personal o compartir información
vía red. Cuando vamos de compras, al momento de pagar o cuando verificamos el precio de un
artículo estamos teniendo contacto con un sistema operativo. Cabe observar que la mayoría de
las empresas utiliza ahora el pago de nómina por medio de depósitos bancarios. Esto significa
que las personas tienen que ir a un banco con un cajero, ya sea automático o uno tradicional para
cobrar su dinero mediante una tarjeta de débito o un monedero electrónico. En el momento en
que la persona inserta su tarjeta o la proporciona al cajero ocurre una serie de eventos, como la
autenticación del usuario por un sistema operativo central, el cual a su vez soporta servicios a
otras aplicaciones necesarias para llevar la contabilidad de miles de usuarios que, es posible, se
encuentren haciendo diversas transacciones monetarias del mismo banco, o que incluso, si es un
banco al que no está afiliado, éste se conecta con el banco del usuario solicitando el retiro del
dinero.
A tal grado es la penetración de estos sistemas que incluso, si estamos atentos podemos
conocer de su existencia en los automóviles, en las centrales telefónicas, en los servicios de
internet, en los juegos y la lista podría aún ser mucho mayor.
Entonces, si están en todos lados, ¿cómo es que no los conocemos o no los notamos? Un
sistema operativo es precisamente una interfaz que ayuda a interactuar de una manera sencilla
con el hardware (entiéndase como hardware, todos aquellos dispositivos que se pueden tocar o
que son físicos. En el caso de una lavadora sería el motor, las aspas y todo lo demás que debe
1
2 1.1. DEFINICIÓN, Y CONCEPTO
de controlarse para un buen lavado. Si hablamos de una computadora tenemos, el procesador, la

memoria, los dispositivos de entrada/salida, los buses y otros). Por lo tanto, todos los ejemplos
citados anteriormente usan procesadores, unos grandes, otros pequeños pero todos van a contar
con una interfase que ayude a facilitar la tarea del usuario cuando retira su dinero o cuando
solicita un precio de un artículo mediante el código de barras o cuando lave su ropa. A esa
interfase podemos llamarle Sistema operativo.
En vista de todo lo anterior, podemos deducir que existen diversos sistemas operativos. Cada
uno con un diseño específico y con funciones de acuerdo a las tareas que va a realizar Algunos
son tan simples que sus entradas están solamente basadas en perillas y botones digitales y sus
salidas son hacer que el hardware haga la tarea solicitada. Otros son tan complejos que pueden
manejar a miles de usuarios solicitando servicios a múltiples computadoras conectadas entre sí
pero orquestadas por un sistema operativo distribuido con multiprocesamiento. Si hablamos de
un entorno científico o de investigación podemos hablar de sistemas operativos para un hardware
con múltiples procesadores trabajando en paralelo corriendo cientos de aplicaciones a la vez,
asignándolas a uno o varios procesadores para disminuir su tiempo de ejecución.
En la sección 1.1 daremos una definición más acorde al ámbito computacional, los objetivos
y funciones que debe efectuar cualquier sistema operativo en general.
En la sección 1.3.1 se hace una referencia detallada, desde un punto de vista histórico, del
desarrollo de los sistemas operativos hasta el momento actual.
En la sección 1.2 haremos un estudio detallado de las estructuras más importantes de un
sistema operativo, las funciones que realizan y las formas de implementar cada una de ellas
desde un punto de vista general.
Para terminar, en la sección 1.6.2 haremos un análisis pormenorizado de las ventajas y des-
ventajas de los sistemas operativos más usados actualmente.
1.1. Definición, y concepto

1.1.1. Definiciones
Un sistema operativo en un programa que -como se dijo en la introducción del capítulo 1-
actúa como una interfaz entre un usuario y el hardware de la computadora.
Ahora es necesario saber qué tipo de usuario es el que quiere interactuar con el hardware y
qué necesidades específicas requiere para hacer su trabajo. Por otro lado, necesitamos también
saber con qué capacidades cuenta el hardware y de qué manera estas capacidades pueden ser ad-
ministradas por el sistema operativo. Trataremos en primer lugar a todos los diferentes usuarios
que tienen contacto con un sistema operativo.
CAPÍTULO 1. INTRODUCCIÓN A LOS SISTEMAS OPERATIVOS 3
1.1.1.1. Tipos de usuarios de un sistema operativo
En general podemos clasificar a nuestros usuarios en dos grandes entornos: entornos perso-
nales y entornos empresariales o institucionales. Dentro de éstos es posible categorizar aún más
en tres grupos, usuarios finales, usuarios programadores y usuarios administradores:
Entornos personales. Un sistema operativo dentro de un entorno personal debe de cubrir ne-
cesidades orientadas hacia una sola persona y su familia. Debe de estar enfocado a facilitar su
interacción con el usuario mediante sistemas multimedia, entornos gráficos y fáciles de usar,
tener la mayor cantidad de ayuda posible en línea, contar con asistentes para el desarrollo de
las diversas tareas de instalación y puesta en marcha que incluyen el sistema operativo pasando
por las aplicaciones y el uso de las mismas. El sistema operativo debe de ser capaz incluso de
proveer los mecanismos para incluir y detectar la mayor cantidad de hardware de dispositivos
de entrada/salida tales como tarjetas de vídeo, de sonido, módems, tarjetas de red, tarjetas de
captura de vídeo, memorias USB1 y toda la gama de dispositivos que surgen hoy en día orienta-
dos hacia la conectividad teléfonos celulares, cámaras de vídeo digitales, cámaras fotográficas.
Todo ello con una intervención mínima del usuario.
Hay que tener en cuenta que a nuestro usuario no podemos decirle: “Indique el número de
ranura del slot PCI en el que instaló su GeForce4 MX 420 También debe incluir el número de
interrupción que desea que utilice el sistema operativo. Es necesario que indique los controla-
dores de DRI,GLX,DDC, la tasa de refresco horizontal y vertical de su monitor y la resolución
en pixeles verticales y horizontales”. En la mayoría de los casos estos usuarios solo quieren usar
su computadora. Solamente es necesario que el usuario, tenga unos conceptos mínimos de base
para que pueda disfrutar de su equipo de cómputo.
Entornos Empresariales o institucionales. Los requerimientos empresariales o instituciona-

les que debe incluir un sistema operativo no necesariamente deben cubrir los requerimientos
personales.
En una empresa o institución, es obligatoria la autenticación del usuario y se necesita llevar
un registro de las actividades realizadas por el mismo. También la mayoría de las veces el usuario
tiene acceso restringido a los programas que puede ejecutar y las áreas de datos o archivos a los
que puede acceder. En ciertas empresas se tiene también restringido el horario y los días en los
que puede acceder y desde qué lugares puede acceder a los equipos de cómputo donde trabaja
normalmente. Decimos equipos de cómputo por que un usuario final empresarial o institucional,
1
Universal Serial Bus Bus Serie Universal
puede acceder desde su computadora u otras terminales en diferentes lugares, incluyendo su

casa a uno o varios servidores de la empresa.
Además, el sistema operativo debe ser capaz de poder atender peticiones de diferentes usua-
rios al mismo tiempo y proporcionar los accesos a los programas al que está autorizado el usua-
rio.
Como podemos ver, la compartición y administración de recursos junto con la seguridad
en este tipo de entornos es una de las principales diferencias en comparación con un entorno
personal
Usuarios Finales. Los usuarios finales son aquellos que realizan tareas relacionadas directa-
mente con la productividad en su campo específico, como un usuario de hoja de cálculo o de
procesador de palabras cuyas necesidades se reducen a hacer uso de tareas como ejecutar su
aplicación, escribir su documento, imprimirlo o mandarlo vía correo electrónico, guardar una
copia en disco en CD o en su pendrive2 . Hacer presentaciones, escuchar música, ver vídeos,
incluso jugar, ya sea un juego individual o jugar en equipo vía red local o internet.
Este tipo de usuarios, por lo común requieren una interfaz lo más intuitiva y fácil de usar en
la medida de lo posible. De ahí que a lo largo de la historia de las computadoras se haya puesto
mucho énfasis en el desarrollo de interfases visuales, uso de ratón pantallas táctiles y toda una
gama de dispositivos que faciliten la interacción del usuario final con la computadora.
Podemos encontrar en este ámbito a las computadoras personales que básicamente están de-
dicadas a cubrir las necesidades de una persona y su familia. Y aparentemente no requieren de
mucha seguridad, tal vez no sea necesario un complejo sistema operativo que administre múlti-
ples tareas o múltiples usuarios al mismo tiempo, no obstante, en la actualidad, se está poniendo
cada vez más al alcance de todos la computación multitarea y multiusuario, e incluso los sis-
temas multiprocesadores (al momento de escribir este libro, pueden conseguirse procesadores
core duo 3 ). Los conceptos anteriores se analizarán con mayor detalle en el punto 1.1.1.2.
En la computación personal es frecuente que se use la computadora para hacer compras vía
internet, pagos interbancarios, declaración y pago de impuestos, inscripción a escuelas, obten-
ción de documentos personales como extractos de actas de nacimiento, constancias estatales de
no habilitación e incluso varios usuarios se “llevan” el trabajo a casa, o mejor dicho se conectan
desde su casa al trabajo para terminar los pendientes.
Todo ello implica un ajuste tremendo en la seguridad de los sistemas operativos que usan,
debido a la delicadeza de la información que se transfiere. De ahí la importancia que tiene
escoger adecuadamente un sistema operativo.
2
Memoria USB
3
Es un chip que cuenta con dos núcleos de procesador y que puede verse ya como sistema multiprocesador
Los usuarios finales empresariales difieren solamente en los mecanismos de acceso que de-
ben de usar antes de poder hacer uso de la computadora. Por lo común estarán restringidos por
políticas empresariales o institucionales al uso de algunos paquetes expresamente instalados por
el encargado de la administración de los equipos o de la red. Estos usuarios no pueden, salvo
previa autorización, instalar ningún tipo de software y frecuentemente están siendo monitoriza-
dos por el sistema operativo, guardando la hora de acceso, programas ejecutados, transacciones
realizadas y varias estadísticas orientadas al mejoramiento de la productividad de los usuarios.
Usuarios Programadores. Un programador de aplicaciones es un usuario que requiere varias

herramientas de software de sistemas incluyendo entre otras cosas, editores, compiladores, li-
gadores, manejadores de bibliotecas, depuradores y en un nivel más alto entornos integrados de
desarrollo de aplicaciones en donde son capaces de acceder a todos los programas anteriores con
unas cuantas órdenes de teclado o de ratón, con compilación y depuración interactiva.
El sistema operativo tiene asociadas un conjunto de librerías que comúnmente se les denomi-
na llamadas al sistema las cuales pueden ser accedidas a través de un lenguaje de programación
de bajo, medio o alto nivel por los programadores de aplicaciones.
El primer fundamento de un sistema operativo seguro es no permitir que ningún tipo de
usuario tenga acceso directo al hardware. Cualquier acceso al hardware de la computadora debe
ser realizado a través de alguna llamada al sistema operativo.
El usuario programador necesita entonces un conjunto de llamadas al sistema bastante am-
plio para que pueda realizar sus tareas lo más eficientemente posible.
En algunos sistemas operativos antiguos, los programadores tenían la costumbre de saltarse
las llamadas al sistema por ser demasiado lentas en aplicaciones que requerían mucha velocidad,
tal como los juegos y accedían directamente al hardware. Los resultados eran que en el mejor
de los casos, el sistema operativo debía cargarse nuevamente en memoria. En un sistema de
cómputo personal, esto no conlleva muchos problemas, pero ¿Es esto posible en un entorno
empresarial?, por supuesto que no. En un entorno donde están trabajando muchos usuarios, no
puede permitirse que alguno de ellos acceda ni siquiera a la memoria de otros usuarios y mucho
menos al hardware.
Usuarios Administradores. Un usuario administrador, root(raíz) también conocido como su-

perusuario o administrador de sistemas se encarga de instalar los sistemas operativos, instalar
los programas de aplicación de los usuarios, las herramientas de monitoreo, los programas ser-
vidores que proporcionarán algún servicio como correo, páginas WEB, servicio de transferencia
de archivos (FTP File Trasfer Protocol) y servidores de bases de datos, entre otros.
Otras funciones incluyen la preparación de nuevas unidades de disco, creación de particio-

nes, formateo de las unidades, comprobación de las unidades de disco existentes, y en general
la instalación de cualquier dispositivo de hardware nuevo.
También se encarga de administrar los usuarios finales, lo que incluye: la creación de las
cuentas de los usuarios, asignación de su área de trabajo, asignación de permisos a los directorios
a los cuales puede acceder mediante listas de control de acceso, incluyendo los días y horas en
los cuales pueden acceder a los servicios para los cuales han sido autorizados. También tiene la
responsabilidad de administrar las bases de datos a nivel de acceso, configurar las paredes de
fuego o firewalls para controlar exactamente qué es lo que entra o sale de los servidores y si está
autorizado o no.
En algunas instituciones tiene también funciones de mantenimiento preventivo y correctivo
del equipo de cómputo y los servidores. Así como también el mantenimiento del software y el
resguardo de datos, lo que incluye diferentes estrategias de respaldo de información, por ejemplo
respaldos mensuales, quincenales o semanales, así como estrategias de recuperación de desastres
ocasionados por agentes externos al centro de procesamiento de datos.
La elaboración de estadísticas también es parte del trabajo del administrador. El sistema
operativo debe de proporcionar los medios para poder monitorear el estado del uso de todos
los recursos del sistema de modo que pueda llevarse un histórico para que después pueda ser
analizado por el administrador o sus superiores.
Por la parte administrativa su función es establecer las políticas de uso del equipo de cómputo
y del software. También la elaboración de reglamentos y las penalizaciones en caso de incum-
plimiento de las políticas. Incluyendo el control de acceso a los dispositivos e impresoras de la
corporación.
El sistema operativo debe proporcionar los mecanismos de control, auditoría y planeación
necesarios para apoyar al administrador.
Como puede desprenderse de los tópicos anteriores, el punto de vista de un usuario personal
puede diferir mucho de los otros dos. el desarrollo de un sistema operativo para uso personal
debe ser orientado a la facilidad de uso, muchas veces no importa cuántos recursos consuma.
El desarrollo de un sistema operativo para una organización debe de estar enfocado hacia la
eficiencia, esto es, distribuir lo mejor que se pueda los recursos entre los diferentes usuarios que
están haciendo uso de el.
En la actualidad, incluso un usuario con equipo personal debe de conocer al menos las tareas
básicas de administración del sistema operativo, por lo común un fabricante de computadoras
dejará instalado el sistema operativo configurado de una forma demasiado abierta o a veces
demasiado cerrada lo que implica pérdida de funcionalidad o agujeros de seguridad muy graves.
1.1.1.2. Arquitectura de una Computadora
Ahora describiremos una de las arquitecturas de computadora más comunes, la arquitectura

Von Newmann. En la figura 1.1 observamos sus componentes.
Figura 1.1: Componentes de una Arquitectura Von Newmann
Una computadora basada en esta arquitectura cuenta básicamente con los siguientes elemen-
tos: una Unidad Central de Proceso (UCP), una memoria principal, una memoria secundaria y
un conjunto de dispositivos de entrada/salida periféricos.
Unidad Central de Proceso. La unidad central de proceso es el componente principal de un

sistema de cómputo. En la figura 1.2 podemos ver sus componentes que son:
Figura 1.2: Componentes principales de la Unidad Central de Proceso

Unidad Aritmético Lógica. Su función primordial es la de efectuar los cálculos mate-

máticos usando números enteros solamente. Las operaciones más comunes son: multiplicación,
división, suma, resta, desplazamientos y rotaciones de bits a la derecha y a la izquierda, ope-
raciones lógicas como and, or, not, xor. Los elementos que usa pueden ser registros, valores
enteros constantes o localidades de memoria. Los cálculos de punto flotante serán realizados
por coprocesadores matemáticos. Actualmente, la mayoría de las computadoras cuentan ya un
coprocesadores matemáticos integrados en el chip del procesador.
Registros. Los registros son usados por la unidad aritmético lógica y pueden ser de ocho,
dieciseis, treinta y dos o sesenta y cuatro bits. Los registros de mayor cantidad de bits pueden ser
divididos en registros más pequeños, de acuerdo al tamaño de dato que vaya a utilizarse. Tene-
mos unos registros especiales llamados registros de índice que pueden ser usados para acceder
un dato a partir de un desplazamiento dado. Otro conjunto de registros está encargado de guardar
las direcciones correspondientes a segmentos de memoria que indican en donde se encuentran
los datos, el código y la pila. En algunas arquitecturas cualquier registro de propósito general
puede ser usado como registro índice.
Unidad de Control. Es un circuito encargado de decodificar una instrucción máquina en

microinstrucciones e indicar a la unidad aritmético lógica, a los registros, al bus de datos y al bus
de direcciones, las operaciones que deben de efectuar y el orden en el cual deben de ejecutarse.
Por ejemplo: MOV AX, número.
Las microinstrucciones que tendría que realizar son:
dirección(numero) −→ bus de direcciones
memoria(bus de direcciones) −→ bus de datos
contenido(bus de datos) −→ al registro AX
Bus de direcciones. La unidad de control debe de colocar aquí una dirección, ya sea de una
localidad de memoria principal o la de un dispositivo de entrada/salida. El número de bits usados
aquí determina la capacidad total en bytes de direccionamiento en la memoria. por ejemplo, si
contamos con un bus de direcciones de 32 bits, el número máximo de localidades que podemos
acceder es de direcciones totales = 232 bytes.
Bus de datos. Se encarga de enviar los datos a memoria principal y a los dispositivos de
entrada/salida. Es necesario que antes se coloque una dirección en el bus de direcciones. El
tamaño de los datos que se pueden extraer de la memoria depende del número de bits usados
aquí.
Memoria principal. La memoria principal también llamada Memoria de Acceso Aleatorio

es un área de almacenamiento de miles o miles de millones de bytes. Un byte se compone
de ocho bits. Por lo común está implementada con tecnología DRAM (Memoria Dinámica de
acceso Aleatorio). El procesador puede acceder a cualquier posición de memoria colocando su
dirección en el bus de direcciones.
Cualquier programa que deba ser ejecutado, se debe primero cargar en un área de memoria,
comúnmente conocida como segmento de código. Los datos que ocupa este programa también
deben de colocarse en la memoria y para ello se asigna otra área de memoria denominada seg-
mento de datos. Un programa también necesita espacio para ir guardando información acerca
de las llamadas a funciones -ya sea que pertenezcan al mismo programa, o que sean llamadas al
sistema-. Esta información permite regresar a la instrucción que está después de la llamada a la
función correspondiente. A esta área de datos se le conoce como segmento de pila. Dependiendo
del sistema operativo y del tipo de arquitectura de la computadora este segmento puede crecer de
abajo hacia arriba o de arriba hacia abajo. Por ejemplo, en una arquitectura Intel la pila crece de
arriba hacia abajo. Esto es, el principio de la pila se encuentra en la dirección más alta disponible
en el segmento y cada vez que se agrega información el tope de la pila se va decrementando.
En el caso ideal sería recomendable que el o los programas a ejecutar junto con sus datos
residan siempre en memoria principal. Debido al tamaño de ésta no es posible, ya que es pe-
queña en comparación con otros medios de almacenamiento. La mayoría de los programas son
muy grandes y además el sistema operativo también consume una cierta cantidad de memoria.
Por otro lado, este tipo de memoria es temporal y ante cualquier falla eléctrica, la información
contenida se elimina. Por lo tanto, es necesario que haya otro modo de almacenamiento de datos
a largo plazo. Esta tarea se lleva a cabo por la memoria secundaria.
La gran ventaja de esta memoria es su velocidad de acceso, pero desafortunadamente es cara,
comparada la tasa de costo por byte con otros dispositivos.
Dentro de este tipo de memoria tenemos otra aún más rápida pero así mismo también más
cara, es la memoria caché. La memoria caché está integrada en el chip junto con el procesador,
lo que la hace una memoria de acceso muy rápido. Por lo común se ocupa como una memoria
intermedia entre la memoria principal y el procesador. La memoria caché guarda información
que es muy posible que sea solicitada por el procesador. La unidad de control anticipa estos datos
de acuerdo a ciertos algoritmos de prioridad y al estar ejecutando alguna instrucción instruye
a la caché para leer -paralelamente a la ejecución- otras instrucciones o datos de modo que
el procesador, no tenga que hacer un acceso a la memoria principal, que es más lenta y que
en ciertos equipos el procesador debe de insertar varios ciclos de espera. Estos mecanismos
maximizan el tiempo de procesador ocupado.
Memoria Secundaria. Debido a que la memoria principal es pequeña se hace patente la nece-
sidad de mantener los datos en otros dispositivos a éstos se les agrupa en la categoría de memoria
secundaria. El dispositivo de almacenamiento secundario más común son los discos magnéticos.
Un disco va a dividirse primeramente en pistas, sectores y cilindros. Luego deben de asignarse
particiones o rebanadas que van a ser independientes. Si se daña una partición, es muy probable
que las demás estén intactas. Sobre cada partición puede montarse un sistema de archivos en el
capítulo 5 daremos una explicación detallada de sus estructuras y su administración, puesto que
es uno de los recursos más importantes de una computadora. Los discos magnéticos se clasifi-
can primordialmente en base a su velocidad, y ésta es medida comúnmente en revoluciones por
minuto (rpm), así tenemos discos de 5400 rpm, 720 rpm, 10000 rpm y 15000 rpm.
Otro aspecto muy importante es su capacidad en bytes, anteriormente se manejaban en me-
gabytes, por ejemplo, 10 Megabytes. En la actualidad podemos encontrar discos duros que van
desde 10 Gigabytes (y ya es pequeño) hasta terabytes. Un Kbyte equivale a 1024 bytes, 1 Me-
gabyte equivale a 1024 Kbytes, 1 Gigabyte equivale a 1024 Megabytes, 1 Terabyte equivale
1024 gigabytes. Actualmente es común encontrar discos duros de 100 gigabytes, 180 gigabytes
y más.
Desde un punto de vista tecnológico podemos clasificar a los discos duros por su interfase
con la computadora. Existen básicamente tres clasificaciones:
IDE/EIDE/ATA (Enhanced/Integrated Device Electronics/Advanced Technology Attach-

ment
SCSI (Small Computer-System Interface)
Sata (Serial ATA)
La tecnología IDE/EIDE/ATA tiene tasas de transferencia del orden de los 133 Megabits
sobre segundo. La tecnología SCSI ronda en una tasa de transferencia de alrededor de los 320
Megabits sobre segundo. La tecnología Sata tiene tasas de trasferencia del orden de los 300
Megabits sobre segundo.
A medida que aumenta la velocidad se incrementa el precio. También al aumentar la capaci-
dad aumenta el precio, aunque comúnmente no va en relación directa con la capacidad. Esto es,
puede adquirirse un disco de 200 Gigabytes por una fracción de dos discos de 100 Gigabytes.
Los discos SCSI son capaces de sostener la velocidad de transferencia aún cuando tengamos
varios dispositivos conectados al bus, lo que no sucede con las otras tecnologías. Además, la
tecnología SCSI está diseñada para trabajo pesado 24 horas al día, por 365 días al año, lo que
implica que si vamos a montar un sistema operativo como servidor es más recomendable instalar
un disco basado en tecnología SCSI.
Figura 1.3: Dispositivos de almacenamiento masivo
La regla del precio se aplica no solamente a los discos duros, podemos establecer una cla-
sificación basada en el costo por byte colocando primeramente los más caros para terminar con
los más baratos. En la figura 1.3 podemos ver esta relación. Observe cómo a medida que nos
alejamos del procesador la velocidad disminuye y también el precio. La única excepción que
puede hacerse son las memorias USB que cada día son más baratas, incluso se están diseñando
memorias de este tipo para substituir a los discos duros.
Hay que hacer notar que los dispositivos de almacenamiento también podemos clasificarlos
en memoria volátil y no volátil. De este modo, los registros, la memoria caché y la memoria
RAM caen dentro de la categoría de memorias volátiles Todos los demás caen dentro de la otra
categoría
Dispositivos de Entrada/Salida. Un sistema de cómputo cuenta con muchísimos dispositi-

vos de entrada/salida incluyendo los vistos en la sección 1.1.1.2. El sistema operativo dedica
gran parte de su código en la implementación de los controles necesarios para administrar a los
dispositivos de almacenamiento y a los de entrada/salida.
Cualquier fabricante de dispositivos que se conecten directamente al bus o a algún puer-
to, deberá proporcionar un controlador. Este controlador se encarga de comunicar al sistema
operativo con el hardware específico del dispositivo.
El sistema operativo asigna a cada dispositivo un conjunto de búferes, independientes de los
búferes que pueda contener el propio dispositivo, y les asigna un número de interrupción (en
ocasiones el mismo controlador le indica al sistema operativo qué interrupción usará). Cuando
tenemos varios dispositivos del mismo tipo por lo general compartirán la misma interrupción,
pero éstos tendrán adicionalmente un número de dispositivo único. Al generarse la interrupción,
se verifica qué dispositivo la generó para que la unidad central de proceso pueda atenderlo.
Una interrupción es una rutina de software que permite atender un suceso generado por algún
dispositivo. En este caso por el controlador del dispositivo. Es el mecanismo que usa el sistema
operativo para comunicarse con todos los dispositivos.
Las interrupciones se generan para avisar a la unidad central de proceso que ha sucedido
un evento. Este evento puede indicar que ha terminado la operación solicitada, que hubo erro-
res o que necesita que se le envíen más datos. Las interrupciones se clasifican en dos grupos:
interrupciones de hardware e interrupciones de software.
Las interrupciones de hardware son generadas por los dispositivos para indicar que ha su-
cedido un evento en ellos. Las interrupciones de software las maneja el sistema operativo para
tratar errores generados por operaciones en los programas tal como rebasar los límites de un
arreglo o una división por cero.
Al solicitar una operación de entrada/salida el controlador, coloca los valores adecuados en
los registros del hardware. El hardware decodifica la instrucción y la ejecuta. La mayoría de
los dispositivos pueden manejar dos tipos de transferencia de datos, ya sea una transferencia
orientada a caracter o una transferencia orientada a bloques. Dependiendo del modo el hard-
ware comienza la transferencia de la información al búfer local. Cuando termina le indica al
controlador vía una interrupción hardware que la operación ha terminado.
La entrada/salida basada en interrupciones es adecuada cuando se transfieren pocos bytes
¿pero qué sucede cuando se necesita transferir grandes cantidades de información?
Se le debe indicar al controlador el modo que va a usar si va ser una transferencia tipo ca-
racter o tipo bloque.Si vamos a transferir una gran cantidad de información usando el modo
caracter, habrá un tremendo desperdicio de tiempo ocasionado por las interrupciones. Por ejem-
plo si se leen 300 Kbytes, se habrá de llamar al controlador 300,000 veces. En cambio, si se usa
el modo transferencia basado en bloques. El controlador solamente será llamado una sola vez
vía interrupción hardware, cuando se haya terminado de transferir los 300 Kbytes. Para lograr
que sea posible transferir cantidades de información grandes, al controlador se le asignan áreas
de memoria llamadas búffers
Después de haber descrito los componentes de una arquitectura tipo Von Newmann, ahora
corresponde analizar otro tipo de clasificación basada en el número de procesadores que puede
tener un sistema de computadora.
Sistemas monoprocesadores. La mayoría de los sistemas de computadora actuales utilizan

solamente un procesador. No obstante, su diversidad es tremenda, dado que los podemos encon-
trar desde un Asistente Digital Personal o PDA hasta un mainframe
Un sistema monoprocesador tiene un solo procesador capaz de ejecutar un variado conjunto
de instrucciones que a medida que van lanzando nuevas versiones de procesadores este con-
junto va aumentando. La mayoría de las computadoras actuales tienen también procesadores
especializados. Por ejemplo, una tarjeta de vídeo tiene una memoria principal separada del resto
del sistema y un procesador dedicado a administrar la entrada/salida del vídeo. De esta forma,
el procesador central queda libre para realizar otras tareas. El disco duro y el teclado cuentan
también con procesadores especializados.
Los procesadores de propósito especial sólo ejecutan instrucciones relacionadas con su tarea,
no pueden ejecutar procesos de usuario. El sistema operativo sólo les indica qué tarea deben de
realizar y monitorea sus avances y sus resultados. Este monitoreo se hace como se explicó en el
apartado 1.1.1.2 vía interrupciones.
Aunque un sistema de computadora tenga varios procesadores de propósito especial no sig-
nifica que sea multiprocesador. En este caso solamente cuentan los procesadores que son capaces
de ejecutar procesos de usuarios y no tareas específicas.
Un sistema monoprocesador, puede ser usado por un sistema operativo monousuario como
los basados en el antiguo DOS (Disk Operating System) sistema Operativo de disco, en sus
versiones ms-dos de microsoft, dr-dos de Digital Research y os-dos de IBM o por la línea de
microsoft winXX de computadoras personales.
Pueden también ser usados con un sistema operativo multitarea y multiusuario tal como
UNIX(Solaris, GNU/Linux entre otros) o los de microsoft en su línea de sistemas operativos de
red como windows NT, 2000, o 2003 server.
La mayoría de los sistemas operativos multitarea/multiusuario basados en red tienen soporte
para multiprocesadores en menor o mayor grado.
Sistemas multiprocesadores. Un sistema multiprocesador es aquel que cuenta con más de un

procesador que puede ejecutar instrucciones de propósito general o procesos de usuario.
Estos procesadores están dispuestos de tal forma que pueden compartir memoria, el bus de
datos, el bus de direcciones y los dispositivos de entrada y salida. Un sistema multiprocesador,
también conocido como sistemas paralelos o fuertemente acoplados tiene las siguientes ventajas:
Mayor rendimiento. Teniendo más de un procesador el sistema operativo puede estar ejecu-
tando dos procesos de usuario en paralelo o dividir un proceso en varios subprocesos para
asignarlos a cada procesador. Esto no significa que el tiempo pueda reducirse a la mitad.
el tiempo efectivo de ejecución tiene que ver con el grado de paralelización que puede
hacerse sobre un proceso y las dependencias de información que existan entre ellos.
Compartir recursos. Como todos los procesadores comparten los mismos dispositivos, el cos-
to adicional en procesadores es mucho menor a tener varias computadoras con todo y
periféricos.
Tolerancia a fallos. Si el sistema operativo es capaz de administrar adecuadamente los proce-

sos asignados a diferentes procesadores, cuando un procesador falle, el trabajo que estaba
haciendo se reasigna entre los demás procesadores. En este caso el sistema no deja de
funcionar, solamente sufre una degradación directamente proporcional al número de pro-
cesadores que fallen.
En la actualidad se usan solamente dos tipos de arquitecturas de sistemas multiprocesadores:
Multiprocesamiento Asimétrico. Existe un procesador maestro que se encarga de administrar

y asignar las tareas a los demás procesadores La forma más común es asignar una tarea
por procesador. Aquí tenemos un ejemplo de una relación maestro-esclavo. El procesador
maestro planifica y administra las tareas y se las asigna a los procesadores esclavo.
Multiprocesamiento simétrico. En esta arquitectura todos los procesadores realizan las tareas
que corresponden al sistema operativo. No existen relaciones maestro-esclavo.
Un ejemplo de sistema con multiprocesamiento simétrico es la versión Encore de UNIX

para la computadora Multimax. Este sistema puede configurarse de modo que utilice docenas
de procesadores, todos los cuales ejecutan una copia de UNIX. La ventaja de este modelo es
que muchos procesos pueden ejecutarse simultáneamente (N procesos si hay N CPU) sin que
haya deterioro del desempeño. Sin embargo, es preciso controlar cuidadosamente la Entrada
y salida para asegurar que los datos lleguen al procesador apropiado. Además, dado que las
CPU son independientes, una podría estar desocupada mientras otra está con exceso de trabajo,
con la consiguiente ineficiencia. A fin de evitar esto, los procesadores pueden compartir ciertas
estructuras de datos. Un sistema multiprocesador de este tipo permite compartir dinámicamente
trabajos y recursos entre los distintos procesadores, y puede reducir la variabilidad entre los
sistemas. Por otro lado, tales sistemas deben escribirse con mucho cuidado considerando los
accesos simultáneos a memoria o a disco a lo que se les denomina acceso a áreas críticas de
datos.
Hay que distinguir que la diferencia entre multiprocesamiento simétrico y asimétrico puede
deberse al software o al hardware. Podría existir hardware especial para diferenciar los múltiples
procesadores, o podría escribirse software que permita un solo maestro y varios esclavos. Por
ejemplo, el sistema operativo de Sun, SunOS versión 4, ofrece multiprocesamiento asimétrico,
mientras que la versión 5 (Solaris 2) es simétrica.
Sistemas cluster. Un sistema cluster se diferencía de un sistema multiprocesador en que ahora

tenemos computadoras interconectadas vía red.
Los clusters son usados en sistemas de alta disponibilidad, es decir, como estamos hablando
de computadoras individuales interconectadas, si una llega a fallar, entonces las demás pueden
tomar sus tareas y continuar con el trabajo. Es común que exista una capa de abstracción de
cluster. Esto hace que el cluster se vea simplemente como una computadora más, pero bajo la
capa podemos tener decenas o cientos de computadoras repartiéndose el trabajo. Los clusters se
pueden estructurar -al igual que los sistemas multiprocesadores- en simétricos y asimétricos. En
el modo simétrico ambos dos o más hosts ejecutan aplicaciones y se monitorean entre ellas. en
el modo asimétrico, mientras un host ejecuta las aplicaciones el otro esta en modo de espera mo-
nitorizando al primero. En el momento que llegue a fallar, reinicia las aplicaciones y el servicio
se restablece casi momentáneamente.
Otras formas de cluster incluyen el cluster en paralelo y los clusters conectados a una red de
área extensa (WAN wide area network).
Los clusters en paralelo permiten a múltiples equipos acceder a las mismas bases de datos.
Cabe aclarar que las aplicaciones deben diseñarse específicamente para usarse en este tipo de
sistemas, debido a que la mayoría de los sistemas operativos no soportan acceso múltiple a una
misma área de datos.
Dentro de las herramientas existentes para la administración de clusters tenemos a mosix y
a openmosix que son de las más utilizadas actualmente.
Como ejemplo de cluster de red, actualmente el cluster más grande diseñado hasta el mo-
mento fue desarrollado por google. Es un cluster que funciona a nivel mundial y con tiempos
de respuesta muy breves, el lector puede hacer una prueba con otros buscadores y comparar los
tiempos de respuesta.
1.1.1.3. Proceso de arranque de una computadora
Después de haber analizado los componentes de una computadora explicaremos ahora cómo
funciona. Al energizar la computadora, el procesador se inicializa, la primera tarea que se hace
es colocar una dirección específica en un registro denominado contador de programa. Esta di-
rección comúnmente señala a una dirección de memoria ROM (Read Only Memory, Memoria
de Sólo lectura). que contiene un conjunto de rutinas denominadas BIOS (Basic Input Output
System). La primera tarea que tiene a cargo el BIOS es verificar todos los componentes del
equipo. Se hace una verificación general de memoria, tarjeta de vídeo, se determina el tipo de
unidades de disco, teclado, ratón y otros componentes del Sistema. Si hay errores, se le avisa
al usuario mediante mensajes en pantalla. Si existe un problema en memoria o en el procesa-
dor a algún otro error grave entonces se detendrá el sistema. En caso de que hayan pasado las
pruebas adecuadamente o haya errores corregibles, se le da oportunidad al usuario de entrar a la
configuración del sistema. Esta tarea comúnmente se realiza, presionando una tecla o combina-
ción de ellas. Las teclas más comunes pueden ser supr, F1, F9, F10 dependiendo del fabricante
de la computadora. El usuario puede optar por continuar el proceso de arranque o corregir los
problemas encontrados durante las pruebas de dispositivos.
Si no hubo errores, el sistema continua con el proceso de carga. EL BIOS, después de haber
verificado los discos, consulta la secuencia de arranque establecida por el usuario en la confi-
guración básica del sistema. En ésta se le indica qué dispositivo debe de usar en primer lugar.
Una secuencia común es primero los discos duros, después las unidades de CDROM/DVD, las
memorias USB o pendrives, las unidades de disco flexible y por último se intentará hacer un
arranque desde la red.
El BIOS cargará una pequeña rutina que, por convención, se encuentra siempre en el primer
sector de cualquier unidad de almacenamiento comúnmente conocido como sector de arranque
o también conocido como Master Boot Record (MBR) Registro de Arranque Maestro. Puede
existir un sector de arranque por cada partición, pero la BIOS sólo cargará el MBR.
Esta rutina es un cargador, que a su vez puede controlar otros cargadores que se encuentren
en otras particiones del disco duro, permitiendo así el arranque de más de un sistema operativo.
Después que el usuario ha elegido qué sistema operativo desea ejecutar, el cargador leerá de
disco un programa más grande denominado kernel o núcleo y por último le pasará el control.
En un sistema operativo GNU/linux tenemos dos programas cargadores uno llamado lilo
(Linux Loader) y otro llamado grub. En windows el cargador más común es el NT loader.
La primera función del kernel es inicializar los servicios del sistema operativo. El primero y
más importante es inicializar la tabla o el vector de interrupciones, para de esta manera, poder
atender todas las peticiones de servicios de los dispositivos y los servicios de software solicitados
vía interrupción como se explicó en la sección 1.1.1.2.

Ya que el sistema operativo inicializó todas sus estructuras de datos, el siguiente paso es em-
pezar a cargar los programas necesarios para interactuar con los usuarios. En un sistema basado
en UNIX el primer proceso que se carga es uno denominado init(), éste también es el padre de
todos los procesos. Este a su vez comienza un proceso para verificar los dispositivos existentes
en el equipo y así cargar los controladores necesarios para manejar el hardware -si es que todavía
no existe una lista de hardware del equipo-. La mayoría de los sistemas operativos orientados a
equipos personales cargan un programa que verifica si es que hay hardware nuevo y así cargar
su controlador correspondiente. En un sistema operativo orientado a entornos empresariales, es
necesario que se instale manualmente el controlador para que pueda ser reconocido por éste.
Ya que se tienen los controladores de los dispositivos, el sistema operativo comienza a cargar
los servicios. Si hablamos de un entorno empresarial comenzará a cargar los servicios de correo,
páginas web, el de transferencia de archivos, los de conexión remota, entre otros y se pondrá a la
escucha de eventos para atender las peticiones de los usuarios o de otros sistemas. En sistemas
basados en UNIX, puede iniciar el modo gráfico, mostrando una pantalla para solicitar el nombre
de usuario (login) y enseguida la contraseña para darle acceso al sistema o puede solicitar en
modo texto la misma información. En el caso de modo texto el sistema operativo iniciará un
programa basado en shell o línea de comandos, en donde el usuario escribe las órdenes que
desea sean ejecutadas.
En un sistema operativo orientado al usuario, después de haber cargado los controladores
iniciará una interfaz gráfica solicitando el nombre de usuario y su contraseña para que pueda
acceder al sistema.
En un sistema basado en windows en un entorno personal, lo más común es que cargue muy
pocos servicios. Estos los cargará hasta que el usuario haya iniciado sesión.
En los sistemas basados en windows pero con versiones empresariales o de red, el sistema
operativo cargará los servicios aunque ningún usuario haya iniciado sesión y se pondrá a la
escucha para atender las peticiones externas.
1.2. Funciones y características

Un sistema operativo moderno se divide en subsistemas de modo que sea más fácil su di-
seño. Estos subsistemas están orientados al control de cada elemento de una computadora. Así,
tenemos un subsistema administración de procesos, un subsistema de planificación de CPU, un
subsistema administrador de memoria, un subsistema administrador de dispositivos y un subsis-
tema administrador de sistemas de archivos.
18 1.2. FUNCIONES Y CARACTERÍSTICAS
1.2.1. Administración de procesos

Como se explicó en la sección 1.3.2, un programa tenía el control completo de los recursos
de la computadora. Cuando terminaba su ejecución regresaba el control al sistema operativo
mediante una instrucción determinada. Si el programa no incluía esa instrucción entonces la
computadora simplemente se detenía. Los sistemas de computadora actuales, pueden tener múl-
tiples programas en memoria y ejecutarlos asignándoles una cantidad de tiempo predeterminada.
Para poder lograr lo anterior, se creó el concepto de proceso. Un proceso es una instancia de un
programa en memoria que se está ejecutando o listo para ejecutarse. Este nuevo enfoque no
puede permitir que un programa se apropie de todos los recursos y mucho menos permitir que
se detenga la computadora. Como podemos ver, el sistema operativo debe de tener todo el con-
trol de lo que sucede con los recursos de cómputo como el tiempo de CPU, la memoria, los
dispositivos de entrada/salida y el sistema de archivos.
La definición de un sistema operativo, como se dijo en la sección 1.1, es una interfaz con el
usuario. Mientras más complejo sea el sistema operativo, debe de realizar más tareas para estos
usuarios. Aunque la tarea principal es ejecutar programas, también debe hacer cargo de otras
tareas que no están incluidas en el núcleo.
Visto de esta forma un sistema está constituido por un conjunto de procesos: procesos que
forman parte del sistema operativo que realizan tareas del sistema y procesos de usuario que
hacen tareas relacionadas con el trabajo de los usuarios. Todos estos procesos pueden ejecutarse
de manera concurrente, esto es, pueden solicitar el mismo recurso al mismo tiempo, ya sea
multiplexando el tiempo de CPU o siendo asignados a diferentes CPU’s. Distribuyendo el tiempo
de CPU entre los diferentes procesos, el sistema operativo puede incrementar la productividad
de la computadora.
Un proceso es una instancia de un programa en memoria o en ejecución. Cuando el sistema
operativo carga un programa en memoria se le denomina proceso.
1.2.1.1. Concepto de proceso
En el transcurso de la historia de los sistemas operativos ha sido necesario nombrar las acti-
vidades que se realizan dentro de una computadora. En un sistema por lotes se les denominaba
trabajos, un sistema de tiempo compartido los llama programas de usuario o tareas. Incluso
un sistema operativo puede estar ejecutando un mismo programa dos o más veces. Todas estas
actividades tienen mucho en común por lo que a todas ellas se les llama procesos. EL concepto
que se usa más a menudo es el de la sección 1.2.1. Hay que tomar en cuenta que un proceso es
mucho más que sólo código de un programa que se está ejecutando (a lo que se le denomina en
muchas ocasiones como sección de texto). Un proceso incluye además de su código, informa-
ción necesaria para que el sistema operativo pueda darle seguimiento. En general va a contener
la siguiente información:
Estado del proceso. Puede ser: nuevo, preparado, en ejecución, en espera, detenido, terminado
o zombie
Contador de programa. Indica la dirección de la siguiente instrucción a ejecutarse.
registros de la CPU. Guarda la información necesaria de los registros para regresar al proceso
al estado en el que se encontraba para continuar su ejecución.
Información de planificación de la CPU. Incluye la prioridad del proceso, los apuntadores a

las colas de planificación y otros parámetros.
Información de la memoria. Contiene información referente a las tablas de páginas o segmen-

tos y registros índice. La información varía dependiendo de el mecanismo de administra-
ción de memoria que se utilice.
Información contable. Incluye la cantidad de tiempo real ocupado por el proceso, los cuantos
de tiempo 4 , el PID (Processs IDentifier) o identificador de proceso,etc.
Información de la E/S. Incluye la lista de los dispositivos de E/S asignados al proceso, una
lista de manejadores de archivos y su estado: abiertos para lectura, escritura, bloqueados.
Contiene también un área de datos y un área de pila. El área de datos es usada por el proceso
para mantener la información que necesita durante su ejecución. El área de pila es ocupada
para pasar información entre subrutinas propias de proceso e interactuar también con el sistema
operativo para enviar o recibir información.
1.2.1.2. Planificación de procesos
El objetivo de la multiprogramación es maximizar el el tiempo de uso de la CPU. Esto co-

múnmente se logra manteniendo en memoria muchos procesos y ejecutando cada uno durante
varios cuantos de tiempo. La frecuencia de ejecución debe ser tal que el usuario tenga la ilusión
de que el sistema está dedicado solamente a él. Para conseguir este objetivo el planificador de
procesos selecciona un proceso disponible de la cola de procesos y lo pone en la CPU para em-
pezar su ejecución. Si hay más procesos deben de esperar su turno para ser ejecutados. Cuando
se cambia un proceso por otro, se realizan varias actividades, la principal se le denomina cambio
de contexto. Un cambio de contexto implica guardar el estado actual del proceso en ejecución,
4
Se refiere a la cantidad de tiempo asignada al proceso
ya sea en memoria o en disco y restaurar el estado anterior del nuevo porceso a ejecutar para que
continúe exactamente donde fue interrumpido. el tiempo que consume un cambio de contexto
es tiempo de CPU que no ejecuta ninguna tarea de usuario, mientras menos cambios de contex-
to existan en el sistema, más tiempo se dedicará a tareas productivas. el tiempo de cambio de
contexto depende mucho del soporte que proporcione la arquitectura de la computadora sobre la
que se encuentre el sistema operativo. Algunas incluyen múltiples conjuntos de registros, con lo
que un cambio de contexto implica solamente un cambio de un apuntador a un nuevo conjunto
de registros. En otras sin embargo, debe de guardarse en la pila del proceso toda la información
de estado de los registros, lo cual implica muchas instrucciones y por tanto, ciclos de CPU.
1.2.1.3. Operaciones sobre procesos
En la mayoría de los sistemas operativos actuales, se pueden ejecutar varios proceso concu-
rrentemente y podemos crearlos y eliminarlos en la medida en que sea necesario, esto implica
que el sistema operativo debe tener mecanismos para la creación, ejecución y eliminación de un
proceso.
Creación de Procesos. Un proceso puede crear varios procesos más que le ayuden a terminar
su tarea más rápido. Al proceso que crea se le llama proceso padre y a los que creó se les
denomina procesos hijo. Cada uno de los nuevos procesos puede crear a su vez nuevos procesos.
De esta forma se construye un árbol de procesos. Cada proceso es identificado por un número
único, y se le denomina PID(Process IDentifier) o Identificador de Proceso.
Terminación de procesos. Un proceso termina cuando ejecuta su última instrucción y hace

una llamada al sistema operativo por lo común usando una función exit(). Y si es un proceso
hijo el sistema operativo devolverá el valor pasado a exit al padre quien lo recibirá mediante una
llamada al sistema llamada wait(). A partir de este momento el sistema operativo libera los
recursos asignados al proceso, los archivos abiertos y los búferes de entrada/salida.
Uno de los problemas principales de los procesos es que debe de hacerse una copia de todo el
proceso padre incluyendo al hijo, lo que implica una gran carga durante el cambio de contexto.
Una variante más eficiente de un proceso se le denomina hilo. Un hilo es solamente una porción
de código que tiene acceso al área de datos del proceso padre, por lo que no es necesario copiar
toda la información del proceso
1.2.2. Planificación de CPU

Planificar el tiempo de CPU fue la innovación más importante para lograr la multiprograma-
ción. La planificación, permite establecer la cantidad de tiempo que se asigna a cada proceso,
de modo que cuando se termine, el planificador pueda asignar la CPU a otro proceso. De esta
forma, mientras haya procesos a ser ejecutados, la CPU no estará desocupada.
De forma general existen dos tipos de planificadores. Los planificadores a corto plazo y los
planificadores a largo plazo. En el capítulo 1.2.2 haremos una descripción más extensa de estos
tipos de planificadores.
Para poder llevar a cabo sus tareas de administración, el sistema operativo debe obtener el
control de la CPU cada cierto tiempo. La planificación apropiativa, consiste básicamente en que
el sistema operativo toma el control de la CPU y todos los recursos del proceso debido a una de
las siguientes causas:
El Proceso entró un el estado de espera. El proceso está esperando los resultados de una ope-
ración de entrada/salida.
Se han terminado los cuantos de tiempo o se produce una interrupción. El proceso pasa al
estado de preparado, esperando nuevamente su oportunidad de ejecución.
El proceso sale de un estado de espera Cuando se termina una operación de entrada salida pa-
ra un proceso, éste pasa al estado de preparado.
Terminación del proceso. Cuando termina el proceso, el sistema operativo se apropia de la

CPU y libera los recursos asignados al proceso.
1.2.2.1. Planificador a corto plazo.
Selecciona un proceso de la lista de procesos listos a ejecutarse, hace el cambio de contexto

y le cede la CPU para su ejecución. Las estructuras de datos más comúnmente utilizadas son las
colas FIFO, una cola con prioridades, un árbol o simplemente una lista enlazada no ordenada.
1.2.2.2. Planificador a largo plazo.
Hace un análisis más detallado acerca de las necesidades de cada proceso para que, de acuer-
do con sus resultados, se ejecute el que sea más idóneo.
Existen varios algoritmos para llevar a cabo la planificación. El más simple de ellos es el
FCFS (First Coming First Served), primero en llegar, primero en ser servido. Este enfoque asig-
na la CPU al primer proceso que lo solicite. Otro enfoque es el SJF (Shortest Job first). Este
algoritmo asigna la CPU a aquel proceso que tenga más oportunidad de terminarse primero.
La planificación por prioridades es más general que la estrategia SJF. El sistema operativo le
asocia cierta prioridad a cada proceso y entonces se le asigna la CPU a aquel que tenga la prio-
ridad más alta. Si tienen la misma prioridad entonces se usa la estrategia FCFS. Otra forma de
planificación es la planificación por turnos, diseñado especialmente para ser implementado en
sistemas de tiempo compartido. Es parecido a la FCFS pero se aplican conceptos de apropiación
para conmutar entre procesos. La planificación mediante colas multinivel permite dividir las
necesidades de los procesos en clases. Por ejemplo, un proceso interactivo necesita ser atendido
más rápidamente que un proceso basado en lotes. De esta forma, se establecen varias colas con
prioridades diferentes. Cada cola puede tener su propio algoritmo de planificación. debe, por su-
puesto, definirse una planificación entre colas. Una variación a este esquema es la planificación
mediante colas multinivel realimentadas, el cual permite que los procesos puedan migrar a
otras colas, de acuerdo a sus necesidades de ejecución.
1.2.3. Administrador de memoria

El objetivo del administrador de memoria es aprovechar al máximo la memoria principal
de la computadora, puesto que es escasa y cara. Además en el apartado 1.2.2 se mostró cómo
es que debe de planificarse la CPU para poder atender varios procesos . Esto significa que el
sistema operativo debe de ser capaz de poder compartir la memoria entre todos los procesos que
se encuentren en ejecución en la computadora.
La memoria es un componente muy importante para la operación de un sistema de compu-
tadora actual. Podemos ver a la memoria como un arreglo de palabras o bytes cada uno con su
propia dirección. la CPU guarda en un registro denominado contador de programa la siguiente
dirección de la instrucción a ejecutar. La lee y el contador se incrementa, la instrucción es ejecu-
tada, El programa puede contener instrucciones que indiquen si se van a leer datos o a escribir
datos a la memoria.
Existen varias técnicas de administración de memoria. Las más comunes son la asignación
de memoria estática o asignación de memoria por segmentos y la asignación de memoria me-
diante páginas. Antes de abordar estos métodos de asignación de memoria hablaremos de algu-
nos conceptos básicos como el funcionamiento de la memoria, la reasignación de la memoria,
direcciones lógicas y físicas y memoria virtual.
1.2.3.1. Funcionamiento básico de la memoria
Los registros de la CPU y la memoria principal son las áreas a las que puede acceder la CPU
de forma directa. Como se explicó en la sección 1.1.1.2, la CPU puede acceder a los registros
a la velocidad de uno o dos ciclos de reloj, siendo el área de acceso más rápido. Para acceder
a la memoria principal es necesario colocar primeramente la dirección del dato y luego esperar
a que la memoria recupere el dato y lo coloque en el bus de datos. El problema principal es
que la tecnología con la cual está hecha la tarjeta madre o base es diferente a la tecnología del
microprocesador. Mientras que un procesador típico actual trabaja a velocidades del orden de los
giga Hertz 5 (Entre uno y cuatro Giga Hertz). Un ciclo viene dado por la distancia que existe entre
un pico y el siguiente valle. El bus de direcciones y datos de la tarjeta madre trabaja en el orden
de los Mega Hertz (en el orden de los 33 Mega Hertz para modelos antiguos hasta 800 Mega
Hertz en los modelos actuales). En el mejor de los casos , si hablamos de un procesador a una
velocidad de 1.6 Giga Hertz y un bus de tarjeta madre de 800 Mega Hertz, estamos hablando de
una diferencia de magnitud 2. Si la tarjeta madre tiene un bus a una velocidad de 400 Mega Hertz
la diferencia es de magnitud 4. Esto significa que el procesador debe de permanecer inactivo
durante el doble o cuatro veces el tiempo mientras espera que la memoria termine de hacer su
transferencia. Para minimizar este problema, se hace uso de memoria caché con tecnología de
preacceso, la cual intenta leer con anticipación los datos que usará el procesador.
En un nivel perteneciente al sistema operativo, se debe tener en cuenta que en un sistema de
multiprogramación, cada usuario sólo debe tener acceso a la memoria que le ha sido asignada y
no a otras áreas. Para ayudar al sistema operativo, existe hardware al que el sistema operativo le
indica cual es el rango de direcciones legales a las que puede acceder el proceso. Si se intenta ha-
cer una lectura más allá de lo permitido, el hardware generará una interrupción predeterminada
que pasará nuevamente el control al sistema operativo. El sistema operativo terminará inmedia-
tamente el proceso enviándole una señal kill, y mostrará un mensaje de violación de segmento.
Los registros que se usan, usualmente un registro base y un registro límite solamente pueden
ser cambiados por instrucciones que pueden ejecutarse en modo protegido. Puesto que sólo el
kernel se ejecuta en este modo, es el único que puede manipularlos. Si un programa intenta ha-
cer uso de estas instrucciones se generará una interrupción indicando que no es una instrucción
permitida. De esta forma se imposibilita que el usuario acceda a áreas de memoria que no le
pertenezcan.
1.2.3.2. Reasignación de direcciones
La mayoría de los programas, cuando se compilan o se ensamblan, lo hacen a partir de la di-

rección 00000. pero cuando se carga un programa del disco, la dirección de la memoria en la que
se carga no va a ser precisamente 00000. Va a depender del segmento que le haya proporcionado
el manejador de memoria. Lo que hace aquí el sistema operativo es añadir el desplazamiento co-
5
Los Hertz son una unidad de medición de ciclos por segundo esto es: 1Hz = 1/(Ciclo P or Segundo)
rrespondiente a las instrucciones que lo necesiten. Esta información, se encontrará comúnmente

en el encabezado del programa binario.
Por otro lado, se ha implementado un conjunto de librerías dinámicas que están disponibles
para muchos de los programas y que posiblemente se esté ejecutando más de una instancia del
mismo, lo que ocasionaría tener espacio de memoria desperdiciado por tener dos instancias del
mismo código. Una librería dinámica se cargará solamente una vez y podrá entonces ser utilizada
por muchos programas evitando de esta manera el desperdicio innecesario de memoria.
1.2.3.3. Espacio de direcciones lógico y físico
Una dirección lógica es aquella que es generada por la CPU. Una dirección física es aquella
con la que realmente trabaja la memoria principal. La correspondencia entre direcciones lógicas
y físicas la hace un dispositivo de hardware denominado MMU (Management Memory Unit),
Unidad de Administración de Memoria. Su función es parecida al proceso de relocalización.
Tenemos una dirección base más un desplazamiento, entonces suma toas las direcciones para
obtener la dirección física real en donde están los datos.
1.2.3.4. Memoria virtual
Ya sabemos que la cantidad de memoria que existe en una computadora es limitada. Cuando
tenemos muchos programas corriendo, lo más común es que esta memoria se acabe muy pronto.
Una solución para “aumentar” la capacidad de la memoria principal es mediante una técnica
denominada memoria virtual. la memoria virtual es espacio de disco en memoria secundaria
asignado exclusivamente para mantener procesos que están el estado de suspendidos, dormi-
dos o en espera. En el momento en que se reanude su ejecución, el sistema operativo, hará un
intercambio de contexto como es normal, pero ahora cargará de disco parte o todos los datos per-
tenecientes al proceso. Esto da al usuario la ilusión de contar con el doble de memoria de lo que
realmente tiene la computadora. Aunque a primera vista parece una buena opción, cuando el sis-
tema se sobrecarga, el sistema operativo tardará mucho más en hacer un intercambio de contexto
desde memoria secundaria que desde la memoria primaria que es más rápida, recrudeciendo aún
más el problema.
1.2.3.5. Asignación de memoria contigua
Lo más común es dividir la memoria en dos partes una para el sistema operativo y otra
para los procesos de los usuarios. La ubicación del sistema operativo está determinada en parte
por la ubicación del vector o tabla de interrupciones para el manejo de los dispositivos. Como
la mayoría de los microprocesadores asume que está colocada en la parte baja, muchos de los
diseñadores colocan al sistema operativo después de la tabla de interrupciones. Esto es, en la
parte baja de memoria.
En la asignación contigua de memoria, al momento de crear un proceso, éste se asignará
a un único bloque que tenga el tamaño solicitado por el mismo. Hay que tener en cuenta que
es normal que los datos se coloquen en otro segmento o bloque de memoria, de esta manera
es más fácil conseguir dos bloques de la mitad de tamaño a uno grande para guardar tanto los
datos como el código. En la asignación de memoria contigua, el número de procesos que pueden
existir al mismo tiempo depende del número de particiones fijas que tenga disponible el sistema,
de modo que cada partición puede contener solamente un proceso.. Cuando un proceso termina,
la partición vuelve a estar disponible para ser asignada a otro que vaya a ejecutarse. Bajo este
esquema, a medida que va transcurriendo el tiempo y van ejecutándose procesos con diferentes
tamaños, la memoria va fragmentándose en bloques muy pequeños que no pueden unirse para
satisfacer una solicitud del sistema. Entonces, aunque sumando todos los fragmentos disponible
haya espacio suficiente para cubrir los requerimientos de uno o más procesos, el sistema falla
por que no está junta. El sistema operativo puede indicar el fallo al usuario o iniciar una tarea de
compactación de memoria para reorganizar nuevamente la memoria ocupada y la libre. Aunque
este procedimiento puede resultar muy caro computacionalmente hablando.
1.2.3.6. Asignación de memoria por páginas
El otro enfoque es tener bloques de memoria pequeños y de tamaño fijo. Este esquema
permite que el espacio de direcciones físicas no sea contiguo. La paginación evita el considerable
problema de buscar un bloque lo suficientemente grande como para poner un proceso cuando
la memoria se encuentra muy fragmentada o en su defecto la compactación, tanto de memoria
principal como de la secundaria o la memoria virtual.
La manera más sencilla de implementar la paginación es descomponer la memoria física
en bloques denominados frames o marcos de tamaño fijo. Cuando el sistema operativo carga
un proceso, le asigna tantos marcos de memoria como sean necesarios. Los dispositivos de
almacenamiento secundario también están organizados de la misma forma, así se facilita la
carga de marcos desde el disco a la memoria. El tamaño de página está definido por el hardware
en potencias de dos y está en el rango de 512 bytes hasta 16 MegaBytes.
Cuando se usa un esquema de paginación, no existe el problema de fragmentación, puesto
que todos los marcos pueden ser asignados a diferentes procesos independientemente de donde
se encuentren. El problema con el que nos encontramos ahora es una fragmentación interna. Si
el proceso no es un múltiplo exacto del tamaño de página entonces, el último marco estará par-
cialmente lleno, no obstante en promedio su rendimiento es mejor que la asignación de memoria

contigua.
1.2.4. Administrador de dispositivos

Un sistema operativo dedica la mayor parte de su código para tratar con los dispositivos de
entrada salida. Puesto que es el medio por el cual se comunica con los usuarios debe de im-
plementar estrategias para la manipulación correcta de éstos. En la sección 1.1.1.2, se describió
la forma mediante la cual un dispositivo interactúa con el sistema operativo. los dispositivos
de entrada/salida actuales cuentan con procesadores llamados satélites que ayudan a la CPU a
cumplir las tareas de entrada/salida más lentas. por ejemplo una impresora es varios órdenes de
magnitud más lenta que la ucp, sin embargo, la ucp hace una transferencia de datos al spool
del administrador de impresoras y éste a su vez hará una transferencia al búfer de memoria de
la impresora, ésta tiene una capacidad que varía entre los 2 Mega bytes hasta los 256 Mega
bytes. Lo más común es que incluyan 8 o 16 Mega bytes. Capacidades arriba de ellas son op-
cionales y muy caras. Cuando la impresora termine los datos que se encuentran en su búfer el
procesador satélite generará una interrupción indicando que le envíen más datos. La interrupción
será atendida por el sistema operativo y la transferirá al proceso encargado de la administración
de impresión, enviándole éste otro bloque de datos. Así la CPU puede seguir atendiendo otros
procesos. Como podemos ver, en realidad un dispositivo es tratado de la misma forma que un
proceso con la diferencia de que a este proceso ahora se le llama controlador éste puede acceder
directamente al hardware. El sistema de entrada salida proporciona una abstracción en la que
los dispositivos de entrada/salida y los archivos, se tratan con las mismas llamadas al sistema,
variando, obviamente el significado de las operaciones realizadas sobre ellos. En general, así
como es posible abrir, leer, escribir, obtener el estado de un archivo y cerrarlo, esas mismas ope-
raciones también pueden hacerse sobre la mayoría de los periféricos. Los dispositivos de entrada
salida comparten dos características que en general definen el problema básico de su manejo:
1. Operación asíncrona
2. Diferencia en velocidad
Operación asíncrona. Cuando el procesador está ejecutando uno o varios procesos, está inter-
actuando continuamente con la memoria. Coloca una dirección en el bus de direcciones
y la memoria le responde con el dato o instrucción correspondiente en el bus de datos.
Durante ese período en el que la memoria está trabajando, el procesador entra en un pe-
ríodo de inactividad. Así, decimos que trabaja en sincronía con la memoria. Además, el
procesador trabaja con el supuesto de que, a menos que la memoria esté dañada y que
es la excepción a la regla, no habrá ningún problema. El procesador no puede ocuparse
de otras tareas mientras la memoria esté trabajando. Un dispositivo, por el contrario, a
veces estará disponible y otras no. Además el procesador no puede estar esperando hasta
que el dispositivo se habilite. Aún trabajando, la mayoría de los dispositivos cuenta con
partes mecánicas que se gastan y pueden ocurrir errores o en ocasiones es necesaria la
intervención humana para que el dispositivo continúe trabajando normalmente. Por todo
lo anterior, decimos que los dispositivo trabajan asíncronamente con respecto al reloj del
procesador.
Como podemos deducir, se necesita algún tipo de diálogo entre el procesador y los peri-
féricos. Como apuntamos en la sección 1.1.1.2 este diálogo se puede dar, desde el punto
de vista del dispositivo, vía interrupciones. Desde el punto de vista del procesador, éste
puede consultar directamente los registros de estado del dispositivo en caso de necesitar
alguna información. Si está disponible puede leerla del búfer. En otro caso deberá esperar.
En este momento el procesador pasará a realizar otra tarea y si es necesario volverá pos-
teriormente a verificar los registros de estado del dispositivo, si es que no se ha generado
una interrupción del dispositivo para alertar sobre algún suceso. Cuando se completa la
operación de entrada salida, el dispositivo enviará una señal, para que sea atendido por el
procesador. Si el dispositivo no puede enviar señales, la información será recogida hasta
que el procesador vuelva a verificar los registros de estado.
Diferencia en velocidad. Existe una gran variadad de dispositivos de entrada/salida, así como
también protocolos para permitir su comunicación con la CPU. La velocidad del dispositi-
vo está relacionada directamente con la tecnología usada y su protocolo de comunicación.
Dentro de los dispositivos de almacenamiento secundario -como se dijo en la sección
1.1.1.2 las velocidades varían desde un lento disco suave (floppy), pasando pos dispositi-
vos ópticos, hasta un disco duro SCSI de 15000 rpm. En un sistema de telecomunicaciones
o de red tenemos velocidades que van desde 10Mbits hasta, actualmente 1Gigabit en ca-
bles de cobre categoría 7. Si dividimos entre ocho para saber cual es la capacidad de
transferencia en bytes o caracteres de una red, tenemos entonces que, para una velocidad
de 10Mbits, la tarjeta de red puede transferir 1,250,000 caracteres, esto es 1.25 millones
de caracteres por segundo. Aún así la velocidad de un procesador típico varía en el rango
de 1Ghertz hasta los 4 Gigahertz y subiendo. Esto es que, si hablamos de un procesa-
dor corriendo a la velocidad de 1Gigahertz y utiliza en promedio, por ejemplo dos ciclos
por instrucción, el procesador podría ejecutar cerca de 500 millones de instrucciones por
segundo, hablamos de un factor diferencia de 500 en velocidad. Para tenerlo siempre ocu-
pado necesitaríamos un sistema con cerca de 400 tarjetas de red, considerando que está
exclusivamente para atenderlas. Si el procesador esperara a que la tarjeta terminará de
enviar su caracter estaría 99.8 por ciento de su tiempo desocupado. Así, vemos la necesi-
dad de multiplexar la CPU entre los diferentes dispositivos de entrada/salida y aún, queda
mucho tiempo libre para ejecutar otros procesos del sistema o de usuario.
1.2.5. Administrador del sistema de archivos

Aunque los discos duros se consideran parte de la memoria secundaria, se manejan también
como dispositivos de entrada/salida. Dada la importancia que tienen para los sistemas operativos
actuales y la frecuencia de acceso que se tiene a los mismos, es necesario profundizar a detalle
cómo es que funcionan y la forma de organizarlos.
Un sistema operativo es una interfaz para el usuario y debe de ocultar en la medida de lo
posible todos los detalles concernientes al uso de los dispositivos incluyendo la memoria se-
cundaria. Sin embargo debe de proporcionar diferentes interfaces para cada tipo de usuario que
tenga la necesidad de manipular un archivo en diferentes niveles. Por ejemplo, un usuario final
lo que desea es, escribir un documento, guardarlo, hacer cambios e imprimirlo. No le interesa
saber en qué pista/sector o entrada de directorio quedó guardado. Para un usuario programador,
lo que necesita es tener un control más fino sobre el manejo del archivo y puede interesarse más
por la eficiencia y seguridad del almacenamiento. Para un administrador sus necesidades po-
drían incluir el poder controlar quien puede acceder al archivo o directorio o quien no. Algunos
sistemas operativos implementan una capa de abstracción para poder usar cualquier dispositivo,
como si fuera un archivo. A este tipo de administración de dispositivos se le denomina Entra-
da/salida independiente del dispositivo. Esto significa que podemos usar las órdenes comunes
de un shell o línea de comandos para crear, manipular o mandar a imprimir un archivo. Otro
aspecto importante del sistema operativo es administrar la memoria virtual, que como se dijo
en la sección 1.2.3.4, es una manera de aumentar la memoria física de la computadora usando
espacio en almacenamiento secundario.
En general un sistema administrador de archivos debe de implementar las siguientes funcio-
nes:
Manejo de memoria Virtual. Traducir las direcciones lógicas a direcciones físicas de archivo
Mantener las entradas de directorio. Contiene información que usa continuamente el usua-
rio, los datos de quien puede accederlo y además es el vínculo para poder acceder al
contenido del archivo.
Mantener información de archivos. Debe de llevar el control de asignación y desasignación

de espacio a cada disco, junto con la manera de recuperarlo.
En los sistemas operativos actuales, la manera más común de administrar el sistemas de

archivos es dividiéndolo en partes que sean del mismo tamaño de las páginas que se manejan
en memoria. Para comprender esto, vamos a discutir en forma general la estructura física de un
disco.
Al adquirir un disco e instalarse en una computadora debe primeramente ser acondicionado
para que pueda ser reconocido por el sistema operativo. Existe una utilidad en los sistemas
operativos para dividir el disco en rebanadas llamadas particiones. Una partición es una parte
independiente de las otras y puede contener incluso otro sistema operativo. Las características
de una partición son:
Tamaño de la partición. Describe cuanto espacio del disco en megabytes va a contener la par-
tición.
Tipo de sistema de archivos. Indica la manera en la cual van a estar organizados los archivos
en la partición. Es una etiqueta que ayuda a otros sistemas operativos reconocer particiones
que no son nativas.
Tipo de partición. Si la partición es arrancable o no. Esto quiere decir que si tiene un sector de
arranque o no.
Uso de la partición. Algunos sistemas operativos necesitan una estructura especial de direc-
torios que deben crearse, ya sea en una misma partición o en forma separada para poder
funcionar. Por ejemplo, los sistemas basados en Unix, necesitan una partición de intercam-
bio exclusiva y que no puede ser usada para guardar información. Esto evita problemas
en el intercambio de memoria a disco. Los basados en windows, toman el espacio libre
que queda en el disco. Si el usuario llena más el disco, el área de intercambio se reduce,
pudiendo en ocasiones impedir su funcionamiento cuando no hay suficiente espacio para
el intercambio entre memoria y disco.
El siguiente paso es el formateo del disco. Cuando formateamos un disco se crea una estruc-
tura especial que permite separar cada partición en pistas, clusters o cilindros y sectores.
Una pista es una línea circular que va incrementando su radio y separada una de otra por una
pequeña distancia.
Una pista es un segmento pequeño de disco definido en un pista y separado por dos líneas
radiales, esto es que salen del centro del disco y llegan hasta el borde. A medida que nos acerca-
mos al borde del disco los sectores se hacen cada vez más grandes, pero esto no quiere decir que
guardan más información. Por lo general un sector se define entre los 512 bytes y los 8 Kiloby-
tes, dependiendo de la capacidad del disco duro. A discos de mayor capacidad mayor tamaño
de sector. También podemos definir un sector como la cantidad de información que es capaz de
leer una sola cabeza lectora escritora del disco. En la figura 1.4
Figura 1.4: Conformación de pistas y sectores en un plato de disco
Un cluster o bloque está definido solamente en discos que estén usando al menos dos caras
de un mismo plato del disco duro. Un disco duro puede tener múltiples platos para guardar más
información. Así, un cluster se define como la cantidad mínima que puede leer simultáneamen-
te el conjunto de cabezas lectoras escritoras del disco que comúnmente están diseñadas como
peines que se desplazan paralelamente a una distancia muy pequeña de la superficie del plato.
Entonces, físicamente un cluster está compuesto por todos los sectores que se encuentran ali-
neados por las cabezas lectoras escritoras y que pueden ser leídos o escritos simultáneamente
en una sola operación de disco. Así el tamaño de un cluster queda definido en términos de los
sectores que pueden ser accedidos al mismo. Si tenemos entonces un disco duro de un plato, el
cluster está definido por los dos sectores que se encuentran alineados en ambas caras del plato.
Si su capacidad es de 512 bytes el cluster tendrá entonces 1024 bytes o 1 Kbyte de tamaño.
Algunos autores definen un cilindro como el conjunto de sectores que se encuentran en dos
o más pistas del mismo diámetro alineadas en dos o más caras del plato y que pueden leerse
durante una rotación completa del disco, debido a que cuando giran los platos, podemos ver
cómo se forma un cilindro a través de los platos.
No obstante la unidad de acceso mínima en cualquier disco duro será la de cluster o bloque
que comúnmente son múltiplos de 512 bytes. Si se necesita solamente un sector, los demás
quedarán guardados en el búfer en espera de ser utilizados

Ya que el disco se encuentra divido en las particiones, pistas, bloques y sectores adecuados,
el siguiente paso es crear sobre cada partición el sistema de archivos. Cada sistema operativo
utiliza su propia estructura para el control de la información y para asignación de nuevo espacio
para los archivos.
Una estructura general que usa un sistema de archivos es la siguiente:
Entradas de directorios. Una entrada de directorio contiene la información de un archivo. En

primer lugar contiene el nombre, el tamaño en bytes, la fecha de creación, el propietario
del archivo los permisos y el primer cilindro o sector asignado al archivo.
Tablas de asignación de archivos. En esta estructura se guarda la información que permite ir

recuperando la dirección de los demás bloques o sectores en donde se encuentra el resto
de la información del archivo. Esta estructura varía enormemente de un sistema operativo
a otro. Siendo algunas más eficientes que otras.
Área de datos. El área de datos es en donde realmente se guarda la información correspondien-

te a los archivos.
En el capítulo 5 haremos una descripción detallada y completa sobre cómo estructurar un

sistema de administración de archivos. Con lo visto es esta sección es suficiente para tener una
comprensión adecuada del tema.
1.3. Evolución histórica
1.3.1. Historia de los sistemas operativos

En esta sección discutiremos de una manera general cómo han evolucionado los sistemas
operativos desde un punto de vista funcional y de acuerdo a como han enfrentado la organización
de los trabajos a ejecutar. En general los sistemas operativos han pasado por varias etapas más o
menos diferenciadas.
En la década de 1940, cuando empezaban las grandes computadoras de válvulas de vacío el
sistema operativo no existía, en esta situación el operador de la computadora era el encargado
de gestionar todos los recursos de la computadora. Sus tareas iban desde cargar manualmente
el programa en la memoria de la computadora, ejecutarlo e interpretar los resultados obtenidos
por la misma. A estos sistemas se les llamó sistemas dedicados debido a que la computadora era
usada solamente por un programa en un tiempo dado. Esta fue la generación cero.
32 1.3. EVOLUCIÓN HISTÓRICA
Cuando se observó el enorme desperdicio de tiempo de CPU, se fueron implementando

nuevas mejoras, a menudo influenciadas también por los nuevos avances tecnológicos.
A principios de 1950, la nueva generación de sistemas operativos permitió agrupar tareas
comunes como compilar secuencialmente varios programas que requerían el mismo compilador,
ensamblarlos, ligarlos y luego guardar el código binario para su posterior ejecución. Todo ello
vino acompañado de nuevas tecnologías como las lectoras de tarjetas perforadas que permitían
al operador colocar en la secuencia deseada los compiladores, el código fuente, los datos y otras
instrucciones de control para que fueran alimentados a la computadora. Después el operador fue
substituido en parte para la organización automática de los trabajos por lotes. Este programa era
llamado monitor residente, el cual se encargaba de leer los trabajos, organizarlos de la manera
más eficiente y enviarlos a la computadora. Esta fue la generación uno.
Con el advenimiento de las cintas magnéticas, se observó que podía disminuirse el tiempo
ocioso de la CPU sacando las lectoras de tarjetas que resultaron ser muy lentas para las velocida-
des de la CPU, entonces las cintas empezaron a usarse como un intermediario entre las lectoras
de tarjetas y la CPU. De este modo, se creó el concepto de dispositivos de entrada/salida fuera
de línea. Así, el operador podía poner a leer a dos o más lectoras de tarjetas colocando la in-
formación en una cinta magnética, disminuyendo por el mismo factor la lentitud de las lectoras.
Cuando la cinta estaba llena, se colocaba en la unidad lectora de cintas, que alimentaba a la
CPU.
La introducción del transistor a mediados de 1950 permitió desarrollar computadoras más
confiables y rápidas. Ya se utilizaban también compiladores que facilitaban enormemente la
escritura de programas.
A la mitad de la década de 1960, empezaron a desarrollarse los sistemas de tiempo compar-
tido con multiprogramación y establecerse los principios de multiprocesamiento. En este tipo
de sistemas se encuentran en memoria varios programas de usuario en la memoria principal y el
procesador cambia rápidamente de un programa a otro, dando la ilusión al usuario de que tiene
la CPU para el solo. Los usuarios pueden acoplarse directamente a la computadora mediante
terminales.
Surgen también los sistemas de multiprocesamiento, en donde se integran dos o más CPU’s
para intentar reducir el tiempo de procesamiento asignando dos o más tareas a diferentes proce-
sadores o intentar dividir un proceso en varios para asignarlos a diferentes CPU’s.
Al final de esta generación empiezan a aplicarse los conceptos de independencia de disposi-
tivos.
surgen también por esta época los sistemas de tiempo real usándolos principalmente para el
control de procesos industriales. Un sistema de tiempo real se caracteriza por proporcionar una
respuesta inmediata a sucesos que tienen que ver con los requerimientos de producción. Estamos
en la segunda generación.
La tercera generación comienza en 1964 con la introducción de la familia de computadoras

sistema/360 de IBM. Fue el primer diseño de sistema operativo de propósito general. Fue preci-
samente esta generalización lo que ocasionó que fueran sistemas voluminosos y lentos. Algunos
de ellos soportaban procesos por lotes, tiempo compartido, procesamiento de tiempo real e in-
cluso multiprocesamiento. Esto ocasionó que fueran costosos, tanto en su desarrollo como para
el usuario final.
La cuarta generación comienza a mediados de 1970. es impulsada por avances tecnológicos

en el diseño de nuevos chips con tecnología LSI (Large Scale Integration) y VLSI (Very Large
Scale Integration). Integración a gran escala e integración a muy grande escala.
En esta generación empieza el auge de las redes de computadoras y del procesamiento en

línea. Los usuarios pueden conectarse desde lugares geográficamente apartados usando una línea
telefónica o usando diversos tipos de terminales. Intel introduce su primer microprocesador el
4004 para incluirlo dentro de una calculadora.
A principios de los ochentas intel, junto con IBM introducen la primera computadora per-
sonal con el microprocesador 8088. En 1984 Apple Computer lanza su primera computadora
personal. Introdujo por vez primera en la computación personal una interfaz gráfica con un ra-
tón el cual fue inspirado por las investigaciones realizadas en Xerox PARC.
Los sistemas operativos usados en estas pequeñas computadoras empezaron recorriendo nue-
vamente el camino de los usados en las grandes computadoras, aunque, desde un punto de vista
temporal, el desarrollo de los sistemas operativos para las computadoras personales ha llevado
casi el mismo tiempo que el de las grandes computadoras.
En la década de los 90’s el sistema operativo dominante en el mercado personal es el mercado

es la línea producida por microsoft, que merece una explicación aparte.
en 1992 Linux Torvalds -un estudiante de la Universidad de Helsinky- empezó desarrollan-

do el núcleo de un sistema operativo usando conceptos de Minix. Dio a conocer su trabajo a
la comunidad de internet, siendo patrocinado por la FSF (Free Software Foundation y comenzó
uno de los esfuerzos comunitarios más grandes para la programación y puesta a punto del mis-
mo. Siendo ahora un competidor muy importante para microsoft. Se hará una descripción más
detallada de su desarrollo en la sección 1.6.2.
A continuación haremos una descripción más detallada de las diferentes tecnologías que han
revolucionado los sistemas operativos.
1.3.2. Evolución de los Sistemas Operativos

1.3.2.1. Sistemas dedicados
La historia y evolución de los sistemas operativos se encuentra íntimamente ligada con la

evolución de las computadoras. Desde este punto de vista, cuando se había diseñado una compu-
tadora era necesario idear la forma de sacar el mayor provecho posible de ella, ya que eran
demasiado caras.
Las primeras máquinas estaban diseñadas con tubos de vacío lo que hacía que ocuparan un
gran espacio, era común que ocuparan una sala completa. No había sistema operativo. El pro-
gramador diseñaba un programa y luego capturaba las instrucciones directamente en la consola
del operador. El programador podía ir observando como se ejecutaba el programa mediante unos
indicadores luminosos de la consola.
A medida que pasó el tiempo se fueron creando nuevas herramientas de software y hardware,
las cuales ayudaban en el proceso de diseño y ejecución de programas. Un aspecto importante
fu la creación de grandes librerías de código, primero de código fuente denominadas macros y
después de código objeto. Este código facilitaba mucho el diseño de nuevos programas. Ya na
había que reescribir la mayoría de las rutinas de entrada salida que eran comunes a la mayoría
de los programas, así, se establecieron los primeros conceptos de reusabilidad del software. La
rama que se encarga del estudio y desarrollo de nuevas metodologías de diseño y reusabilidad
es la ingeniería de software o análisis de sistemas.
Cuando se diseñaron los primeros compiladores como FORTRAN (FORmula TRANslation
Traducción de Fórmulas) y COBOL (COmmon Bussines Oriented Language, Lenguaje Común
Orientado a los Negocios), el primero orientado a aplicaiones científicas y el segundo a las em-
presas, facilitó el diseño de los programas, pero complicó aún más la preparación del mismo,
puesto que aún no se integraban todas las herramientas del software de sistemas sino que de-
bían de ejecutarse por separado. Por ejemplo, para ejecutar un programa en FORTRAN, primero
debía escribirse el programa, despúes cargarse el compilador, luego el código, fuente. El com-
pilador regresaba código en ensamblador, lo que implicaba ahora cargar el ensamblador para
generar el código objeto. Este código objeto, necesitaba varias librerías para que el ligador pu-
diera generar el ejecutable. Por último la salida era pasada al cargador para poner el programa
en memoria y empezar su ejecución y depuración. Si había un error debía de repetirse todo el
proceso nuevamente.
Como cada programa se encontraba en diferentes cintas, el operador tenía que hacer varios
intercambios para poder realizar todas esas tareas lo que implicaba una pérdida tremenda en
tiempo de CPU. Toda esta pérdida se reflejaba en menos utilidades para los inversionistas que
habían aportado el dinero para el desarrollo de la computadora. Hay que recalcar que el uso de
las computadoras estaba reservado sólo a grandes instituciones o empresas que podían pagar ese
tiempo de CPU valiosísimo.
1.3.2.2. Sistemas por lotes
La otra mejora substancial fue dejar las tareas de programación y depuración al programador
y la carga de cintas al operador de sistemas. De esta manera, si había un error el operador enviaba
al programador un volcado de memoria para que corrigiera el error, e inmediatamente ponía otro
trabajo en la computadora para tenerla ocupada el mayor tiempo posible. Los trabajos que tenían
necesidades parecidas eran agrupados en un mismo lote con el fin de que pudieran ejecutarse en
la secuencia adecuada pero sin la intervención del operador. Por ejemplo, ya sabemos que para
poder ejecutar un programa escrito en Fortran, éste debe compilarse, ensamblarse ligarlo con
las librerías y ejecutar el binario generado. Todas estas operaciones se unían en un solo lote, de
esta manera se evitaba la lenta intervención del operador humano en cada paso. Aún así, había
problemas. Cuando un programa se detenía el operador debía verificar qué había sucedido y
decidir si era posible continuar o empezar otro trabajo. Esto requería mucho tiempo.
El siguiente paso fue implementar un sistema monitor, el cual leía de un archivo todas las
tareas a ser ejecutadas, por lo común de una lectora de tarjetas, cuando se terminaba la tarea en
turno, ésta pasaba el control al sistema de monitor, éste tomaba del archivo la siguiente tarea y la
pasaba el control. Así se redujo aún más la dependencia de un operador humano. La innovación
fue mantener en memoria el sistema monitor a lo que se le llamó sistema residente. De esta
manera surgió el primer sistema operativo rudimentario.
En un sistema basado en lotes, el control de un trabajo se realiza mediante tarjetas que con-
tienen la secuencia de órdenes que debe interpretar el sistema monitor residente y luego hacer
que se ejecuten. Cada tarjeta incluye órdenes del tipo $CargarCompilador, $CargarProgramaa-
Comppilar, $CargarProramaCompilado, $CorrerPrograma, $CargarDatosdePrograma, $Fin. Ca-
da instrucción hace uso de una tarjeta.
Con la llegada de las tarjetas perforadas, se ganó un tiempo significativo con respecto al ope-
rador, pero aún así estos dispositivos, comparados con la velocidad de la CPU eran demasiado
lentos. Lo que significaba que la CPU todavía tenía muchos tiempos muertos. No obstante ya
había una mejora substancial.
1.3.2.3. E/S compartida
A medida que mejoraba la tecnología, llegaron con el tiempo las cintas magnéticas. Estas
tenía una velocidad de acceso mucho mucho mayor que las tarjetas perforadas y las impresoras
de línea. Entonces primeros se pasaban los paquetes de tarjetas a una cinta magnética y de ahí la
CPU leía la información. Todos los lectores de tarjetas y las impresoras operaban fuera de línea,
en lugar de ser controlados por la computadora principal. En la figura 1.5 podemos ver cómo se
lograba transferir datos de un dispositivo lento a uno más rápido.
Figura 1.5: a) Un sistema con E/S en línea b) E/S fuera de línea
La principal desventaja de este esquema es que incrementa el tiempo para preparar un tra-
bajo, ya que este no pasa directamente a la CPU, si no que primero debe de pasar a cinta y la
cinta debe de llenarse primero con otros trabajos de modo que se encuentre preparada para ser
leída por la CPU. El incremento de eficiencia se da por que ahora se pueden usar varias lecto-
ras de tarjetas para llenar una sola cinta, esto es, si se ponen a leer dos dispositivos de tarjetas
simultáneamente, entonces el tiempo de lectura se reduce a la mitad.
Aunque el uso de cintas mejoró mucho el tiempo de procesamiento, las cintas tienen el pro-
blema de ser dispositivos secuenciales, lo que quiere decir que el sistema no podía leer o escribir
al mismo tiempo en ambos extremos de la cinta. El acceso se debe de llevar a cabo mediante un
rebobinado, el cual es un movimiento mecánico y por lo tanto muy lento. Con el advenimien-
to de los discos o dispositivos de acceso aleatorio, se resolvió parte del problema. El proceso
consiste en leer de los dispositivos de tarjeta a disco y mantener ahí la información, lo mismo
hacemos en la salida, después de que la CPU ha terminado el trabajo, éste lo almacena en el sis-
tema de disco hasta que el dispositivo externo esté listo para imprimirlo verdaderamente a este
proceso se le denomina operación simultánea de periféricos en línea también conocida como
spool (simultaneous peripheral operation on line) Esta nueva tecnología permitió mantener
ocupada a la CPU y a los periféricos un tiempo mayor, ya que mientras se estaba imprimiendo
alguna información la CPU podía estar realizando cálculos o incluso haciendo otra operación
de entrada salida en algún dispositivo. Aquí lo único que necesita la CPU es ser informada de
que el periférico a terminado de procesar los datos y está lista para que se le envíe otro lote o
que el bloque de datos se encuentra listo para ser leído por la CPU. Todo esto combinado con
el control de los dispositivos orientados a interrupción (vea la sección 1.1.1.3 en la página 16)
dieron como consecuencia natural los entornos multitarea y multiprogramación que usan todos
los sistemas operativos existentes en la actualidad.
1.3.2.4. Entornos de tiempo compartido
En un entorno de tiempo compartido, multitarea o multiprogramación, el tiempo de CPU

se distribuye entre diferentes usuarios que están conectados a la computadora principal simul-
táneamente. En este nuevo enfoque se permite que diferentes programas se ejecuten “al mismo
tiempo”, de esta manera, cuando un programa está ocupado en procesar datos sobre un disposi-
tivo de entrada/salida, el CPU estará ejecutando otro programa. Esto hace que esos programas
compitan por los recursos del sistema. El enfoque más común es asignar rebanadas de tiempo
de CPU a cada proceso (programa) de modo que cuando se le termine el tiempo o esté ocupado
esperando datos de algún dispositivo, se ejecute otro programa, mejorando así el rendimiento
del sistema.
Figura 1.6: Un sistema multiusuario típico
Los sistemas interactivos proporcionan un ambiente más adecuado para el desarrollo depu-
ración y ejecución de programas, al contrario de un sistema por lotes en donde el programador
tenía que esperar el volcado de memoria para poder hacer la depuración del programa. En un sis-
tema de multiprogramación puede editar, compilar, depurar y ejecutar el programa sin pérdidas
38 1.4. CLASIFICACIÓN
de tiempo significativas.
El ejemplo más común de un sistema multiusuario lo podemos encontrar en un campus uni-
versitario o una empresa en donde es necesario conectarse a un servidor para tener acceso a los
recursos de cómputo. En la figura 1.6 vemos una distribución clásica de terminales conectadas
a un servidor.
1.4. Clasificación
1.4.1. Sistemas por lotes sencillos
Las primeras computadoras eran muy grandes y se controlaban desde la consola. La entrada
más común era a través de tarjetas perforadas y unidades de cinta. La salida consistía se enviaba
básicamente a impresoras de línea, unidades de cinta y a tarjetasperforadas. Los usuarios no
interactuaban directamente con ellas. El usuario preparaba un trabajo, incluyendo el programa,
los datos e información de control. Este trabajo se entregaba al operador de la computadora.
Después de algún tiempo, se entregaba la salida que podría contener el resultado del programa
junto con un vaciado de memoria y registros en caso de haber un error en el programa. La tarea
del sistema operativo consistía en mantener ocupada la computadora el mayor tiempo posible.
Figura 1.7: Estructura de la memoria de un sistema por lotes
Para agilizar el proceso los programas similares se agrupaban en lotes y se introducían a la

computadora como un grupo. El operador era la persona encargada de organizar los trabajos en
lotes y de devolver el trabajo al programador correspondiente. Un sistema operativo por lotes
lee un flujo de trabajos individuales, ejecutando uno a uno secuencialmente y proporcionando
la salida. Su característica principal es la ausencia de interacción del usuario con el trabajo
correspondiente. Con los sistemas por lotes la CPU como tal está ociosa la mayor parte del
tiempo debido a las operaciones de entrada salida que son muchas órdenes de magnitud más
lentas que la CPU. Situación que no ha cambiado a la fecha debido a que, aunque los dispositivos
de entrada salida han mejorado mucho en los últimos años, las velocidades de la CPU también
se han incrementado mucho más. La técnica más común es el uso de buffers, ya sea en disco o en
memoria principal de modo tal que la información de los dispositivos de entrada o de salida se
almacenen en esotso buffers para que sea procesada completamente por la CPU. A esta técnica
se se conoce como spooling. Así, la CPU solamente realiza trabajo cuando se le informa que sus
datos se encuentran listos.
Figura 1.8: Flujo de datos en el spooling
1.4.2. Sistemas por lotes multiprogramados

Con el esquema de trabajo por lotes no se aprovecha la cpu como debe de ser y en algún
momento, la CPU se encuentra ociosa o los dispositivos de entrada/salida están ociosos. Esto
es, uin solo usuario no puede mantener ocupada ni la CPU ni los dispositivos de Entrada/Salida.
el propósito de la multiprorgamación es mantener varios trabajos en la memoria a la vez, como
puede verse en la figura 1.9. Estos trabajos son un subconjunto de los existentes en disco y
que están en reserva. El sistema operativo escoge uno de los trabajos en memoria y empieza a
ejecutarlo, en un momento dado necesitará hacer alguna operación de entrada o salida. En un
sistema sin multiprogramación, la CPU estaría desocupada. En el sistema multiprogramado, el
sistema operativo escoge otro trabajo y lo ejecuta. Cuando el último trabajo necesita esperar, la
CPU conmuta a otro trabajo, en algún instante el primer trabajo terminará sus operaciones de
entrada salida y podrá nuevamente ser ejecutado por la CPU.
1.4.3. Sistemas de tiempo compartido

Los sistemas de tiempo compartido se desarrollaron al requerir el usuario una interacción
mayor con la computadora y la necesidad de aprovechar al máximo los ciclos de CPU ya que
las computadoras eran muy caras.
Figura 1.9: Estructura de la memoria en un sistema de multiprogramación
Cuando los dispositivos de entrada y salida mejoraron, esto es, se integró un teclado y un
monitor, fue entonces posible el que varios usuarios interactuaran directamente con la compu-
tadora, como se explicó en la sección 1.3.2.4, un sistema de tiempo compartido da al usuario la
sensación de tener una computadora propia
1.4.4. Sistemas operativos de red

Podemos definir que un SOR es un sistema que mantiene a dos o mas computadoras unidas,
por lo regular la comunicación es por algún medio, ya sea físico o no físico. Pueden compartir
diferentes recursos como algún medio físico como una impresora, y también pueden compartir
un medio no físico. Como ejemplos de SOR tenemos: Linux, UNIX, Windows server, LAN Ma-
nager, Novell Netware. Los componentes que conforman a un SOR son dos, clientes y Servidor;
los cliente son quipos configurados con sistemas operativos mono compuestos, y se conectan y
se validan al servidor para poder empezar a trabajar en la red. Por otra parte los servidores son
equipos configurados con operativos de red que proporcionan recursos a los clientes. El software
de red de cliente permite que estos recursos estén disponibles para os quipos clientes.
Algunas de las características más comunes que podemos encontrar en un SOR son: Al
compartir recursos describe los recursos que están disponibles para cualquier usuario de la red.
Permite distintos usuarios con diferentes niveles de acceso a os recursos, asegura que los re-
cursos utilizado por dos usuarios no sean utilizados al mismo tiempo lo que conocemos como
comunicación coherente. El administrador de red determina: a las personas o grupos de personas
que podrán acceder a los recursos, también crea, borra o modifica usuarios y grupos de usuarios,
otorga y/o quita permisos al usuario a los recursos controlados por el SOR.
1.4.4.1. El modelo cliente servidor
El Modelo cliente-servidor está basado en protocolo solicitud/respuesta las ventajas que este
tuene es que es sencillo y sin conexión y demás es muy eficiente. Los servicios que este pro-
porciona son los siguientes: ejecución de un programa; acceso a una base de datos y acceso
a un dispositivo de hardware Un servidor funciona en una computadora específica usando un
socket con un número de puerto específico. Un socket es concepto abstracto por el cual dos
programas (posiblemente situados en computadoras distintas) pueden intercambiarse cualquier
flujo de datos, generalmente de manera fiable y ordenada. El cliente conoce el nombre de la
maquina (hostname) o el IP, en la cual el servidor está funcionando y el número del puerto con
el servidor está conectado. Si el cliente lanza una demanda de conexión y el servidor acepta la
conexión, este abre un socket en un puerto diferente, para que pueda continuar escuchando en el
puerto original nuevas peticiones de conexión, mientras que atiende a las peticiones del cliente
conectado
El cliente: En la comunicación entre el cliente y el servidor se puede llevan a cabo lo si-
guiente:
1. Establece una conexión con el servidor
2. Crea un socket con el servidor
3. Manda mensajes al servidor o esperar un mensaje de él
4. puede cerrar la conexión con e servidos
El servidor
1. Ejecuta un requerimiento
2. Regresa los datos solicitados o un código de error si no pudo ejecutarlo correctamente
3. El servidor inicia un puerto de comunicación, en espera de clientes que intentan conectarse

a él
4. Una vez que se conecta con alguien crea un hilo de ejecución para este usuario
5. Se comunica con el cliente mediante el socket
6. Espera que el cliente se vaya o el mismo servidor cierre la sesión
Un socket proporciona una comunicación de dos vías o punto a punto, son versátiles es im-
portante porque es un componente básico de comunicación entre interprocesos e inter-sistemas
garantizando que todo octeto llegará a su destino en el mismo orden que se transmitió. Existen
varios tipos de sockets entre ellos podemos mencionar el Socket de flujo el Socket de datagrama
y el Socket de paquete secuencial
1.4.5. Sistemas de computadora personal
Cuando los precios de las computadoras fueron lo suficientemente accesibles, es posible que
cada usuario pueda tener us propia computadora. A este sistema se le conoce como computadora
personal (PC Personal Computer).
Las computadoras personales surgieron en la década de los 70’s, se trataban de microproce-
sadores muy pequeños y económicos comparados con los grandes sistemas tipo macro compu-
tadoras (main frame) las cuales sólo era posible adquirirlas por algunos gobiernos o grandes
universidades.
Estas microcomputadoras no poseían la capacidad para ejecutar sistemas operativos de tipo
multitarea de ese entonces y usaba sistemas operativos monotarea lo que implicaba también que
fuera monousuario. A diferencia de las grandes main frames de ese entonces, cuyo objetivo era
optimizar el aprovechamiento de la CPU, el objetivo de las microcomputadoras era maximizar
la facilidad de uso y enfocarse en las necesidades de los usuarios.
Los sistemas personales se clasifican básicamente en dos tipos: computadoras de escritorio y
computadoras de viaje o lap tops. Usan básicamente tres tipos de plataformas de hardware intel,
AMD siendo compatibles entre sí y la de las computadoras Macintosh que empezaron usando
microprocesadores de motorola MC68000 de tecnología CISC. En marzo de 1994, Apple intro-
dujo la gama PowerPC cambiando a una tecnología RISC y en el 2006 comenzó la transición a
los procesadores de Intel con arquitectura x86.
Los sistemas operativos más comunes a nivel de computadoras personales mencionándolos
en orden cronológico: MS-DOS, OS/2, Apple Macintosh y Microsoft Windows en diferentes
versiones.
Los sistemas operativos de computadoras personales se han beneficiado de los desarrollos
tecnológicos de los sistemas operativos para macrocomputadoras. Por ejemplo,la memoria vir-
tual y el desarrollo de esquemas de protección de archivos. En general, tanto la evolución del
hardware como de los sistemas operativos en las macrocomputadoras, se está repitiendo en las
computadoras personales.
A su vez los dispositivos de entrada salida mejoraron también existiendo ahora teclados,
ratones de diferentes tipos, apuntadores, pizarrones electrónicos, tabletas para entornos gráficos,
etc. En los dispositivos de salida también existe gran variedad, las impresoras han integrado,
la digitalización, funciones de copia, reduciendo su tamaño muchísimo. Las pantallas de LCD
o LED han substituido a la tecnología cd CRT (Tubo de rayos catódicos). Incluyendo algunas
capacidades de Toque o las pantallas Touch Screen) que permiten interactuar directamente en la
pantalla.
1.4.6. Sistemas operativos de computadoras de bolsillo

Son aquellos que se utilizan en dispositivos pequeños tales como teléfonos celulares, PDA’s
(Personal Digital Assistant), realizan tareas que pueden ir desde la administración de una agenda
hasta el acceso a internet, un block de notas, reproducción de videos, música o grabación de
sonido. Algunos pueden contar incluso con televisión analógica y radio integrados. La mayoría
incluye también una cámara digital y acceso a redes sociales. Tienen integrados un conjunto de
juegos, pero otros pueden soportar aplicaciones en java, lo que permite instalar aplicaciones de
terceros. Algunos de los sistemas operativos más populares son Android, symbian OS y Palm
OS.
1.4.7. Sistemas paralelos

La mayoría de las computadoras tenían un solo procesador, pero la tendencia actual es ha-
cia los sistemas multiprocesadores. Estos sistemas integran dos o más microprocesadores en la
misma tarjeta madre y están comunicados por el mismo bus, el reloj es el mismo y también
comparten la memoria principal a excepción de la memoria caché. También comparten los dipo-
sitivos periféricos. Este sistema se conoce como sistemas fuertemente acoplados. La principal
razón para construir estos sistemas es la de incrementar el rendimiento aunque este rendimiento
no es proporcional al número de procesadores existentes en el sistema, puesto que se incurre
en “gastos administrativos” para mantener a todo el sistema trabajando de manera organiza-
da. También, debido a que los recursos son compartidos, no es posible que varios procesado-
res hagan uso simultáneo de ellos, situación conocida como “acceso concurrente”. Un sistema
multiprocesador puede resultar más económico si es necesario procesar la misma información
por diferentes programas, ya que comparten periféricos, gabinetes, fuente de potencia, etc.. Un
sistema multiprocesador mejora la confiabilidad, ya que si es posible dustribuir las tareas ade-
cuadamente entre varios procesadores si uno falla, el sistema no tendrá problemas, perderá un
poco de eficiencia por que otro procesador tomará sus tareas, pero se sigue proporcionando el
servicio.
1.4.8. Sistemas distribuidos

Para entender que es un sistema distribuido comenzaremos dando algunas definiciones:
SISTEMA DISTRIBUIDO: Colección de computadoras independientes que aparecen ante
los usuarios del sistema como una única computadora.
SISTEMA DISTRIBUIDO: cualquier sistema en el que varios CPU conectados entre sí tra-
bajan de manera conjunto.
En base a estas definiciones podemos decir que un sistema distribuido es una colección de
computadoras que aun que son independientes, están conectadas entre sí y trabajan de manera
conjunta, y lo podemos observar en los bancos por que cuenta con cientos de sucursales dis-
tribuidas por todo el mundo y cada computadora tiene la capacidad de comunicarse con las de
otras sucursales.
Definimos como SOD a un sistema operativo que distribuye los servicios entre otros host
con el mismo sistema operativo y es visto como un solo sistema para todos y cada uno de los
elementos de la red Características:
1. Mismo Sistema Operativo: el SO es igual entre todos los servidores
2. La comunicación se realiza por medio de mensajes entre los dispositivos
3. Fácil entendimiento del sistema operativo
4. Transparente: el usuario no nota la diferencia de la forma de trabajo
5. Confiabilidad: hay seguridad en la conexión y en los datos
6. Desempeño: hay buena capacidad de respuesta y existe la tolerancia a fallos
7. Todos los servidores trabajan como un único sistema
8. Escalabilidad: mantenimiento y actualización
9. Manejo de protocolos: logra una comunicación exitosa entre los dispositivos de a red.
1.4.8.1. Ventajas de los SD con respecto a los centralizados:
1. Los sistemas distribuidos tienen en potencia una proporción precio/desempeño mucho

mejor que la de un sistema centralizado.
2. Los sistemas distribuidos tienen mayor confiabilidad al distribuir la carga de trabajo
3. La falla de un circuito descompondría solo una máquina y el resto seguiría intacta.
4. Crecimiento por incrementos.
5. Los sistemas distribuidos pueden compartir datos, periféricos caros como impresoras láser
y dispositivos de almacenamiento masivo y lograr una conexión de personas
1.4.8.2. Desventajas de los sistemas distribuidos
1. Falta de experiencia en el diseño implementación y uso del software distribuido.
2. Comunicación
3. Las redes de comunicación pueden perder mensajes por lo que se requiere un software
para su manejo
4. Seguridad
5. Almacenamiento
Existen dos tipos de sistemas operativos distribuidos: Los débilmente acoplados: permite que
las máquinas y lo usuarios de un sistema distribuido sean independientes entre sí en lo funda-
mental, pero que interactúen en cierto grado cuando sea necesario, también se le conoce como
débilmente acoplado puesto que las maquinas individuales se distinguen con claridad. A este
tipo de sistemas se le conoce también como multicomputadora. Se define también a un sistema
débilmente acoplado por la velocidad en que viajan los datos. En un sistema multicomputadora,
los datos viajan a través de la red y por tanto, es más lenta su transmisión. Los fuertemente
acoplados: el programa de aplicación y le sistema operativo están mejor acoplados que los dé-
bilmente acoplados y no se distinguen con tanta claridad. Los datos viajan muy rápido, por estar
conectados a través de un bus común. A estos sistemas se les conoce también como sistema
multiprocesador.
1.4.9. Sistemas operativos multiprocesadores

Con el avance de los circuitos integrados ahora es muy común que las computadoras persona-
les y de escritorio cuenten con varios CPu’s físicos. Podemos encontrar en el mercado compu-
tadoras con dos, tres, cuantro, cinco o más microprocesadores dentro del mismo chip. En el
ámbito de servidores, podemos encontrarlos con cientos o incluso miles de procesadores. Este
tipo de hardware necesita un sistema operativo especial que permita administrar los procesos y
distribuirlos en todos los procesadores disponibles en el sistema. A estos sistemas operativos se
les llama sistemas operativos multiprocesadores
1.4.10. Sistemas de tiempo real

Es aquel que debe de responder dentro de límites de tiempo bien establecidos. Si responde
fuera de estos tiempos entonces no cumpliría adecuadamente con sus tareas. Si hablamos de un
46 1.5. ESTRUCTURA: NIVELES O ESTRATOS DE DISEÑO
sistema de fabricación en línea, por ejemplo de automóviles, cada tarea debe de realizarse dentro
un lapso de tiempo determinado. Si el robot que se encarga de soldar ciertas piezas necesita
hacerlo en un momento o en un lapso de tiempo determinado hablamos entonces de un sistema
en tiempo real duro. Estos sistemas deben prtoveer garantías de que las operaciones ocurrirán
en un instante o en un intervalo de tiempo dados. El otro tipo de sistemas en tiempo real son
los sistemas en tiempo real suave, en el cual es aceptable que ocasipnalmente se pueda fallar a
un tiempo determinado. Los sistemas de video o de audio digital entran en esta categoría. Los
teléfonos digitales son también ejemplos de sistemas en tiempo real suave.
1.5. Estructura: niveles o estratos de diseño

El diseño y desarrollo de un sistema operativo es tan complejo que comúnmente éste debe
ser estructurado de tal forma que varias personas puedan dedicarse a distintos módulos o en su
defecto tareas distintas dentro de un mismo módulo.
Bajo este enfoque, las interfaces entre las tareas y entre los módulos deben quedar lo su-
ficientemente definidas como para que los programadores puedan enfocarse en el desarrollo
del módulo. Siguiendo primeramente un diseño estructurado y después un diseño orientado a
objetos, al análisis, diseño y modificación de un módulo puede ser hecho mucho más fácil.
El diseño de un sistema operativo puede abordarse empleando distintos enfoques. Dentro de
éstos los más comunes son diseñar una estructura única del sistema operativo o diseñarlo a partir
de una estructura por niveles.
1.5.1. Estructura única

Por lo común se debe a un diseño mal planificado, hablamos de un sistema monolítico que
está enfocado más a producir resultados rápidos orientados a resolver una tarea en particular.
Empiezan siendo sistemas pequeños para luego, a medida que se le van añadiendo funcionalida-
des crece a tal grado que después es muy difícil adaptarlo a nuevas situaciones. Como ejemplo
tenemos el sistema operativo de microsoft, MS-DOS(MicroSoft Disk Operating System) Siste-
ma Operativo de disco. Cuando salió su primera versión, los procesadores de Intel (Básicamente
el 8088 y el 8086 Basados en una arquitectura de 8 y de 16 bits con un direccionamiento ex-
terno de hasta 20 bits) no soportaban multitarea ni memoria extendida. Tampoco podían manejar
un modo protegido. Por lo que no era necesario incluir en el diseño del sistema características
de protección de memoria o de acceso al hardware. Esta falta de soporte del modo protegido
permite que cualquier programa pueda acceder libremente a toda la memoria del sistema o al
hardware del mismo e incluso a la del sistema operativo, dejándolo en una situación precaria
en cuanto a la integridad de su propio código. Lo único que podía hacer era verificar que un
programa no hubiera escrito en su área de memoria. Si así era, forzosamente se obligaba a una
nueva lectura de todo el código del sistema operativo del disco a la memoria, para poder seguir
trabajando adecuadamente. Si no era posible hacer la verificación. la computadora se quedaba
congela siendo necesario reiniciarla para empezar otra vez.
El tamaño máximo de los programas o de los segmentos no podía exceder de los 64Kbytes.
Cuando apareció el microprocesador 80286 y el 80386 de Intel. El sistema operativo no era
capaz de soportar la multitarea, debido a que sus versiones anteriores no fueron diseñadas para
manejar el modo protegidoindexmodo protegido, desaprovechando así por mucho tiempo, las
nuevas características de estos procesadores que ya soportaban el modo protegido y cálculos de
32 bits. Cuando aparecieron computadoras con un límite de memoria más allá de los 640Kbytes
de RAM, el MS-DOS implementó un manejador para permitirle al sistema operativo colocar
programas o datos en la Memoria Alta o Extendida, pero sin tener aún acceso transparente a la
misma. Esto debido a la limitación de direccionamiento con la que fue expresamente diseñado.
Figura 1.10: Estructura del MS-DOS de Microsoft
En al figura 1.10 observamos cómo están organizados los niveles del sistema operativo MS-
DOS. Puede verse inmediatamente que un programa de usuario tiene acceso al hardware, ya
sea vía sistema operativo o como la mayoría de los juegos que se desarrollaron en MS-DOS
accediendo directamente a la BIOS de la computadora o al hardware para lograr su máxima
velocidad. Obviamente, MS-DOS fue expresamente diseñado para ambientes de computación
familiar y de diversión. La principal ventaja que tuvo MS-DOS fue lo asequible del equipo de
cómputo y del propio sistema operativo en cuanto a precio y permitió que muchísimos progra-
madores desarrollaran nuevo software con poca inversión para este tipo de ambiente. De ahí,
poco a poco empezó la penetración en ambientes empresariales.
Los sistemas operativos basados en Unixrecorrieron más o menos el mismo camino, pero la
principal ventaja que tuvo fue la de separar el núcleo del sistema operativo de los servicios que
podía proporcionar, haciendo mucho más fácil añadir nuevas características para aprovechar
los nuevos avances del hardware más rápidamente. Por otro lado, a diferencia de MS-DOS,
Unix siempre fue desarrollado pensando en ambientes empresariales, instituciones de gobierno
o educativas.
1.5.2. Estructura por niveles

Como observamos en la sección 1.5.1. Si el hardware no cuenta con los mecanismos de
soporte para la ejecución de instrucciones en modo protegido o modo kernel, es muy difícil dar
soporte solamente vía software, tanto que por lo común no se implementa. Cuando el hardware
proporciona ese soporte es relativamente simple proporcionar un entorno de ejecución único
para el sistema operativo y otro para el usuario, de modo que si el usuario intenta acceder a
un área de memoria o dispositivo que no le corresponde el hardware genera una interrupción
cediéndole el control al sistema operativo de modo que pueda terminar con el programa que
causó el acceso. Estas nuevas funcionalidades permiten que los diseñadores se concentren en
el desarrollo de sistemas operativos modulares usando técnicas de diseño estructurado tal como
top down (Diseño de arriba hacia abajo) y Bottom-Up (Diseño de abajo hacia arriba).
En un diseño top-down se comienza escribiendo el módulo de nivel más alto y de ahí, cada
uno de ellos empieza a dividirse en tareas cada vez más simples, hasta que sea posible codificar
cada una de las subtareas en un lenguaje de alto o medio nivel.
En el diseño Bottom-up empezamos haciendo pequeñas subtareas que hagan perfectamente
bien su trabajo, de ahí pasamos a integrarlas en un módulo que agrupe a todas las subtareas que
estén muy relacionadas de modo que podamos hacer una tarea mucho más grande.
En este tipo de diseños es común que haya ciclos en los que se van intercalando ambos tipos
de diseño, esto es, se empieza con un top-down, enseguida se hace un bottom-up para ver si es
posible agrupar las nuevas subtareas por afinidad, repitiendo el ciclo hasta tener una clara idea
del sistema y pasar a la etapa de implementación.
Varios de los sistemas operativos que aparecieron en los 90’s tienen un nuevo enfoque de
desarrollo: el enfoque orientado a objetos.
En un análisis orientado a objetos. Todo lo que existe en el mundo son objetos, los cuales
pueden modelarse mediante un conjunto de características o atributos y un conjunto de activi-
dades o métodos que pueden realizar sobre esos atributos. Un atributo puede ser a su vez otro
objeto con estructura similar de modo que pueda ser analizado bajo el mismo enfoque. Cuando
los objetos están definidos, estos pueden interactuar entre ellos para poder solucionar un proble-
ma. En nuestro caso, el sistema operativo viene a ser un objeto, el cual está constituido por otros
objetos para que pueda llevar a cabo sus tareas. La función del objeto sistema operativo es la
de coordinar los otros objetos, tales como los que analizamos en la sección 1.2, por ejemplo, el
objeto administrador del CPU, el objeto administrador de procesos, el objeto administrador de
memoria, y el objeto administrador de dispositivos de entrada salida. Siguiendo con el análisis,
cada uno de ellos va a estar formado por otros objetos o va a interactuar con ellos. Así el admi-
nistrador de procesos, puede considerar como objeto a un proceso con sus atributos tales como
el objeto código o el objeto memoria para su ejecución.
El sistema operativo de windows NT (Windows New Technology) -Nueva Tecnología de
Windows- fue diseñado bajo este nuevo enfoque, empezando con un enfoque de micronúcleo y
terminando en uno de niveles. En la sección 1.6, explicaremos esta implementación de sistema
operativo.
También los nuevos sistemas operativos basados en Unix, como Solaris y GNU/Linux in-
cluyen tecnología orientada a objetos en sus núcleos, añadiendo también módulos dinámicos, lo
que permite que haya mayor eficiencia y seguridad.
Figura 1.11: Arquitectura lógica del núcleo de GNU/Linux
En la figura 1.11 vemos una distribución lógica del sistema operativo GNU/Linux.
Estas distribución se aplica a todos los componentes del sistema operativo. Esto es, se aplica
al administrador de procesos, al administrador de memoria, al administrador de los dispositi-
vos de entrada salida, al sistema de archivos y agrega nuevas capas: la capa de red y la capa
de interfaz humana integrando es este nivel la capa de seguridad. El administrador de CPU o

planificador está integrado en la capa de procesamiento.
Figura 1.12: Arquitectura parte 2: La capa del Sistema y de red
En la figura 1.12 vemos las tareas que se deben de implementar en el sistema y en la red.
En la figura 1.13 observamos las tareas que se deben implementar en los subsistemas de me-
moria, procesamiento y almacenamiento. La última capa es la la interfaz humana, que podría
corresponderse en parte con el administrador de dispositivos.
En la figura 1.14 tenemos la última capa definida para el kernel de linux. incluye el manejo
de los dispositivos de entrada salida que interactúan directamente con el usuario final. En este
nivel está incluida la capa de seguridad.
En una estructura de niveles, cada nivel se implementa sólo utilizando operaciones defi-
nidas en los niveles anteriores aumentando su grado de abstracción y haciéndose más fáciles
de programar y entender a medida que nos acercamos al usuario y disminuyendo su grado de
abstracción al acercarse al hardware. Cada capa oculta todos los detalles de las capas inferiores.
La desventaja es que debe de hacer un análisis muy detallado de los requerimientos de los
usuarios de modo que todos ellos puedan ser cubiertos por las operaciones definidas en la última
capa. De otra forma, es necesario modificar cada uno de los niveles para proporcionar la nueva
funcionalidad. Otro problema es que el sistema operativo obtenido con este enfoque tiende a ser
menos eficiente en función de los niveles que hayan sido implementados, a mayor número de
niveles menos eficiente será, debido a que las órdenes y la información tendrá que viajar por un
número mayor de capas. En la figura 1.15 podemos observar cómo un nivel envuelve al anterior,
y por conceptos de seguridad se impide el acceso directo a los niveles más internos del sistema.
Figura 1.13: Arquitectura parte 3: almacenamiento, memoria y procesamiento
1.6. Núcleo
Cuando empezaron a desarrollarse los primeros sistemas operativos, resultaron ser demasia-
do grandes y difíciles de mantener. A mediados de los años 80’s en la Universidad de Carnegie
Mellon, los investigadores desarrollaron un sistema operativo al que llamaron Mach. Mach está
basado en una tecnología denominada micronúcleo o microkernel. Esta manera de estructurar
al sistema operativo elimina todos los componentes no esenciales del kernel y éstos se diseñan
como programas del sistema a nivel de usuario; así se obtiene un kernel más pequeño y modular.
Aún en la actualidad no hay consenso de cuales deben de ser los módulos que deban estar a nivel
de kernel y cuales no. Sin embargo es común encontrar una administración de procesos y me-
moria muy reducida. También implementan los mecanismos de comunicaciones - la cual es su
principal función- entre módulos, los programas del usuario y los distintos servicios ejecutados
a nivel de usuario. Considerando lo anterior el programa cliente y el servicio nunca interactúan
directamente, el microkernel es el medio para establecer la comunicación. El método más común
es el intercambio de mensajes entre el programa cliente hacia el microkernel del microkernel al
servicio y viceversa.
La principal ventaja de usar microkernel en el diseño de un sistema operativo, es su facilidad
para adaptar nuevos servicios. Estos se añaden a la capa de usuario y si es necesario modificar el
microkernel, los cambios serán relativamente fáciles de hacer. Los microkernels son también fá-
ciles de portar a otras plataformas de hardware. También proporcionan mayor seguridad, puesto
que la mayoría de los programas y servicios se ejecutan en el espacio del usuario y no en modo
52 1.6. NÚCLEO
Figura 1.14: Arquitectura parte 4: La capa de Interfaz Humana
kernel.
La principal desventaja que tiene el microkernel es su desempeño frente a otras formas de
implementación. La carga impuesta al microkernel por el paso de mensajes puede ser tal que
el sistema se alente demasiado. La ventaja de utilizar servicios a nivel de kernel es que éstos
pueden comunicarse directamente con otros servicios, lo que por diseño, está prohibido en un
enfoque microkernel.
Windows NT empezó siendo diseñado con la tecnología de microkernel, pero su desempeño
fue peor que el del kernel de windows 98. Se optó por ir agregando mayor cantidad de tareas al
microkernel incluyendo el manejo de gráficos y terminó casi como si fuera un kernel monolítico.
La FSF (Free Software FoundationFundación de Software Libre) diseñó un nuevo kernel
denominado Hurd basado en Mach. Hurd Es un acrónimo recursivo que significa: Hird of Unix
Replacing Daemons y en español: Demonios que reemplazan a Unix. El término Hird significa
Hurd of Interfaces Representing Depth (Hurd de Interfaces que representan profundidad). Tanto
Hurd como Hird en inglés se pronuncian como Herd que significa en español “manada”. Si a
esto añadimos que su nombre real es: GNU Hurd, donde gnu viene a ser una variante de gñu, su
significado sería “manada de gñues”.
Este diseño de kernel se basa completamente en técnicas orientadas a objetos y la idea prin-
cipal es la de no tener un solo programa o kernel que se encuentre administrando todo el sistema,
en vez de ello, un conjunto de servidore a nivel microkernel son los encargados de proporcionar
los servicios necesarios
Figura 1.15: Organización por niveles de un sistema operativo
1.6.1. Kernel Modular

Un kernel modular usa también tecnologías orientadas a objetos en su diseño. La diferen-
cia es que el microkernel se encarga de administrar a un conjunto de módulos necesarios para
realizar alguna alguna tarea específica. La ventaja de este tipo de diseño es que los módulos
pueden cargarse de disco en cualquier momento en que vayan a ser utilizados y descargarse en
el momento en que ya no se ocupen, dejando más memoria principal libre para ser utilizada por
otros procesos.
Este enfoque es el que vamos a encontrar comúnmente en los sistemas operativos actuales
como Solaris, Linux y Mac OS X. Por ejemplo Solaris se organiza alrededor de un kernel que
se encarga de administrar los siguientes módulos:
1. Módulos controladores y de Bus
2. Módulos de Sistemas de Archivos
3. Tipos de planificación
4. Llamadas al sistema
54 1.6. NÚCLEO
5. Otros módulos
La diferencia con respecto a un diseño microkernel es la habilidad que tienen los módulos
de comunicarse entre sí sin pasar a través del núcleo, lo que permite una mayor velocidad de
respuesta.
Mac OS X es un sistema operativo híbrido en el sentido en que empieza un diseño por niveles
pero permitiendo la carga de diferentes módulos dinámicamente con comunicación directa. Mac
OS X está basado también en un kernel Unix, básicamente a nivel de kernel una tecnología Mach
y BSD.
1.6.2. Análisis de los Sistemas Operativos más Comerciales

En la actualidad la competencia en los sistemas operativos se basa más en atraer a los usua-
rios con ambientes llamativos y facilidad de uso que en la calidad interna de los productos.
También la costumbre, la publicidad y la cantidad de software desarrollado para cada uno, tiene
mucho que ver en el número de usuarios que lo usan. Por el momento, los sistemas operativos
dominantes en los entornos personales son los de la empresa microsoft con la línea de Windows
XX (95, 98, ME, XP) y su última liberación llamada windows vista con muchas variantes de
acuerdo al entorno en el que se implemente. En los entornos empresariales, compite con su línea
de Windows NT Server y Workstation, Windows 2000 Server y Windows 2003 server.
El sistema operativo de Apple MAC OS XX, con sus líneas Mac OS X (v10.0 (Cheetah),
v10.1 (Puma), v10.2 (Jaguar), v10.3 (Pantera), v10.4 (Tigre) y su último lanzamiento v10.5
(Leopardo)), están enfocadas a los entornos personales y ha sido adoptado por los profesionales
del diseño gráfico y también en entornos educativos. Ha liberado también una versión Mac Os
Server (1999), para los entornos empresariales.
El sistema operativo Solaris de la empresa Sun MicroSystems tiene su mayor participación
en entornos de los grandes servidores empresariales, gubernamentales y educativos, intentando
entrar con poco empuje en los entornos personales, no obstante ser una de las primeras empre-
sas en innovaciones tecnológicas, de sistemas operativos, ambientes de programación, servicios
WEB, sistemas de multiproceso y clusters de computadoras, por mencionar algunas.
El sistema operativo GNU/Linux, es el más joven en cuanto a su desarrollo, pues el núcleo
fue desarrollado en 1992, pero todas las demás herramientas estaban disponibles desde 1990
auspiciadas por la FSF (Free Software Foundation). GNU/Linux tiene sus raíces en el entorno
educativo, llegando a ser utilizado por empresas que creen en el software libre. El software
libre en general va ganando mucha popularidad principalmente desde el año 2000 a la fecha,
entrando con mucho empuje en los entornos personales y llegando a ser un competidor muy
serio también en los entornos de servidores. Incluso Sun Microsystems apoya de frente el uso
del software libre abriendo el código de varios de sus productos, pero con otro tipo de licencia.
En los siguientes apartados haremos una descripción general de todos estos sistemas opera-
tivos. procurando abarcar los aspectos más importante de cada uno de ellos.
1.6.3. GNU/Linux
En esta sección presentamos un análisis general del sistema operativo GNU/Linux. Haremos
hincapié en sus ventajas y desventajas y los posibles ambientes en los que puede ser usado con
éxito.
1.6.3.1. Breve historia de GNU/Linux
El sistema operativo GNU/Linux está basado en un kernel desarrollado por Linus Torvalds,
un estudiante de la Universidad de Helsinky Finlandia. La idea primaria era desarrollar un kernel
basado en Minix (Para una historia completa desde UNICS, UNIX y Minix puede verse [101]),
pero con más facilidades y además que aprovechara todas las características del microprocesador
80386 desarrollado por Intel con una capacidad real de 32 bits y soporte de modo protegido. Un
poco después Linus Torvalds, puso a disposición gratuitamente de la comunidad de Internet
el código fuente del incipiente kernel. Cual sería su sorpresa cuando gente de todo el mundo
empezó a enviar sugerencias y la mayoría de las veces aportaciones muy importantes de código
para ir mejorando poco a poco el núcleo y darle mayor funcionalidad, acercándose cada vez más
a la funcionalidad de UNIX. La historia de linux, como se mencionó en 1.6.2 está fuertemente
relacionada con la FSF fundada en 1985 por un grupo de personas encabezadas por Richard
Stallman, cuyo ideal es que todo el mundo tenga acceso a software de calidad y sin ningún
costo. Para ello se diseñó una licencia especial conocida como copyleft como contraparte a
copyright. Del copyleft surge la GPL o “Licencia Pública General”, la cual permite ejecutar,
copiar, modificar y distribuir el software creado y distribuido bajo esta licencia.
En 1990, el sistema GNU de software libre, ya contaba con un editor de texto y un com-
pilador que rivalizaba con cualquier compilador comercial, a su vez también contaban con la
mayoría de las bibliotecas y utilidades para tener un sistema operativo funcional.
Hay que tener en cuenta que un sistema operativo no es solamente el kernel. El kernel se
encarga de administrar los procesos, la memoria, los dispositivos de entrada/salida, la CPU y
el sistema de archivos, pero se necesita el software que debe de hacer uso de todos estos recur-
sos, para todos los tipos de usuario que van a usar el sistema operativo. Hablamos entonces de
aplicaciones de oficina, servicios cliente-servidor y toda la gama de programas que existen en
56 1.6. NÚCLEO
la actualidad para cubrir las necesidades de todos nuestros tipos de usuarios: usuarios finales,
usuarios, programadores y usuarios administradores.
En 1992 el núcleo Linux fue integrado al Proyecto GNU bajo la Free Software Foundation
resultando de esta unión un sistema operativo completamente libre y funcional.
El proyecto GNU porta la mayoría de sus programas a otras plataformas, incluyendo UNIX,
Solaris, Windows y Mac OS X, por lo que puede existir perfectamente sin Linux. El kernel
Linux sin embargo, representa la posibilidad de tener un sistema operativo completamente in-
dependiente de las firmas de sistemas operativos comerciales, por que si existe algún tipo de
alianza con otro fabricante, es posible que impidan parcial o totalmente la ejecución de software
libre en sus sistemas operativos.
Las primeras áreas en las que fue utilizado GNU/Linux fue en las académicas dado que
era posible analizar al detalle requerido, la forma en que están implementados los distintos
componentes de un sistema operativo.
1.6.3.2. El núcleo de Linux
Linus Torvalds presentó al público la versión 0.01 en mayo de 1991, no podía conectarse vía
red y se ejecutaba en microprocesadores 20386 y compatibles. Poseía muy pocos controladores
de dispositivos. Manejaba el sistema de archivos Minix y su sistema de memoria virtual era muy
limitado. Algo importante es que el kernel ya implementaba adecuadamente los procesos con
espacios de direcciones protegidos.
Cuando se liberó la versión 1.0 en marzo de 1994, el kernel ya era capaz de comunicar-
se vía red, tenía soporte para los protocoles de red estándar TCP/IP de UNIX, habían también
implementado los sockets con compatibilidad BSD. Incluía un sistema de archivos mejorado y
además incluía soporte para controloadores SCSI para acceso a discos de alta velocidad, me-
joraron el sistema de memoria virtual permitiendo de esta manera el uso de paginación sobre
los archivos de intercambio y el mapeo de memoria de archivos arbitrarios. El sistema imple-
mentaba también mecanismos de comunicación interprocesos (IPC)basados en System UNIX
V, incluyendo memoria compartida, semáforos y colas de mensajes. Incluía soporte para car-
gar/descargar módulos dinámicamente del kernel. La siguiente versión importante es la versión
2.0, se mejoró el administrador de memoria para proporcionar una caché unificada para los datos
del sistema administrador de archivos. Se extendió a su vez el mecanismo de caché del siste-
ma de archivos a los sistemas de archivos de red. Se añadieron al kernel nuevos protocolos de
red incluyendo AppleTalk AX.25 y se mejoró substancialmente la eficiencia del protocolo de
TCP/IP.
La última versión hasta el momento es la 2.6.18 en su versión estable que incluyen un soporte
mejorado para los sistemas SMP (Multi Procesamiento Simétrico), sistemas de archivos con
registro diario y mejoras en el administrador de memoria. El kernel de Linux mantiene ahora un
esquema apropiativo, permitiendo al núcleo desalojar un proceso mientras se ejecuta en modo
kernel y el planificador de procesos cuenta con un eficiente algoritmo de planificación.
1.6.3.3. El Sistema GNU/Linux
Como se mencionó en 1.6.3.1. El desarrollo de buena parte del núcleo fue auspiciado por la
FSF, pero tener un sistema funcional completo es otra historia.
En particular un sistema operativo GNU/Linux utiliza herramientas desarrolladas por mu-
chísimas personas alrededor del mundo. En particular usa muchas librerías que pertenecen al
sistema operativo BSD de la Universidad de Berkeley California, la cual también tiene su con-
traparte en el software libre denominado Free BSD. Otro componente importante es la interfaz
gráfica del usuario basada en X Window que fue desarrollada por el Instituto Tecnológico de
Massachusets o MIT y básicamente todo el soporte de software para la programación de siste-
mas fue proporcionado por el proyecto GNU. Por mencionar unas pocas tenemos: el compilador
C de GNU llamado gcc, editores como el GNU-emacs el depurador gdb el controlador de ver-
siones de programas CVS, entre muchas otras más.
1.6.3.4. Distribuciones más Importantes de GNU/Linux
Dado que el sistema operativo GNU/Linux es libre y de código abierto, es posible en teoría
que cualquier usuario pueda modificar el sistema al grado que desee. En particular, lo que es
complicado para la mayoría de las personas que no están involucradas en el área de ciencias
computacionales o afines, es instalar un sistema en donde sea necesario bajar los códigos fuente
del sistema operativo, compilarlo y después instalarlo en donde corresponda. Esta tarea a su vez
debe de repetirse para cualquier nuevo componente, servicio o aplicación que deseemos instalar
en nuestro sistema. Antes de poder instalarlo sería necesario buscar en internet el programa
adecuado. Este proceso sería muy tedioso para el común de las personas.
El siguiente nivel en la organización de las comunidades de internet es la personalización del
sistema GNU/Linux. Al producto que generan las comunidades que se encargan de personalizar
un sistema operativo GNU/Linux se le denomina distribución. Una distribución es una manera
particular de “distribuir” el software de un sistema GNU/Linux. En general los desarrolladores
de sistemas entregan solamente el código fuente del programa y las librerías necesarias para
poder instalarlo. Además entregan también un listado de librerías que necesita el programa en
tiempo de ejecución a la que se les denomina “dependencias” y que en ocasiones forman parte
del propio sistema GNU/Linux. Una comunidad que mantiene una distribución se encarga de
58 1.6. NÚCLEO
administrar sitios en donde juntan todo el software que forma parte de su distribución. A cada
programa que incluyen se le denomina “paquete”. Es común que a cada paquete se le asigne una
persona para mantenerlo actualizado, esto es, verificar si la comunidad de desarrolladores de ese
paquete hizo cambios. Si es así, entonces lo compilará y empaquetará de modo que cumpla con
las reglas de la distribución. Si se soporta más de una plataforma, entonces, repetirá el proceso
para todas ellas verificando que no haya problemas en las dependencias. La persona que man-
tiene el paquete no corrige errores del programa. Además de tener todos los programas que les
parecen convenientes, desarrollan otras herramientas para simplificar la instalación del sistema
completo, pasando por los asistentes de instalación, los asistentes de instalación y configura-
ción de manejadores de dispositivos, administradores de paquetes y otras herramientas que les
permitan a los usuarios no tan avanzados hacer sus tareas lo más fácil posible.
Aunque hablamos de software libre, vamos a encontrar distribuciones apoyadas por em-
presas comerciales, por ejemplo, las más representativas son Red Hat y Mandriva las cuales
manejan dos versiones de sistemas GNU/Linux fedora y mandriva, que son distribuciones li-
bres, pero para aquellas empresas que necesiten soporte técnico, se les ofrecen distribuciones
mejoradas a un precio razonable. En este caso no venden el sistema operativo, venden la dis-
tribución o el empaquetado de programas, la integración de controladores de hardware o en su
defecto el soporte técnico. Por ejemplo, Red Hat maneja su versión Red Hat Enterprise orientada
a servidores y mandriva ofrece su Corporate Desktop 4.
Una derivación de la antigua distribución Mandrake y que está teniendo mucha aceptación
en el mundo linux es PCLinuxOS, puede descargarse un DVD listo para usarse y con una
cantidad enorme de manejadores de dispositivos y de lo último en aplicaciones de usuario.
En Alemania y en el mundo, una de las distribuciones comerciales más fuertes es Suse con
un instalador de dispositivos mejorado y un manejador de paquetes relativamente fácil de usar y
con un gran soporte de controladores, es una de las preferidas de muchos usuarios.
Merece mención aparte una de las distribuciones más jóvenes la comunidad de Ubuntu.
Es una de las mejores distribuciones basadas en Debian ganando cada vez más usuarios. Es
patrocinada por una empresa comercial llamada canonical, pero ofreciendo incluso los medios
(CD, DVD) y el envío al lugar que se le indique en forma gratuita hasta el momento. La ventaja
con respecto a Debian es la actualización constante en manejadores de dispositivos y programas
con los últimos avances, aunque en ocasiones adolece de la estabilidad de Debian
Dentro de las distribuciones completamente gratuitas, la más representativa es Debian. Lo
más interesante es su contrato social, en donde se comprometen a mantener por siempre una
distribución de calidad sin cobrar un sólo centavo, contrario a lo que pasó con Red Hat y Ma-
drake(Mandriva), que al tener una base de usuarios lo suficientemente grande optaron por
lanzar una distribución paralela con un costo (Aunque muchas de las veces es simbólico).
Debian mantiene tres versiones de sus sistemas GNU/Linux. La versión Estable (Stable Ver-
sion), La versión de pruebas (Testing Version) y la versión inestable (Unstable version). La ver-
sión estable se recomienda usarla en ambientes productivos y en donde se requiera la máxima
estabilidad. La versión testing la usan personas o empresas que necesiten paquetes o manejado-
res de dispositivos actualizados pero que no les interesa tanto la estabilidad y la versión inestable
es para aquellos usuarios que deseen tener lo último o para los desarrolladores que están pro-
bando sus aplicaciones.
Aunque en términos generales en ocasiones la estable tiene más problemas en ambientes

personales, se recomienda su uso en entornos de servidores. Los usuarios normales tiene la
opción de elegir entre cualquiera de las tres dadas sus necesidades específicas.
Un problema que siempre se achacó a Debian fue su “difícil instalación”, que en realidad no
es más que un mito. En la actualidad es tan fácil instalar la versión estable etch como cualquier
distribución de ubuntu o alguna otra. Actualmente se puede escoger entre un instalador en modo
gráfico o modo texto, dando la oportunidad de hacer algunas tareas automáticamente o con
intervención del usuario.
Al momento de escribir estas líneas, existen más de 120 distribuciones. Es común que la
mayoría de los países personalicen sus sistemas GNU/Linux creando así una nueva distribución.
Es también normal que varias instituciones educativas hagan su propia distribución. Incluso en
internet se pueden encontrar programas que ayudan en el proceso de creación de una nueva
distribución.
Existen distribuciones de GNU/Linux para casi todas las necesidades. Desde Grandes em-
presas, centros de investigación, entidades gubernamentales, hasta los usuarios ocasionales que
desean probar algo nuevo. Básicamente se puede conseguir la mayoría de los paquetes y servi-
cios que existen para un sistema operativo comercial. El pago, que mucha de la gente no está dis-
puesta a dar es el tiempo de aprendizaje cuando queremos ir más allá de un usuario de escritorio.
Podemos instalar básicamente cualquier programa con un poco de esfuerzo y de investigación
en la red. Muchas de las veces tenemos que conseguir asesoría en la misma red, preguntando a
otros usuarios. No hay un servicio técnico a la mano cuando hablamos de distribuciones libres,
pero sí tenemos a muchísima gente que ha recorrido antes el camino que empezamos a andar.
Si no conseguimos la funcionalidad que se busca, podemos implementarla o empezar un nuevo
proyecto libre para cubrir esa laguna. Habrá miles de usuarios dispuestos a ayudarnos en toda la
internet, cuyo único aliciente es trabajar por amor a la computación.
60 1.6. NÚCLEO
1.6.4. Solaris
El sistema operativo Solaris se basó en UNIX BSD de la Universidad de Berkeley. Luego
lo mejoraron incorporando todos los requerimientos impuestos por UNIX System V. De esta
manera se convirtió en un sistema operativo basado en System V.
En 1992 se publicó la versión Solaris 2, en ese momento se hace la diferencia entre el kernel
y los programas o servidores de aplicación
Solaris soporta SMP (Multi procesamiento simétrico) y desde Solaris 7 tiene soporte para
aplicaciones de 64 bits.
Solaris soporta las arquitecturas SPARC y x86 incluyendo sus compatibles como AMD64.
Solaris 10, la última liberación de Sun Microsystems, proporciona todos los servicios que
una empresa pueda desear. El sistema operativo ofrece flexibilidad y fiabilidad en servidores
dedicados.
Dentro de los servicios básicos ofrece un ambiente gráfico basado en CDE, lo que no impide
usar otras interfaces de usuario basadas en software libre como Gnome o KDE, las cuales pue-
den integrarse fácilmente en CDE o incluso substituirlo. El último escritorio de Solaris es Java
Desktop System basado en Gnome y es el que está incluido por defecto.
Solaris 10 incluye mas de 600 nuevas funciones, muchas de las cuales no están disponibles
en otros sistemas operativos. Por ejemplo, incluye un depurador llamada DTrace, maneja una
nueva tecnología de sistemas de archivos denominada ZSF y las extensiones Solaris Trusted
Extensions. El sistema operativo Solaris 10 puede descargarse gratuitamente para uso personal
o sin fines de lucro. Para poder usar Solaris comercialmente se necesita autorización y por lo
común se debe de hacer algún pago. Otras características importantes de Solaris son:
Seguridad. Incluye algunas de las características más avanzadas del mundo, tales como Manejo
de Derechos de Usuario y de procesos, Extensiones probadas para el Control de Acceso
Obligatorio, un marco de trabajo criptográfico y la Red Segura por omisión que permiten
proteger datos de misión crítica con seguridad.
Desempeño. Proporciona ventajas inigualables para servicios basados en tecnología de bases

de datos, Web y Java, así como escalabilidad masiva ofreciendo muchas ventajas pre-
cio/desempeño
Redes. Con su pila de redes optimizada y soporte para los protocolos actuales de computación
de redes avanzadas. Solaris 10 proporciona funciones de red de alto desempeño sin modi-
ficaciones.
Manejo de datos. Ofrece avances dramáticos en el sistema de archivos y administración de

volúmenes proporcionando capacidad virtualmente ilimitada y administración cercana a

cero.
Interoperatividad. Proporciona un conjunto de herramientas para habilitar la interoperatividad

con muchísimo hardware heterogéneo y plataformas de software
Herramientas de depuración. DTrace permite habilitar la depuración y optimización de apli-

caiones en tiempo real.
Opciones de plataforma. Puede correr en sistemas basados en SPARC 800 y en sistemas ba-
sados en x64/x86 incluyendo sistemas de Sun, Dell, HP e IBM.
Virtualización. Incluye las últimas características de virtualización, que permiten consolidar,

aislar y proteger miles de aplicaciones sobre un único servidor.
Disponibilidad. Las características de Autoverificación predictiva, diagnóstico automático y

recuperación de hardware y fallas de aplicaciones, maximizan la disponibilidad del siste-
ma.
Soporte y Servicio. Ofrece un amplio portafolio de clase mundial para que sus usuarios explo-
ten l máximo el potencial de su sistema.
Como puede verse, Solaris es uno de los sistemas operativos más avanzados hasta el mo-
mento, integrando lo mejor del software libre y las innovaciones tecnológicas, permitiendo una
enorme retroalimentación con la comunidad. Como parte de esta retroalimentación, existe una
versión libre y gratuita llamada openSolaris que ofrece las mismas características del sistema
operativo, pero permitiendo una mayor personalización.
En los grandes entornos empresariales, de gobierno y educativos es una de las principales
opciones para implementar. Ofrece muchas ventajas y facilidades de desarrollo.
La principal desventaja es su gran complejidad en la administración, que se ve recompensada
con creces con el tiempo. Pues muchas de las veces, después de instalado el sistema con todas
las aplicaciones sólo resta descansar y monitorear el buen funcionamiento de las aplicaciones
durante muchísimo tiempo. Podemos decir que es el paraíso de los administradores, después de
pasar un período demasiado complicado durante la instalación de servicios.
por otro lado, para un usuario medio sería muy difícil, a lo mejor no instalar el sistema
operativo, pero sí conseguir e instalar los manejadores de dispositivos y aplicaciones.
Este sistema operativo se recomienda más para profesionales de desarrollo y para entornos
institucionales, empresariales o instituciones educativas que para ser usado en casa como sis-
tema operativo casero o familiar, puesto que no está diseñado precisamente para ello. Aunque
62 1.6. NÚCLEO
últimamente se han añadido características que permiten una interacción más sencilla para los
usuario caseros o novatos, aún es muy difícil que pueda penetrar en ese mercado tan competido.
1.6.5. MacOS
Mac OS X fue desarrollado por Apple Inc, usando un modelo de desarrollo de código ce-
rrado, lo que implica que no puede modificarse excepto por sus programadores. Aunque existe
una versión denominada fundación Darwin que es de código abierto. El núcleo está basado en
la tecnología de microkernel de Mach pero con algunas modificaciones importantes, tales como
hacerlo un kernel modular y permitir comunicación directa intermodular, con carga de módulos
dinámicos para mejorar su eficiencia. Sus versiones de servidor tienen también características
de administración muy avanzadas.
En cuanto al software del sistema éste se basa en los últimos avances de la comunidad de
código abierto BSD. El resultado es una estable plataforma de 64 bits de alto rendimiento, el
entorno ideal para ejecutar aplicaciones y servicios.
En lugar de desarrollar tecnologías propietarias, Apple ha adoptado los mejores proyectos de
código abierto, como Apache, Samba, OpenLDAP, Kerberos, Postfix, Jabber y SpamAssassin.
Mac OS X Server[51] integra estas robustas tecnologías y las potencia con una homogé-
nea interfaz de gestión unificada. Sus potentes herramientas administrativas permiten a los pri-
merizos configurar y mantener servicios de red clave, y proporciona además las prestaciones
avanzadas que los profesionales de TI más curtidos necesitan.
Como Mac OS X Server está diseñado con estándares abiertos es compatible con cualquier
infraestructura de red actual. Emplea protocolos nativos para ofrecer servicios de directorio, de
archivos e impresión, acceso remoto seguro a clientes Mac, windows y linux. Se preocupa tam-
bién por su compatibilidad con sistemas no unix, principalmente con windows 2003 y Windows
XP. Por otra parte, la arquitectura de servicios de directorio estándar open Directory permite ad-
ministrar de forma centralizada todos los recursos, incluso los privativos, como Active Directory
de Microsoft.
El servidor Mac OS X combina lo último en tecnologías de código abierto con la tecnología
líder de la industria de Apple de facilidad de uso. La potencia del servidor Mac OS X es un
regreso a los estándares de la industria de código abierto sobre las tecnologías propietarias.
Comienza con un núcleo de código abierto basado en la arquitectura de red de BSD, ofreciendo
las capacidades que se esperan de un sistema UNIX, tal como multiprocesamiento simétrico,
tecnología multihilo y memoria protegida. Mac Os X proporciona una plataforma estable para
ofrecer un alto desempeño con aplicaciones y servicios de nivel empresarial.
1.6.5.1. La fundación UNIX: el kernel Darwin y BSD
El núcleo del servidor Mac OS X se conoce como Darwin, el mismo que se usa para el
sistema operativo de Apple para computadoras de escritorio y computación móvil. Darwin pro-
porciona al servidor Mac OS X la estabilidad, desempeño y fiabilidad asociado con UNIX.
En el corazón de Darwin tenemos un microkernel Mach 3.0 basado en el proyecto de la OSF
(Open Software Foundation) Fundación de Software Abierto. El kernel Mach proporciona ser-
vicios de administración de memoria, control de hilos, abstracción de hardware y comunicación
interprocesos. Darwin incluye lo último en avances tecnológicos de la comunidad de BSD de
código abierto. Originalmente desarrollado en la Universidad de California, Berkeley, la distri-
bución BSD es el pilar de muchas implementaciones de UNIX actuales. Darwin está basado
ampliamente en la distribución FreeBSD e incluye los últimos avances de esta comunidad de
desarrollo.
Con esta rica herencia, Apple entrega servicios de servidor que incluye:
Tecnología Multihilos. Proporciona una mejor administración de hilos para manejar eficiente-
mente aplicaciones multihilos, más aún si los hilos están corriendo sobre múltiples proce-
sadores. Mac OS X implementa los hilos basándose en los hilos POSIX.
Multiprocesamiento simétrico.(SMP) . Mac OS X obtiene toda la potencia de procesamiento

en los sistemas multiprocesamiento, habilitando a las aplicaciones para que se benefi-
cien inmediatamente de el excepcional desempeño de múltiples procesadores. Las tareas
complejas, -tales como cálculos numéricos, consultas de bases de datos y operaciones de
comprensión y codificación-.
Caché con búfer unificado. Para minimizar el acceso a disco y el uso de la memoria principal
muchos sistemas UNIX habilitan los subsistemas de memoria virtual y el sistema de archi-
vos para compartir los búferes del kernel. Mac OS X también utiliza este enfoque y mapea
automáticamente la memoria física y los archivos en la memoria virtual para minimizar el
uso de los recursos del sistema.
Servicios de 64 bits. Las características del núcleo y las librerías de software del sistema del
servidor de MAC OS X están actualizadas específicamente para el procesador G5 Po-
werPC de 64 bits. Con direccionamiento completo de memoria de 64 bits, las aplicaciones
pueden ahora romper la barrera de la memoria física de 4 Gigabytes, permitiéndoles ma-
nejar grandes conjuntos de datos comúnmente encontrados en soluciones de computación
científica, bases de datos y multimedia. Las librerías matemáticas y de vectores han sido
afinadas para obtener la máxima ventaja de las funciones nuevas y más rápidas soportadas
por el procesador G5 PowerPC de 64 bits.
64 1.6. NÚCLEO
Multiconexión. Habilita al servidor Mac Os X mantener múltiples direcciones IP sobre la mis-

ma o sobre múltiples interfaces. Esto es lo ideal para conectar al servidor simultáneamente
con múltiples redes, tales como una red pública o una red privada, o mantener múltiples
sitios de red, cada uno con su propia dirección IP.
IPv6. Muchos de los servicios en el servidor MAC OS X han sido actualizados para soportar
el protocolo de internet versión 6 o IPv6. IPv6 elimina muchos de los problemas en IPv4,
especialmente aquellos relacionados con el número de direcciones disponibles y añaden
funcionalidad en áreas tales como el ruteo y autoconfiguración de las redes.
IPSec. IPSec es un conjunto de protocolos de propósito general para proteger comunicaciones

TCP/IP. Su mecanismo de criptografía de capa de red proporciona privacidad en el uso de
datos e incriptación en el encabezado del paquete, integridad y autenticación del paquete
de origen, y manejo de claves. Aunque es parte del estándar IPv6, IPSec puede ser usado
sobre redes IPv4.
IP sobre FireWire. Ideal para redes y administración de sistemas IP sobre FireWire permite
crear una red punto a punto de bajo costo entre dos dispositivos. IPS sobre FireWire es
también útil como una red de latencia baja y ancho de banda alto en computación de alto
desempeño, aplicaciones de clustering y escenarios IP tolerantes a fallos.
Sistema de Archivos de 64 bits. Mac OS X tiene soporte para un sistema de archivos de 64 bits
además de permitir sistemas de archivos HFS+ (y HFS+journaled) más allá de del límite
de los 64 Terabytes de los sistemas de archivos de 32 bits. Esto habilita a los diseñadores
el desarrollo de aplicaciones que usen volúmenes enormes de bases de datos, archivos de
imágenes y almacenamiento de vídeo digital.
Altos estándares de seguridad. Probados por los expertos de seguridad a nivel mundial, los
protocolos de seguridad estándares de la industria soportan todos los aspectos del sistema,
la seguridad de los datos y del sistema de red requeridos pos las aplicaciones de hoy.
Como puede verse, el sistema operativo MAC OS X ofrece una gama completa de servi-
cios a todos los niveles con una capacidad impresionante. Por tradición, las computadoras y el
sistema operativo MAC OS X los usuarios los han orientado hacia el diseño y desarrollo de apli-
caciones multimedia, incluyendo procesamiento de imágenes, creación de vídeos y renderizado.
No obstante podemos ver que sus aplicaciones pueden ir más allá de éstas y quedar plenamente
satisfecho con este sistema operativo con todas las ventajas de UNIX y la facilidad de uso de un
sistema operativo basado en windows.
El último sistema operativo que analizaremos será windows2003 server en la sección 1.6.6
1.6.6. Windows 2003 Server

1.6.6.1. Un poco de historia
Microsoft, una empresa fundada por Bill Gates, empezó con un sistema operativo mono-
usuario, basado en el microprocesador 8088/8086, allá a principios de los años 80’s, al que
llamó MS-DOS (MicroSoft Disk Operating System) Sistema Operativo de Disco de MicroSoft.
Todo el sistema se podía adquirir en un conjunto de discos y para ejecutarse comúnmente ne-
cesitaba sólo un disco flexible. Incluía una versión del lenguaje de programación BASIC al que
llamó Q-BASIC. Cuando IBM lanzó sus computadoras personales (1980), contrató a microsoft
para desarrollar su sistema operativo e incluirlo en ellas, básicamente IBM trató a las compu-
tadoras personales como un “juguete”, comparadas con las grandes computadoras que en ese
entonces se usaban en la industria, por lo que no hizo caso de crear un sistema operativo propio.
Cuando, varios programadores se dieron cuenta del enorme potencial de las computadoras
personales basadas en los microprocesadores de Intel, empezaron a hacer múltiples aplicaciones
y a venderlas por su cuenta, dejando de lado a las grandes compañías. Borland desarrolló su
turbo Pascal y turbo C, el propio microsoft desarrolló otro lenguaje de programación para el
lenguaje C al que llamó C de microsoft. Tiempo atrás (1977) ya había desarrollado Microsoft
Fortran. Con el sistema operativo funcional a nivel monousuario, estas primeras herramientas
de programación, una computadora personal que era decenas o cientos de veces más barata que
cualquiera de su tiempo y mucha gente queriendo participar en el negocio del software, pronto
empezaron a surgir una inmensa variedad de programas de todo tipo desde juegos, editores
de texto, manejadores de datos como dBase y otras más para las microempresas y negocios
familiares.
Era cierto que la computadora sólo podía ejecutar un solo programa a la vez y que era
necesario cargar nuevamente el sistema operativo después de haber ejecutado ese programa, pero
al fin las computadoras estaban al alcance de todos. El lema de Bill Gates era “una computadora
para cada hogar”. No importaba que en ocasiones la computadora se “colgara” por un programa
mal diseñado, se adquiría la versión corregida y se continuaba trabajando. Los virus hicieron su
aparición con la versión 5. Modificaban el sector de arranque y de ese modo podían tomar el
control de los recursos y autoreplicarse en cualquier disco que se introdujera en la disquetera o
los discos duros. El más notable fue el de “ping Pong” una pelotita que iba rebotando por toda la
pantalla de la computadora hasta que ésta se reiniciara. Después fueron diseñándose virus más
complejos aprovechando las vulnerabilidades de este sistema operativo.
El MS-DOS llegó hasta la versión 6, si hablamos de manejo en modo texto.
Desde la versión 5 microsoft empezó a introducir el ambiente gráfico denominado windows,
basado en una interfaz gráfica con uso de ratón de la empresa Xerox. La primera versión estable
66 1.6. NÚCLEO
fue la Windows 3.1, la cual corría sobre MS-DOS. Con el lanzamiento de windows 3.1, empeza-
ron a surgir también las aplicaciones de ventanas surgiendo las hojas de cálculo, los procesadores
de texto y manteniendo su compatibilidad a toda costa con toda la gama de aplicaciones en modo
MS-DOS.
Con el advenimiento de los procesadores 80286/20386, se pensó en mejorar el sistema ope-
rativo, de ese modo surgió windows 95 que sin embargo aún no aprovechaba por completo las
características de estos procesadores. Ahora se cargaba directamente de disco duro y no era ne-
cesario ejecutar el MS-DOS, no obstante, se ejecutaba sobre la versión 7 del sistema operativo
MS-DOS, aún con todos los problemas que podían ocasionar aquellos programas mal diseñados.
Así el usuario tenía toda la responsabilidad sobre lo que pudiera ocurrir sobre sus datos.
Microsoft al observar que tenía una base de usuarios empresariales muy grande empezó a
incursionar con los sistemas operativos de red en 1993, empezando con Windows NT Server
y windows NT Workstation. Anteriormente ya había había incursionado en las redes locales al
proporcionar mecanismos de conectividad mediante el protocolo NetBeui y tenía compatibilidad
también con IPX/Novell y TCP/IP.
Al darse cuenta que el núcleo del sistema operativo de windows 95 no cumplía con los
estándares de seguridad exigidos por la industria, comenzó a diseñar un kernel completamente
nuevo basado en la tecnología micronúcleo de mach, pero no a nivel funcional, obligado por
el hecho de mantener la compatibilidad con todos los programas diseñados para windows 95 y
anteriores.
La siguiente versión fue windows 98, el sistema operativo ahora incluía una interfaz más
fácil de usar y el número de aplicaciones para estas computadoras seguía creciendo por su acce-
sibilidad en costo.
Por el lado de servidores sale al mercado Windows 2000 server para reemplazar a windows
NT server, el cual no pudo reemplazar a windows 98 del escritorio. En versiones de servidores
el último lanzamiento fue Windows 2003 Server.
Para mejorar la seguridad en las computadoras personales, diseña windows XP basado en
la tecnología de windows 2000. Pero aún el problema sigue siendo la compatibilidad con las
aplicaciones. En esta versión ofrece distintas maneras de compatibilidad hacia atrás y firma
contratos con las empresas de software para poder certificar su uso bajo windows XP y de esta
forma mejorar su disponibilidad.
La última versión y que supone todo un cambio, en el desarrollo del sistema operativo, ahora
sí basado en una reingeniería total y dejando de lado, hasta cierto punto la compatibilidad -
que siempre había sido su principal problema- saca al mercado Windows Vista que promete
terminar de una vez por todas con los problemas de seguridad.
1.6.6.2. Características importantes
A continuación hacemos una referencia de las características más importantes del sistema
operativo windows 2003 Server de microsoft:
Fácil uso. Microsoft tradicionalmente ha enfocado sus esfuerzos en hacer lo más sencillas po-
sibles la instalación desde el sistema operativo hasta los servicios y las aplicaciones.
Seguridad de la red. Hace uso de funciones de clave, como las relaciones de confianza entre
bosques del servicio de Microsoft Active Directory integrando Microsoft .Net passport.
Permite la administración de identidades por toda la red. Permite a su vez el cifrado de
datos confidenciales de una manera sencilla y puede aplicar directivas de restricción de
software para prevenir los daños causados por virus y otro tipo de código malintencionado.
Permite implementar una infraestructura de claves públicas.
Disponibilidad y confiabilidad. Mejora la confiabilidad con funciones nuevas como el reflejo

de memoria y la memoria agregada en caliente. Permite implementar un servicio denomi-
nado Microsoft Cluster que puede admitir hasta ocho nodos juntos o separados geográfi-
camente.
Sitios Web al instante. Permite al aislamiento entre aplicaciones y un rendimiento muy mejo-
rado. Con los servicios de Windows Media es posible la transmisión de secuencias mul-
timedia con programación de contenido dinámico y puesta a punto de un sitio de internet
fácilmente
Portabilidad. Un sistema operativo es portable si se le puede migrar a una arquitectura diferente

con un número de cambios relativamente pequeño. El kernel de Windows depende de una
Capa de Abstracción de Hardware (Hardware Abstraction Layer o HAL) de manera que
todas las funciones dependientes de la arquitectura se encuentran encapsuladas en esta
capa. Además todo el sistema operativo está escrito en C y C++. Esto asegura que cuando
sea necesario pueda portarse a una arquitectura que cumpla con las especificaciones IA32
e IA64.
Escalabilidad. La escalabilidad se refiere a la capacidad que tiene un sistema operativo de

añadir nuevos avances tecnológicos, tanto de hardware como de software. Debido a que
el programa ejecutivo o kernel del sistema operativo proporciona los servicios básicos
del sistema, existe arriba de éste otro nivel que se denomina subsistema de entorno que
emula diferentes sistemas operativos. gracias a su estructura modular, se pueden añadir
subsistemas de entornos sin afectar al kernel. También usa la carga de módulos dinámicos,
68 1.6. NÚCLEO
lo que permite añadir nuevos sistemas de archivos, nuevos dispositivos de entrada/salida,

mientras el sistema continúa funcionando.
Aunque microsoft ha avanzado mucho en sus sistemas operativos en el área de servidores

y computadoras personales, en comparación con otros sistemas operativos falta todavía cierto
camino por recorrer. Empezó con un sistema operativo orientado al hogar y esa tendencia toda-
vía pesa mucho en cuanto a la seguridad de sus sistemas, lo cual muchas de las veces ya ni el
sistema operativo es el culpable. Debido a la facilidad de uso del sistema, algunos administra-
dores no hacen las actualizaciones a su debido tiempo, aunque hayan sido informados de alguna
vulnerabilidad, ni tampoco cuentan con todas las herramientas que exige un sistema de ese tipo,
esto es, software antivirus, paredes de fuego, autenticación segura, actualizaciones automáticas,
respaldos continuos automáticos y toda la gama de software para mantener funcionando en buen
estado el sistema, que muchas de las veces ya está disponible y sólo es cuestión de planificarlo
y darle seguimiento.
En general, su línea de sistemas operativos es buena en su rama. Los que están diseñados
expresamente para el hogar ahí es donde deben de ser utilizados. Los que son para los entornos
empresariales, deben de tener sus planes de seguridad completos y tener disponibles todas las
herramientas necesarias para que tengamos un sistema operativo lo más fiable posible (que sí lo
es) pero estar pendientes de que se hayan hecho las actualizaciones del sistema, de los antivirus,
de las paredes de fuego y las demás tareas administrativas, para que sepamos realmente qué está
haciendo el sistema.
1.6.7. Consideraciones finales

Por lo analizado anteriormente la línea de sistemas operativos de microsoft, empezaron con
ambientes familiares, en donde no era necesario tener un sistema completamente confiable debi-
do a las aplicaciones que se tenían. Aunque microsoft haya querido diseñar un sistema operativo
confiable basado en los modelos de sistemas operativos existentes en su tiempo, debido a la falta
de características en hardware como el modo protegido, era imposible en su momento. Intel al
igual que microsoft recorrió un camino difícil y tuvieron nuevamente que innovar y mejorar lo
que ya estaba funcionando en esos momentos en otra escala. El principal acierto de Intel fue la
de crear sus microprocesadores y la de microsoft hacer un software que funcionara para esas po-
cas necesidades, y ahora ambas compañías compiten con cualquier computadora de las grandes
firmas de servidores y en la mayoría de los casos, están ganando una batalla, que al principio no
existía.
Ahora las grandes firmas está volteando otra vez al cómputo personal y quieren también
participar en este inmenso mercado. Aunque tienen productos de calidad muy superior y la
mayoría de las veces prácticamente regalan sus sistemas operativos, falta que ganen la lucha
contra la costumbre, la comodidad o facilidad de uso, la inmensa cantidad de software y la
ignorancia de mucha gente inclusive a veces de gobiernos completos.
Al final, un sistema operativo, basado en UNIX, mal administrado puede ser peor que tener
un sistema operativo con vulnerabilidades pero bien administrado y actualizado. Ahora también
entra en juego un personaje que antes estaba oculto: El administrador de los Sistemas Operativos
que será el responsable de que todos los servicios estén al día, y funcionando.
1.7. Problemas
1.1. Explique con sus propias palabras: ¿Qué es un sistema operativo?, ¿Cuáles son sus
funciones?, ¿Cuáles son sus objetivos?
1.2. Enumere cinco posibles lugares en donde haya tenido contacto con algún sistema ope-
rativo.
1.3. Describa las funciones o actividades de cada tipo de usuario de un sistema operativo.
1.4. Realice un diagrama sobre la arquitectura de una computadora y explique detallada-

mente sus componentes.
1.5. Describa en forma ordenada los pasos que se llevan a cabo en el proceso de arranque.
1.6. Realice una línea de tiempo anotando los eventos que considere más importantes en la
evolución de las computadoras. Haga lo mismo para los sistemas operativos y compá-
relas.
1.7. Describa como funciona un sistema dedicado y un sistema por lotes.
1.8. ¿Qué ventajas y desventajas presentan un sistema dedicado y un sistema por lotes.
1.9. ¿Por qué se crearon los sistemas de entrada salida compartida?
1.10. ¿Qué ventajas proporciona un entorno de tiempo compartido?
1.11. Explique la diferencia entre un sistema de entrada salida compartida y un entorno de

tiempo compartido.
1.12. en la pregunta 2 indicó cinco posibles lugares en donde encontrar un sistema operativo.
Ahora clasifíquelos en las categorías de sistemas dedicados, por lotes, entrada salida
70 1.7. PROBLEMAS
compartida o de tiempo compartido. Si es necesario puede crear otras categorías. Justi-

fique por qué.
1.13. Realice un diagrama que incluya los subsistemas de un sistema operativo. Explique
cada uno de ellos.
1.14. ¿Qué es un archivo?
1.15. ¿Qué es un programa ejecutable?, ¿Qué es un proceso?
1.16. Explique las diferencias entre un archivo ejecutable y un proceso.
1.17. ¿Por qué es necesaria la planificación de los procesos?
1.18. Enumere y explique detalladamente las operaciones que se pueden realizar sobre un
proceso.
1.19. ¿Cuáles son las estrategias de planificación para la CPU? Explíquelas.
1.20. ¿Cómo funciona una memoria?
1.21. Investigue la información técnica de una memoria actual de computadora. Explique las
características más importantes.
1.22. ¿Cuál es la función del administrador de memoria?
1.23. ¿Qué es la memoria virtual?
1.24. ¿Qué es una dirección lógica? y ¿Una dirección física? ¿Por qué es necesario usar
direcciones lógicas?
1.25. Describa las estrategias de administración de memoria.
1.26. ¿Cuál es la función del administrador de dispositivos de entrada salida.
1.27. ¿Por qué es importante que el sistema operativo cuente con un administrador de sistema
de archivos.
1.28. Investigue al menos cinco sistemas de archivos y explique a grandes rasgos el funcio-
namiento de cada uno de ellos.
1.29. Dibuje diagramas para cada tipo de estructura de un sistema operativo. Describa las
ventajas y desventajas de cada uno. Suponiendo que tiene que diseñar un sistema ope-
rativo ¿Qué estructura elegiría y por qué?
1.30. Haga una línea de tiempo del sistema operativo GNU/Linux.
1.31. Explique la diferencia entre GNU y Linux.
1.32. Lea la licencia GPL y haga un resumen usando sus propias palabras.
1.33. Lea el CLUF de algú sistema operativo comercial y haga un resumen usando sus pro-
pias palabras.
1.34. ¿Qué diferencia existe entre los dos?
1.35. ¿Qué es FSF?, ¿Quién la fundó?
1.36. ¿Quién empezó el desarrollo?
1.37. ¿Qué es código abierto?, ¿Qúe es software libre?, ¿Qué diferencia existe entre los dos?
1.38. Enuncie diez de las distribuciones de GNU/Linux y explique brevemente cada una de
ellas.
1.39. Enuncie las fortalezas del sistema operativo Solaris y explique cada una de ellas.
1.40. Investigue la historia de Solaris y haga un resumen con sus propias palabras.
1.41. Describa las ventajas del sistema operativo Mac OS X.
1.42. ¿Cómo se llama el núcleo de Mac OS X?
1.43. Describa los servicios que proporciona Mac OS X.
1.44. Haga una línea de tiempo sobre la historia de Microsoft sobre sus sistemas oeprativos
y explique los momentos que considere más importantes.
1.45. Describa las características más importantes del sistema operativo Windows 2003 Ser-
ver.
1.8. Lecturas adicionales

En Silberchatz[95] podemos encontrar una descripción detallada de los sistemas operativos
más relevantes en la historia de la computación. Deitel [33] es también un clásico cuando se ha-
bla de los conceptos de diseño de un sistema operativo. Tenenbaum [99, 100] ofrece también una
explicación bastante profunda sobre la arquitectura de los sistemas operativos. Tanenbaum[99]
72 1.8. LECTURAS ADICIONALES
ofrece el código fuente de MINIX, un sistema operativo académico en donde se basó Linus Tor-
vals para desarrollar el núcleo de Linux. Milenkovic [94] Ofrece también el código fuente sobre
el diseño de un sistema operativo llamado kmos. Lampson[60] nos habla acerca del sistema
operativo mesa.
Redell[82] describe un sistema operativo para uso personal. Dawson Engler[37] describe una
arquitectura de un sistema operativo para el manejo de recursos a nivel de aplicación. Flynn[40]
ofrece los conceptos principales para el diseño de un sistema operativo rápido.
Oustterhout[79] proporciona un análisis general del sistema operativo distribuido sprite.
Capítulo 2
Administración de procesos y del

procesador
O mo hemos explicado en secciones anteriores, una de las principales tareas de un sistema

C operativo es la de administrar los programas que corren los usuarios, además de hacer
las tareas concernientes a la administración de los recursos del sistema operativo. Los sistemas
operativos antiguos solamente podían correr un solo programa por vez. Cuando el programa
era cargado en memoria, éste tenía todo el control de los recursos de la computadora. Como
los computadoras eran demasiado caras, lo que se necesitaba era aprovechar al máximo su po-
tencia. Los sistemas operativos actuales, pueden multiplexar sus recursos para que puedan ser
usados por distintos usuarios, dándoles la impresión de que estos recursos están dedicados a
ellos, excepto, por ejemplo, cuando usan un dispositivo que es obligatoriamente serial como
una impresora. Existen diferentes términos para designar las capacidades de una computadora
y por ende también de un sistema operativo. en primer lugar, tenemos un sistema monotarea
y monousuario. Quiere decir que, como los sistemas antiguos, solamente soporta un programa
y en consecuencia un solo usuario. De ahí pasamos a los sistemas multiusuario y multitarea.
Un sistema operativo multitarea puede tener trabajando varios programas en memoria al mismo
tiempo. Un sistema multiusuario puede permitir la conexión de varios usuarios a la vez. Un sis-
tema multiusuario implica que realiza multitarea pero un sistema multitarea, no puede implicar
que pueda tener múltiples usuarios.
El siguiente término importante es el de los sistemas de multiprocesamiento. Básicamente
se refiere a un sistema que cuenta con muchos procesadores. Existe la tendencia a confundir
un sistema multitarea con uno de multiprocesamiento, pero la multitarea se puede dar en un
sistema con un solo procesador multiplexando la CPU entre las diferentes tareas. Obviamente
la multitarea también se da en un sistema de multiprocesamiento para aprovechar al máximo a
73
74 2.1. CONCEPTO DE PROCESO
todas las CPU. Por último nos referiremos a los sistemas distribuidos. Un sistema distribuido,
se define como la compartición de tareas entre diferentes computadoras conectadas mediante
una red. Esto es, una red permite compartir recursos, como directorios y archivos, un sistema
distribuido, permite a su vez compartir memoria y procesos o tareas.
2.1. Concepto de proceso

Un programa o proceso necesita recursos para poder ejecutarse en la computadora. El siste-
ma operativo necesita asignarle tiempo de CPU, memoria y oportunidad de realizar sus tareas de
entrada/salida. A la copia del programa que maneja el sistema operativo en memoria se le cono-
ce como proceso o tarea. En lo sucesivo usaremos indistintamente uno u otro nombre. Concepto
de proceso Un proceso es una copia de un programa en memoria. Por lo común, la carga de un
programa de disco para subirlo en memoria es el resultado de la ejecución de una orden dada al
sistema operativo por un usuario, ya sea desde una línea de comandos o a través de una interfaz
gráfica de usuario.
Cuando el sistema operativo recibe la orden, éste crea una estructura de datos que le permite
llevar el control de los recursos asignados al proceso y provee los mecanismos necesarios para
que pueda comunicarse con el. Al momento de creación, el proceso recibe un número que lo
identificará durante toda la vida de éste. Al se le llama PID (Process Identifier). Una vez creado,
el proceso empezará a competir por todos los recursos de la computadora.
Desde el punto de vista del usuario, un proceso es solamente un programa que tiene un
conjunto de instrucciones para realizar una tarea específica. Para el sistema operativo es una
entidad que debe ser planificada y asignada al procesador para su ejecución. De este modo, el
sistema operativo lleva un registro que permite controlar dinámicamente la evolución del proceso
desde su creación hasta la finalización del mismo.
2.2. Estados y transiciones de un proceso.

Un proceso pasa por diferentes estados durante su vida. Un proceso puede estar básicamente
en dos estados: No ejecución y En ejecución.
No ejecución. Cuando un programa se encuentra en este estado, se dice entonces que está espe-
rando la oportunidad de ejecutarse, por lo tanto, no se encuentra en la CPU. Todo proceso
que es creado, empieza en el estado de no ejecución.
En ejecución. Cuando el sistema operativo decide que es tiempo de que un proceso pase a
CAPÍTULO 2. ADMINISTRACIÓN DE PROCESOS Y DEL PROCESADOR 75
ejecución, interrumpe al que se encuentra en la CPU y envía a la CPU otro proceso. La

selección del proceso que pasa a ejecución depende del algoritmo de planificación que
tenga el kernel del sistema operativo. El proceso que pierde el control de la CPU pasa al
estado de no ejecución.
Aunque esta estrategia es muy simple, podemos observar que se necesitan definir varios as-
pectos tales como el tiempo que debe asignarse a cada proceso. qué estrategia debe seguir el
sistema operativo para decidir cual será el siguiente proceso a ejecutarse. En donde se guarda-
rán los datos de los procesos que están ejecutándose en ese momento. Entre otras cuestiones
importantes.
En los sistemas operativos actuales el administrador de CPU interrumpirá al proceso en eje-
cución en intervalos regulares. Si su tiempo no ha concluido, entonces le devuelve nuevamente el
control.de otra forma seleccionará un nuevo proceso de la cola de procesos. La cola de procesos
por lo común es una lista enlazada cuyos nodos representan procesos que deben ser ejecutados.
La estrategia más común es usar la FIFO (First Input Firt Output), esto es, primero en entrar pri-
mero en salir. De acuerdo a esta estrategia, el proceso que llega primero, será el que se atienda
primero. Esto no significa que el proceso deberá continuar hasta que termine su ejecución. Este
se ejecutará hasta que se le agote su tiempo asignado. Cuando se le termine su tiempo -y si to-
davía no termina su tarea- regresará al final de la cola para esperar un nuevo turno de ejecución.
En el momento en que termine su tarea, el proceso será eliminado de memoria y la estructura de
datos que lo representa será eliminado de la cola.
Aunque el modelo de dos estados es conveniente para una aproximación general. Es común
que un proceso aún no se encuentre listo para ejecutarse debido a que está esperando que ter-
mine una operación de entrada/salida. En ese momento sería inútil que el sistema operativo le
concediera su segmento de tiempo, puesto que se lo gastaría esperando. Para evitar este y otros
problemas, se aumentan a cinco los posibles estados de un proceso:
1. Estado nuevo
2. Estado de Listo o Preparado
3. Estado de Ejecución
4. Estado de Bloqueado
5. Estado de Terminado
Explicaremos cada uno de estos estados más detalladamente.

76 2.2. ESTADOS Y TRANSICIONES DE UN PROCESO.
Figura 2.1: Diagrama de estados de un proceso
Estado nuevo. Son aquellos procesos que acaban de ser solicitados para ejecución, pero que
aún el sistema operativo no termina de generar todas las estructuras de datos necesarias
para pasarlos al estado de listos.
Estado de Listo o Preparado. se encuentran en este estado aquellos procesos que tienen todo
lo necesario para ejecutarse o continuar sus tareas en donde las dejaron. solamente esperan
a que les toque su turno de ejecución.
Estado de Ejecución. El proceso que se encuentra en este estado es el que tiene el control del
procesador. Si la arquitectura de la computadora existen muchos procesadores, entonces
es posible que exista más de un proceso en este estado. Por el contrario, si hablamos de
una computadora con un solo procesador, entonces en un momento cualquiera existirá
sólo un proceso en este estado.
Estado de Bloqueado. Se encuentran en este estado aquellos procesos que están esperando
que termine una operación de entrada/salida, que se libere un recurso -a excepción del
procesador- o están esperando una señal externa.
Estado de Terminado. Están es este estado aquellos procesos que han finalizado su tarea o
incurrieron en algún acceso no autorizado o hubo un error irrecuperable y el sistema ope-
rativo los eliminó. También es posible que el padre del proceso haya enviado una señal
de terminación de proceso por que la tarea global ha sido finalizada. Esto significa que
el sistema operativo lo quitará de la lista de ejecución y después que haya obtenido las
estadísticas referentes al proceso, lo eliminará definitivamente de memoria y desasignará

todos los recursos que tenía ese proceso.
Tomando en cuenta estos estados, un proceso puede pasar de uno a otro. A esto le llamamos
transiciones. En la figura 2.1, vemos las transiciones que puede efectuar el proceso. A continua-
ción explicaremos brevemente cada una de ellas:
Transición a Nuevo. El usuario ha solicitado la ejecución de un programa. El sistema operativo

determina la ruta del programa a ejecutar y empieza a construir las estructuras de datos
necesarias para ponerlo en la cola de listos.
Transición de Nuevo a Preparado. Tiene lugar cuando el SO está preparado para admitir un
proceso más y ha terminado de inicializar las estructuras de control necesarias. Se tendrán
en cuenta las restricciones de la capacidad de la memoria, de modo que aquellos proce-
sos que tengan baja prioridad o estén bloqueados se envíen a la memoria virtual en caso
necesario.
Transición Preparado a Ejecución. Esta transición se genera cuando el planificador del siste-
ma operativo ha seleccionado un nuevo proceso para ejecutar y está realizando un cambio
de contexto.
Transición Ejecución a Preparado. Cuando se da esta transición, indica que el segmento de

tiempo asignado al proceso ha finalizado. El sistema operativo realizará otro cambio de
contexto para asignarle la CPU al siguiente proceso en su cola de ejecución. También se
puede dar que un proceso con mayor prioridad haya solicitado su ejecución y en este caso,
el sistema operativo se apropiará de la CPU para cumplir el requerimiento. Otra puede ser
sesión voluntaria del control del procesador al sistema operativo.
Transición Ejecución a Bloqueo. Un proceso pasa a bloqueo cuando ha iniciado una opera-
ción de entrada/salida y ésta es demasiado lenta. También cuando espera una señal exter-
na.
Transición Bloqueado a Preparado. Tiene lugar si a un proceso bloqueado se le concede el

recurso solicitado u ocurre el suceso por el que estaba esperando.
Transición Preparado a Terminado. Esto ocurre cuando un proceso padre ha decidido en un

momento dado finalizar la ejecución de sus procesos hijos. Si algún proceso se encontraba
en estado preparado realizará esta transición. También puede deberse a un requisito de
memoria no autorizado.
Transición Bloqueado a Terminado Un proceso hijo puede hacer esta transición debido a que
el proceso padre envío una señal de terminación a todos sus hijos. Otra causa puede ser
que el proceso supere el tiempo máximo de espera por un recurso y el sistema operativo
decida entonces terminarlo, aunque comúnmente enviará un aviso al usuario del proceso
y que éste decida qué hacer.
Para que el sistema operativo pueda implementar todos estos estados es necesario disponer
de dos colas, una para los procesos preparados y otra para los bloqueados. A medida que se
admiten procesos nuevos en el sistema, éstos se van colocando en la cola de preparados. Cuando
el sistema operativo tiene que elegir un proceso para su ejecución, lo hace sobre esta cola. Si su-
ponemos que no hay una política de prioridades entonces la cola puede administrarse mediante
un algoritmo FIFO como se explicó en 2.2. Cuando el sistema operativo le quita el procesador a
un proceso, puede ser porque ha terminado su ejecución, porque ha excedido el tiempo máximo
asignado. En este caso se va agregar al final de la cola de preparados. En caso de que haya que-
dado bloqueado o a la espera de una señal entonces se agregará al final de la cola de bloqueados.
Cuando tiene lugar una señal todos los procesos que esperaban por ella se envían desde la cola de
bloqueados a la de preparados. Esta última medida significa que cuando se produce un suceso,
el sistema operativo debe recorrer toda la cola de procesos bloqueados buscando aquellos que
esperen por la señal. En un sistema operativo grande puede haber una gran cantidad de proce-
sos en la cola de bloqueados, por consiguiente, resultaría más eficiente disponer de un conjunto
de colas, una para cada señal o suceso. De esta forma, cuando se produzca un evento, la lista
entera de procesos en la cola correspondiente a ese suceso podrá pasarse a estado preparado. Si
la planificación de procesos se realiza mediante un esquema basado en prioridades, entonces es
conveniente tener un cierto número de colas de procesos listos, una para cada prioridad.
2.2.1. El Estado de Suspendido

Debido a que el procesador es mucho más rápido que los dispositivos de E/S puede ocurrir
que en un momento dado todos los procesos del sistema se encuentren bloqueados a la espera de
que se complete alguna operación de E/S. Para solucionar este problema existen dos opciones:
1.Instalar más memoria principal al sistema de modo que sea posible cargar más procesos y
aumentar la posibilidad de usar más efectivamente el procesador.
2. Otra solución consiste en aplicar una técnica conocida como intercambio o swapping.
Esta técnica consiste en que si varios procesos están bloqueados, el sistema operativo puede
sacarlos de su correspondiente cola y guardarlo en la partición de intercambio. El proceso trans-
ferido se dice entonces que queda en estado suspendido. Una vez realizada esta operación, se
libera memoria y el sistema operativo puede traer de nuevo a memoria a un proceso previamente
suspendido o bien aceptar un nuevo proceso. Se considera suspendido a un proceso que presenta
las siguientes características:
1. Un proceso suspendido se encuentra en la memoria virtual y debe ser cargado para su

ejecución.
2. Un proceso puede estar esperando o no una señal o la terminación de su E/S. Si lo está,

la condición desbloqueado es independiente de la condición de suspendido y el aconteci-
miento del suceso que lo bloqueó no necesariamente lo pondrá en estado de ejecución.
3. El proceso fue situado en estado suspendido por el sistema operativo o el proceso padre
con el fin de que no se ejecute por alguna razón.
4. El proceso no puede cambiarse de estado hasta que se envíe la señal correspondiente.
2.2.2. El bloque de control de procesos

Para que el sistema operativo pueda llevar el control durante la vida de un proceso, es nece-
sario contar con mucha información. esta información se almacena en el bloque de control de
procesos denominado como PCB (Process Control Block). Dentro de los datos más importantes
del proceso tenemos los siguientes:
Contador de Programa PC. El contador de programa guarda la dirección de la siguiente ins-

trucción a ejecutar del proceso.
Estado del proceso. Puede ser cualquiera de los que analizamos en 2.2.
Información de planeación del CPU. Incluye la prioridad del proceso, los apuntadores a las
colas de planificación y otra información necesaria.
Registros de la CPU. Es necesario guardar una copia exacta del estado en que quedaron los
registros para asegurar que el proceso pueda continuar en el punto en que se suspendió su
ejecución.
Información estadística. Permite al sistema operativo ir contabilizando el tiempo de ejecución

en la CPU, PID del proceso, tiempo en el sistema y otra información relacionada.
Información de la administración de memoria. Almacena la información correspondiente al

uso de la memoria del proceso. Puede incluir registro base y límite, las tablas de páginas
o las tablas de segmentos. Esta información depende del mecanismo de administración de
memoria que se use.
Información de estado de E/S. El sistema operativo guarda una lista de dispositivos usados
por el proceso, una lista de archivos el estado en que se encuentran.
En resumen, en PCB es una estructura que permite guardar toda la información relativa
al proceso y que cambia durante la ejecución del mismo. Es importante hacer notar que aquí
se guarda la información para que el proceso, al momento de tomar nuevamente el control,
empiece a ejecutarse exactamente donde se quedó, independientemente de la operación que
estaba realizando.
2.2.2.1. Relaciones entre procesos
Podemos encontrar dos relaciones básicas entre dos procesos:
Competición
cooperación
Dado que ambos procesos están ejecutándose en la misma CPU o en diferentes CPU, éstos van
a competir por los demás recursos de la computadora. También es posible que se dé la condición
de cooperación entre dos o más procesos para que lleven a cabo una tarea más eficientemente.
Tanto la competición como la cooperación requieren que el sistema operativo proporcione un
soporte conveniente de modo que exista el aislamiento adecuado cuando un proceso acceda a
un recurso -como por ejemplo, su espacio de direcciones- y pueda terminar su tarea con éxito.
La cooperación exige que el sistema operativo proporcione mecanismos de acceso controlado
a los datos y archivos compartidos para asegurar adecuadamente las operaciones atómicas del
proceso, ya sea mediante señales o algún otro mecanismo de sincronización.
2.2.2.2. Operaciones sobre los procesos
En los sistemas operativos actuales es común que los procesos puedan ejecutarse concurren-
temente y también crearlos y eliminarlos dinámicamente.
creación de procesos. Para crear un proceso en un sistema UNIX/Linux, En el programa de

la página 80 se hace uso de la instrucción fork()
switch (fork())
{
case -1:
/* Aquí insertamos el código para manejar el
error de no poder crear un nuevo proceso */

...
break;
case 0:
/* Código que ejecuta el proceso hijo */
...
break;
default:
...
/* Código el proceso padre */
}
Puede usarse también condicionales de esta forma:
pid=fork()
if (pid==0)
{ /* Aquí va el código del hijo*/}
else if pid > 0
{ /*Aquí va el código del padre*/}
else
{/*Aquí se maneja el error en caso de que
falle la creación del proceso*/
}
Hay que observar que incluso los procesos hijos pueden crear nuevos procesos, lo que signi-
fica que al final tendremos un árbol de procesos.
Para que podamos ver los procesos que actualmente se están ejecutando en la computadora
tenemos la instrucción ps en los sistemas UNIX/Linux en los sistemas de Windows tenemos
el administrador de tareas, el cual también indica cuanto tiempo de CPU está consumiendo
un proceso y la memoria que tiene ocupada. Para ver el consumo de recursos en UNIX/Linux
usamos el comando top.
Cuando un proceso crea uno nuevo puede darse cualquiera de los acontecimientos siguientes:
1. El padre continúa ejecutándose paralelamente junto con el hijo.
2. El padre espera a que los hijos terminen las tareas asignadas, para después seguir ejecu-
tándose.
También al momento de crear un proceso puede suceder que:

1. El hijo sea una copia exacta de padre, incluyendo código y datos.
2. el hijo cargue un nuevo programa mediante una llamada a exec() o alguna de sus variantes.
Eliminación de procesos. Un proceso termina cuando ejecuta su última instrucción y pide al

sistema operativo que lo elimine. Cuando el sistema operativo termina el proceso libera todos
los recursos asignados al mismo, cierra los archivos que utilizó, los búferes asociados a éstos y
la memoria física y virtual entre otros.
Existen diferentes maneras de eliminar un proceso del sistema. A continuación explicamos
cuales son éstas.
1. El proceso hace una llamada a la función exit() para indicarle al sistema operativo que
terminó sus tareas y que puede ser eliminado, regresando al padre un código de éxito o
error.
2. El proceso padre envía una señal KILL (morir) al proceso hijo para que termine su ejecu-
ción.
3. El sistema operativo envía una señal KILL al proceso a causa de un acceso (a un bloque
de direcciones -por ejemplo-) no autorizado o algún otro evento.
4. El usuario dueño del proceso envía una señal al proceso mediante la función kill() o si el
proceso tiene asociado una terminal presionando ctrl-c o ctrl-break
5. El super usuario o el administrador del sistema envía una señal al proceso mediante la
función kill() o si el proceso tiene asociado una terminal presionando ctrl-c o ctrl-break
2.3. Procesos ligeros: Hilos o hebras

Ya vimos que un proceso es una instancia de un programa en ejecución. hay ocasiones en
que es necesario, crear nuevos procesos para que hagamos alguna tarea más eficientemente. Para
crear un nuevo proceso hacemos uso de una llamada a una instrucción especial llamada fork()
como se vio en la sección 2.2.2.2. Al momento de ejecutar esta instrucción el sistema operativo
creará una copia idéntica del programa que se encuentra en memoria, le asignará su PCB y todas
las acciones referentes a la creación de un proceso. Ahora, al proceso que invocó la llamada
fork() se le denominará proceso padre y al nuevo proceso, se le llama proceso hijo. El proceso
hijo ha adquirido una copia completa de los datos del padre y además tiene los mismos permisos
sobre los archivos que maneja el padre. Ahora tanto el proceso padre como el hijo competirán
por los recursos de la computadora y se comunicarán de alguna manera para no acceder a los
mismos archivos al mismo tiempo.
La principal desventaja es que tenemos código duplicado, a no ser el proceso haga inmedia-
tamente una llamada a exec(), de tal forma que ahora el sistema operativo reemplazará todo el
código y los datos del proceso hijo con la nueva información del proceso que se cargó. Aún así
este proceso es demasiado lento debido a que se tiene interacción con la memoria secundaria.
Como es posible que el sistema se sobre cargue a causa del código y datos duplicados existe una
alternativa más viable para cuando un proceso necesite ejecutar una tarea que es susceptible de
separar del programa principal. A esta alternativa se le conoce como hilo.
Un hilo o hebra es una unidad básica para hacer uso de la CPU, comprende dentro de su
estructura un PID de hilo, el contador de programa, un conjunto de registros y una pila. La
primera ventaja con respecto a un proceso hijo es que todos los hilos pertenecientes a un proceso
comparten la sección de código, la sección de datos, los archivos abiertos y las señales.
Desde este punto de vista, cuando el sistema operativo crea un nuevo hilo, necesita solamente
crear un PCB correspondiente a la misma, no necesita hacer la copia completa del proceso, por
lo que es mucho más rápido y eficiente crear un hilo que un proceso.
Un proceso lleva a cabo su ejecución siguiendo solamente un hilo de ejecución y aunque
existan varios procesos cada uno seguirá cada uno llevando sólo un hilo de ejecución debido
a sus características inherentes de no compartir su código y sus datos. Con la implementación
de hilos, en la actualidad la mayoría de los sistemas operativos permiten que un proceso tenga
muchos hilos de control.
Vamos a poner un ejemplo: cuando en un sistema multitarea se hacía una solicitud de servicio
el proceso encargado de proporcionarlo creaba una copia de sí mismo mediante la llamada a
fork() y el hijo creado era el que realmente proporcionaba el servicio repitiéndose este proceso
por cada solicitud que llegara.
84 2.3. PROCESOS LIGEROS: HILOS O HEBRAS
Como podemos observar cada proceso hace exactamente el mismo trabajo: atender una so-
licitud del mismo tipo de servicio. Sin embargo por cada solicitud se crea un nuevo proceso con
código y datos. No tiene sentido tener todo ese código duplicado si solamente cambia el valor
de algunas variables de los datos. Además hay que contar la sobrecarga del sistema debido a la
tarea de copiar todo el contexto del proceso.
En la actualidad la mayoría de las aplicaciones están usando los hilos en vez de procesos.
Como se comentó tienen más ventajas que los procesos tradicionales.
incluso varios de los sistemas operativos actuales usan kernels multi hilo; esto significa que
existen varios hilos ejecutando tareas específicas como la administración de memoria y la admi-
nistración de los dispositivos de entrada salida.
2.3.1. Ventajas de la programación multi hilo

Podemos dividir las ventajas de la programación con hilos en:
Economía. Hacer un cambio de contexto de un hilo es mucho más rápido que hacer el cambio
de contexto de un proceso.
Aumento en la capacidad de respuesta. Si hacemos uso de varios hilos en una aplicación in-
teractiva, podemos lograr que nuestra aplicación siga respondiendo a nuestro usuario,
puesto que si se hace una tarea muy larga, como una búsqueda, los hilos encargados de la
interfaz gráfica podrán estar trabajando para procesar entradas del usuario.
Recursos compartidos. Los hilos comparten tanto el código, como los datos del proceso que
los creó, si necesitan información local pueden pedirla independientemente del proceso
padre.
Soporte de multiproceso. Es posible ejecutar paralelamente los hilos en un sistema multipro-

cesador, aumentando significativamente la velocidad.
2.3.2. Implementación de hilos en GNU/Linux

GNU/Linux cuenta con una librería denominada Pthreads. Está basado en el estándar PO-
SIX en donde describen la especificación para el comportamiento de los hilos. Entiéndase por
especificación la manera en la cual deben comportarse las funciones dadas. A diferencia de una
implementación la cual está sujeta al diseño particular de cada desarrollador. A continuación se
muestra un programa que utiliza la librería antes mencionada.
#include <pthread.h>
//
/* Función que va a ejecutar el hilo
correspondiente al hijo */
void *hilo(void *nollevonada);
/* Contadorcomun, global para que sea visible
desde el principal y desde hilo */
int contadorcomun = 0;
int veceshilo=0;
int vecespadre=0;
int main()
{
/* Identificador del hilo hijo */
pthread_t Hilo;
/* error devuelto por la función de
creación del hilo */
int error;
/* se crea el hilo.
* En Hilo tendremos el PID del nuevo hilo,
* Pasamos la función que se ejecutará en el nuevo hilo
* Pasamos NULL como parámetro para esa función de manera
que obtenga los valores por defecto. */
//
error = pthread_create (&Hilo, NULL, hilo, NULL);
//
/* Comprobamos el error al arrancar el hilo */
if (error != 0)
{
perror ("No puedo crear el hilo");
exit (-1);
}
/* Bucle infinito para incrementar el contador
y mostrarlo en pantalla */
while (1)
{
contadorcomun++;
vecespadre++;
printf("Padre : %d veces %d\n", contadorcomun, vecespadre);
86 2.3. PROCESOS LIGEROS: HILOS O HEBRAS
if (vecespadre>10000)
break;
}
if vecespadre>veceshijo
printf("Terminó primero el padre");
else
printf("Terminó primero el hijo");
return(0);
}
/* Función ejecutándose en el hilo hijo.*/
void *hilo(void *nollevonada)
{
/* Bucle infinito para decrementar contador
y mostrarlo en pantalla. */
while (1)
{
contadorcomun--;
veceshijo++;
printf ("Hilo : %d veces %d\n", contadorcomun,veceshijo);
if (veceshijo>10000)
break;
}
pthread_exit(0);
}
Observe que para terminar el hilo se usa la llamada a función ptrhead_exit() con un valor de 0
que indica que no hubo problemas en la ejecución. Cuando es necesario esperar a que termine
la ejecución de una o más hilos entonces el padre usará la llamada a función pthread_join().
2.3.3. Consideraciones finales

Algunos sistemas UNIX implementan dos llamadas a fork(), dependiendo de la función que
se desee realizar dentro de un hilo, una función puede ser duplicar el proceso padre y todos
los hilos o solamente el hilo que llamó a fork(). También cuando se usa exec() se llamará
una versión o la otra. Si exec se llama inmediatamente después de fork(), no hay necesidad de
duplicar los hilos, por que el programa que se cargará sobre escribirá toda el área de código y
datos.
2.3.3.1. Eliminación de hilos
es la acción de eliminar de memoria un hilo que aún no termina su ejecución. Esto es ne-
cesario por que hay ocasiones en que, por ejemplo si tenemos una búsqueda concurrente sobre
una base de datos y se lanzaron varios hilos, cada uno de ellos con una parte de la misma, al-
guno encontrará primero los datos y entonces no será necesario que las demás sigan haciendo la
búsqueda y habrá que eliminarlas.
El problema de la cancelación viene a que, al igual que los procesos, no existe garantía total
de que los recursos regresen al sistema. Por ejemplo, cuando un proceso o un hilo pidieron
memoria dinámicamente. Esta memoria no se regresará hasta que no la devuelva explícitamente
el hilo o proceso que la solicitó, generando lo que se conoce como fuga de memoria, un problema
que debe tratarse con mucho cuidado en la programación con lenguaje C. La eliminación del hilo
puede hacerse de dos formas:
1. Asíncrona. El hilo puede terminarse inmediatamente por el proceso que la creó.
2. Síncrona. El proceso que creó el hilo, verifica si es posible terminarlo, si no, espera y
vuelve a repetir el proceso, dando oportunidad al hilo de terminar adecuadamente.
2.4. Concurrencia y secuenciabilidad

En la sección 2.1 hemos hablado de cómo es que es sistema operativo puede controlar mu-
chos procesos ejecutándose en la misma computadora. Cuando hay varios procesos compitiendo
por los mismos recursos, y dado el caso de que dos o más procesos quieran acceder al mismo
recurso en el mismo instante de tiempo, entonces decimos que tenemos un caso de concurrencia.
Esto es, varios procesos concurren por un recurso al mismo tiempo. si hablamos de computado-
ras con un solo procesador, se puede argumentar que los procesos siempre corren solos sobre
un recurso, pero hay que recordar que por lo común la mayoría de los recursos son decenas o
centenas de veces más lentos que el procesador. Esto indica que existen muchísimas posibili-
dades de que el tiempo asignado al proceso termine mucho antes de que algún dispositivo de
entrada/salida, como un disco duro, por ejemplo, haya terminado su operación correspondiente.
Esto significa que otro proceso que tenga que trabajar sobre el mismo registro almacenado en el
disco duro lo vea desocupado en el momento siguiente, aunque el proceso que ocupó ese regis-
tro no haya terminado de hacer su operación y ya no se ejecute en ese momento. Como puede
verse el segundo proceso trabajará sobre datos no válidos puesto que se encontraban, tal vez en
un proceso de actualización.
88 2.4. CONCURRENCIA Y SECUENCIABILIDAD
Con la memoria sucede un caso similar, si dos procesos tienen acceso a un área de memoria
común, deben de ponerse de acuerdo en la forma de acceder a ésta, tanto para la lectura como
para la escritura. Ambos procesos deben de acceder al recurso en instantes diferentes de tiempo
y además deben de ser capaces de terminar la operación que empezaron. de otro modo, los datos
de esa área de memoria pueden corromperse, cuando los procesos sobre escriban información
que corresponde a cada uno de ellos.
2.4.1. Definiciones
Concurrencia es cuando dos o más procesos quieren acceder a un recurso al mismo tiem-
po. El sistema operativo debe garantizar la integridad de la información, haciendo que entren al
recurso proceso por proceso y garantizar también que terminen de hacer las operaciones sobre
el recurso correspondientes. A lo anterior le llamamos exclusión mutua. La exclusión mutua,
por tanto, es hacer que un proceso ejecute sus operaciones de entrada salida sobre su recurso sin
que entre otro proceso en ese instante. A este conjunto de operaciones les llamaremos sección
crítica, por que si llega a suceder alguna intromisión puede que haya corrupción de datos. La
inanición se da cuando un proceso no puede ejecutar jamás su sección crítica, casi siempre indi-
ca que el algoritmo de exclusión mutua no garantiza que todos los procesos ejecuten su sección
crítica de una forma cíclica. tenemos una condición de carrera cuando dos o más procesos ob-
servan que el recurso está desocupado y tienden a reservarlo y puede suceder entonces que estos
procesos obtengan el derecho a ejecutar su sección crítica, con resultados desastrosos. Por últi-
mo, la sincronización es el mecanismo que usan los procesos para poder entrar ordenadamente
a un recurso compartido.
El sistema operativo es el encargado de proporcionar los medios adecuados para permitir
la concurrencia y también de proporcionar las llamadas de sistema convenientes para que los
procesos puedan hacer uso de ellas y lograr la exclusión mutua y la sincronización. A veces
se le deja esta tarea al programador, pero solamente el sistema operativo es el único capaz de
administrar los accesos de los procesos a los recursos a bajo nivel y hacerla de árbitro, para
indicar a qué proceso le corresponde acceder en su momento a los datos. En el programa de la
página 84, el proceso principal suma uno y el hilo lo resta ¿ Qué pasaría si el padre tuviera que
realizar operaciones adicionales con ese número ? es obvio que los resultados estarían alterados
por que ambos escriben sobre la variable en el momento en que les toca ejecutarse, sin saber si
otro proceso está usando esa variable.
2.4.2. Principios generales de la concurrencia

La concurrencia es fundamental en áreas tales como el diseño de programas, tanto de sis-
temas como de aplicaciones y para el desarrollo de sistemas operativos. La concurrencia com-
prende un gran número de cuestiones de diseño, incluida la comunicación entre procesos, com-
partición y competencia por los recursos, sincronización de la ejecución de varios procesos y
asignación del tiempo de procesador a los procesos. Se verá que estas cuestiones no solo surgen
en entornos de multiprocesadores y proceso distribuido, sino incluso en sistemas multiprogra-
mados con un solo procesador.
La concurrencia puede presentarse en tres contextos distintos:
Múltiples aplicaciones. La multitarea se desarrolló para permitir que el tiempo de CPU de la
computadora fuese compartido dinámicamente entre varias aplicaciones activas.
Aplicaciones estructuradas. Como ampliación de los principios del diseño modular y la pro-
gramación orientada a objetos, algunas aplicaciones pueden implementarse eficazmente
como un conjunto de procesos concurrentes o un conjunto de hilos.
Sistemas operativos. Las mismas ventajas se aplican a los programadores de sistemas. Incluso
algunos sistemas operativos están implementados como un conjunto de procesos o hilos.
En un sistema multitarea con una CPU, los procesos se intercalan en el tiempo aparentando una
ejecución simultánea. Aunque no se logra un procesamiento paralelo y produce una sobrecarga
en los intercambios de procesos, la ejecución intercalada produce beneficios en la eficiencia de
la ejecución y en el desarrollo de programas basados en hilos o procesos, esto es, a medida que
crean más procesos o hilos pueden terminar más rápidamente su tarea. Si se hace uso de una
computadora con múltiples procesadores, el sistema operativo tendrá la posibilidad de asignar
cada proceso o hilo a otro procesador, sin hacer cambio alguno en la aplicación.
La intercalación y la superposición pueden contemplarse como ejemplos de procesamiento
concurrente en un sistema monoprocesador, los problemas son consecuencia de la velocidad
de ejecución de los procesos que no pueden predecirse y depende de las actividades de otros
procesos, de la forma en que el sistema operativo trata las interrupciones surgen las siguientes
dificultades:
1. Compartir recursos globales es riesgoso.
2. Para el sistema operativo es difícil administrar la asignación óptima de recursos.

Las dificultades anteriores también se presentan en los sistemas multiprocesador. El hecho
de compartir recursos ocasiona problemas, por esto es necesario proteger a dichos recursos. Los
problemas de concurrencia se producen incluso cuando hay un único procesador.
2.4.3. La sección crítica

Sea un sistema que consta de n procesos {PO , P1 , P2 , ..., Pn−1 } cada proceso tiene un frag-
mento de código que se denomina sección crítica. Esta sección de código podemos identificarla
fácilmente por que será aquella parte del proceso que modifique datos, registros o archivos que
estén compartidos con otros procesos. La característica especial que tiene es que cuando un pro-
ceso esté ejecutando su sección crítica, no puede ser interrumpido por otros procesos, o en otras
palabras, dos procesos no pueden ejecutar su sección crítica en el mismo instante. Entonces el
problema de la sección crítica consiste en diseñar un conjunto de protocolos que ayuden a los
procesos a llevar a cabo su tareas en las cuales haya recursos compartidos. Así, cada proceso
debe solicitar permiso, al sistema operativo o a los demás procesos para poder acceder al recur-
so, asegurándose de esta forma que será el único en ese momento. Ya que tiene el acceso, debe
bloquear la entrada a los demás procesos, de modo que no puedan interrumpirlo. Al terminar de
usar el recurso compartido debe de desbloquearlo para que puedan acceder los demás procesos
al mismo.
Se han desarrollado diversos algoritmos para afrontar la ejecución de la sección crítica. Para
que una solución sea adecuada, debe cumplir al menos los siguientes puntos:
1. Asegurar la ejecución de una sola sección crítica excluyendo a los demás el acceso al
recurso compartido.
2. No se deben hacerse suposiciones en lo que respecta a las velocidades de ejecución y

prioridades de los procesos que comparten datos, archivos o dispositivos.
3. Garantizar que la terminación anormal de un proceso fuera de su sección crítica, no afecte

el funcionamiento de los demás procesos al acceder a su sección crítica.
4. Cuando dos o más procesos desean ejecutar su sección crítica, se les debe proporcionar el
acceso a cada uno de ellos en un tiempo finito.
2.4.4. Exclusión mutua; solución por hardware y software

La exclusión mutua es asegurar que solamente un proceso esté ejecutando su sección crítica
y que los demás procesos no puedan interrumpirlo. Existen dos enfoques para asegurar la ex-
clusión mutua, el primero depende de que el hardware tenga los mecanismos adecuados para
hacerlo. Lo más común es que el diseñador del microprocesador incluya algunas instrucciones
especiales para permitir operaciones atómicas sobre las variables en memoria y éste se encargará
de determinar quien modifica en primer lugar la variable y así permitir el acceso a la misma en
un orden dado. También en sistemas mono procesador el hardware utiliza interrupciones. Si se
proporciona un medio a los procesos para poder deshabilitarlas puede conseguirse la exclusión
mutua, aunque puede ocasionar muchos problemas. El segundo enfoque consiste en el diseño y
utilización de algoritmos de software que permitan la sincronización y garanticen la ejecución
exclusiva para cada proceso de su sección crítica.
2.4.4.1. Inhabilitación de interrupciones
En una máquina monoprocesador, la ejecución de procesos concurrentes no puede superpo-

nerse. los procesos solo pueden intercalarse. Es más, un proceso continuará ejecutándose hasta
que solicite un servicio el sistema operativo o hasta que sea interrumpido. Por lo tanto, para
garantizar la exclusión mutua, es suficiente con impedir que un proceso sea interrumpido. Esta
capacidad puede ofrecerse en forma de primitivas definidas por el núcleo del sistema para ha-
bilitar o inhabilitar las interrupciones. Un proceso puede hacer cumplir la exclusión mutua del
siguiente modo:
While (cierto)
{
/*inhabilitar interrupciones */;
/* sección crítica */;
/* habilitar interrupciones */;
/* resto */;
}
Puesto que la sección crítica no puede ser interrumpida, la exclusión mutua está garantizada. Sin
embargo, el precio de esta solución es alto. La eficiencia de la ejecución puede verse notable-
mente degradada debido a que se limita la capacidad del procesador para intercalar programas.
Un segundo problema es que esta técnica no funciona en arquitecturas de multiprocesador. Cuan-
do el sistema tenga más de un procesador, es posible (y habitual) que haya más de un proceso
ejecutándose al mismo tiempo. En este caso, inhabilitar las interrupciones no garantiza la exclu-
sión mutua. Hay que agregar que si el reloj se actualiza mediante interrupciones el inhabilitarlas
puede ocasionar un mal funcionamiento del mismo.
2.4.4.2. Instrucciones especiales de hardware
En configuraciones multiprocesador, varios procesadores comparten el acceso a una memo-

ria principal común. En este caso, no hay relación maestro/esclavo, sino que los procesadores
funcionan independientemente en una relación de igualdad. No hay un mecanismo de interrup-
ciones entre los procesadores en el que se pueda basar la exclusión mutua.
A nivel de hardware, como se ha mencionado, los accesos a posiciones de memoria exclu-

yen cualquier otro acceso a la misma posición. Con esta base, los diseñadores han propuesto
varias instrucciones de máquina que realizan dos acciones atómicamente, tales cono leer y es-
cribir o leer y examinar, sobre una misma posición de memoria en un único ciclo de lectura de
instrucción.
Puesto que estas acciones se realizan en un único ciclo de instrucción, no están sujetas a ser
interrumpidas por parte de otras instrucciones.
-La instrucción comparar y fijar (TS, Test and Set) se puede definir de la forma siguiente:
boolean testset(int &i)

{
if (!i)
{
i=1;
return verdadero;
}
else
{
return falso;
}
}
La instrucción examina el valor de su argumento i. Si el valor es 0 , lo cambia por 1 y devuelve

verdadero. En otro caso, el valor no se modifica y se devuelve falso. La función Comparar y Fijar
se ejecuta atómicamente en su totalidad, esto es, no está sujeta a interrupciones. Si estamos en
un ambiente multiproceso y dos o más procesadores intentan ejecutar al mismo tiempo esta fun-
ción entonces se ordenarán aleatoriamente y se ejecutarán secuencialmente en sus procesadores
respectivos.
La instrucción intercambiar se puede definir como sigue:
void intercambiar (int registro, int memoria)

{
int aux;
aux = memoria;
memoria = registro;
registro = aux;
}
Esta instrucción intercambia el contenido de un registro con el de una posición de memo-

ria. Durante la ejecución de la instrucción, se bloquea el acceso a la posición de memoria de
cualquier otra instrucción que haga referencia a la misma posición.
Enseguida analizaremos los algoritmos correspondientes a estas instrucciones. El siguiente
listado muestra un algoritmo clásico sobre el uso de cerrojos para solucionar el problema de la
sección crítica.
/* programa que intenta resolver el

problema de exclusión mutua
*/
int n = /*numero procesos*/
int cerrojo;
void P(int i) {
while (true) {
/* cerrojo esla variable que indica si
pueden entrar a su sección crítica.
*/
while (!testset(cerrojo)) {
/* Esperando .... */
}
/*sección crítica*/
cerrojo = 0;
/*demás código aquí*/
}
}
int main() {
cerrojo = 0;
/*Iniciamos n procesos en paralelo*/
parallelbegin(P(1),P(2) ... P(n));
return 0; /*regresa el control al S. O.*/
}
Cuando se inicia el programa, se da un valor inicial al cerrojo = 0. El único proceso que puede
ingresar a la sección crítica es aquel que encuentre el cerrojo en 0. Todos los demás procesos
están en espera en el ciclo while. Cuando el proceso termine la sección crítica, abre nuevamente
el cerrojo haciendo cerrojo = 0. El primer proceso que ejecute testset será el que ejecute la
sección crítica. En el siguiente programa vemos el uso de la función intercambiar.
/* exclusion mutua con función intercambiar*/

int n = /*numero procesos*/
int cerrojo;
void P(int i) {
int clave;
while (true) {
clave = 1;
while (clave!=0) {
exchange(clave,cerrojo);
}
/*Código de sección critica*/
intercambiar(clave,cerrojo);
/*Demás código Aquí*/
}
}
int main() {
cerrojo = 0;
return 0,
}
El programa principal comienza con una variable compartida cerrojo = 0. Cada proceso tiene una
variable local iniciada en 1. clave = 1. El único proceso que puede entrar a la sección crítica es el
que encuentre el cerrojo abierto en 0; colocándolo en 1 (cerrado). Cuando un proceso abandona
la sección crítica, vuelve a abrir el cerrojo colocándolo en cero.
2.4.4.3. Propiedades de las soluciones con instrucciones de máquina
El uso de instrucciones especiales de la máquina para cumplir con la exclusión mutua tiene
varias ventajas:
Es aplicable a cualquier número de procesos en sistemas con memoria compartida, tanto

de monoprocesador como de multiprocesador.
Es simple y fácil de verificar.
Puede usarse para disponer de varias secciones críticas; cada sección crítica puede defi-
nirse con su propia variable.
Algunas desventajas importantes son las siguientes:
Se emplea espera activa. Así pues, mientras un proceso está esperando para acceder a la sec-
ción crítica, continúa consumiendo tiempo del procesador.
Puede producirse inanición. Cuando un proceso abandona la sección crítica y hay más de un
proceso esperando, la selección es arbitraria. Así pues se podría denegar el acceso a algún
proceso indefinidamente.
Puede producirse interbloqueo. Suponiendo la siguiente escena en un sistema monoprocesa-

dor. El proceso P1 ejecuta una instrucción especial (sea testset o intercambiar) y entra su
sección crítica. Se interrumpe a P1 para dar el procesador a P2 , que tiene mayor prioridad.
Si P2 intenta ahora usar el mismo recurso que P1 , se le negará el acceso por el mecanismo
de exclusión mutua. De este modo, P2 entrará en un bucle de espera activa. Sin embargo,
P1 nunca será ejecutado porque su prioridad es menor que la del proceso listo P2 .
2.4.5. Semáforos
Dentro de las soluciones de software tenemos a los semáforos. Un semáforo es un tipo de
datos abstracto que proporciona la capacidad de hacer uso de un recurso de manera exclusiva
cuando varios procesos están compitiendo por éste.
El semáforo cumple la siguiente semántica:
1. El estado interno del semáforo lleva la cuenta de cuántos procesos pueden utilizar el re-
curso. Se puede implementar, por ejemplo, con un número entero que nunca llega a ser
negativo.
2. Existen tres operaciones con un semáforo:
init(). Inicializa el semáforo antes de que cualquier proceso haya ejecutado una operación
wait() ni una operación signal() al número número de procesos que tengan derecho
a acceder el recurso. Si se inicializa con 1, tenemos entonces un semáforo binario.
wait(). Si el estado indica cero, el proceso queda suspendido por el semáforo hasta que sea
despertado por otro proceso. Si el estado indica que un proceso más puede acceder
el recurso se decrementa el contador y la operación termina con éxito.
signal(). Una vez se ha terminado el uso del recurso, el proceso se lo indica al semáforo
con esta instrucción. Si hay algún proceso bloqueado en el semáforo entonces uno
de éstos se pasará al estado de listo, de otra forma se incrementa el contador.
La operación wait() debe ser implementada como una instrucción atómica. No obstante, en
muchas implementaciones se puede interrumpir. Normalmente existe una forma de comprobar
si la salida del wait() es debido a una interrupción o porque se ha dado acceso al semáforo. La
operación signal() también tiene que ser implementada como instrucción atómica. En ciertas
implementaciones se puede comprobar si se ha despertado un proceso con éxito en caso que
hubiera alguno bloqueado.
Para despertar los procesos se puede implementar varias formas que se distinguen , por
ejemplo con un simple sistema tipo FIFO.
El acceso a regiones críticas puede hacerse con un semáforo que permita el acceso a un sólo
proceso.
En la sección 2.2 hablamos sobre los estados en los que puede estar un proceso. Para evitar
que un proceso consuma tiempo de CPU es necesario crear un nuevo estado, se denomina estado
en espera. De esta forma, dos o más procesos pueden cooperar mediante señales de forma que
pueda obligar a detenerse a un proceso hasta que reciba una señal para que continúe. Así es
posible lograr que se comuniquen varios procesos de modo que todos ellos puedan acceder a
su sección crítica en un momento dado. Para lograr esto se usa una variable llamada semáforo
para intercambiar señales. Si un proceso está en espera de una señal, se suspende hasta que la
señal sea enviada por otro proceso. Como se mencionó wait() y signal() son operaciones que
no pueden interrumpirse. El semáforo mantiene una cola de procesos en espera. La manera en
que los procesos salen de la cola en espera es mediante una política primero en entrar, primero
en salir. En la figura 2.2 tenemos el diagrama de estados de los procesos incluido el estado de
espera.
A continuación tenemos los algoritmos y las estructuras que se usan para construir un semá-
foro binario.
struct semaforo_binario {
enum(zero,one) value;
queueType queue;
};
void waitB(semaforo_binario s)
{
if (s.value == 1)
s.value=0;
else {
/*colocar este proceso P
en la cola s.queue*/
/*bloquear el proceso*/
}
}
void signalB(semaforo_binario s)
{
if (s.queue.is_empty())
s.value=1;
else {
/*remover el proceso P
de la cola s.queue*/
/*colocar el proceso P
como listo para ejecucion*/
}
}
Figura 2.2: Los estados de un proceso más el estado de espera

2.4.5.1. Algoritmo para un semáforo binario
Un semáforo, como se mencionó, cuenta en su estructura con una cola de procesos que
esperan que el semáforo les dé el paso libre. En la operación wait(s), si el semáforo está libre
(valor 1), cierra el paso (valor 0). En la operación wait(s), si el semáforo cierra el paso (valor
0), coloca el proceso en la cola de espera de este semáforo. En la operación signal(s), si la cola
de espera está vacía, el semáforo se coloca como libre (valor 1) En la operación signal(s), si
la cola de espera no esta vacía, el primer proceso de la cola en espera se coloca en la cola de
preparados, listos para que el planificador de procesos lo lleve al CPU para su ejecución. En el
siguiente listado tenemos un programa ejemplo de la utilización de un semáforo binario.
El funcionamiento general de un semáforo es el siguiente: Sean n procesos en el vector
P(i), en cada proceso se ejecuta un wait(s) antes de la ejecución de la sección crítica. El primer
proceso que cambie el semáforo lo hará del valor 1 al valor 0, cerrando el paso, los demás
procesos que encuentren el semáforo cerrado (valor 0) se encontrarán en la cola de espera de
este semáforo. Una vez que el primer semáforo termine la sección crítica, ejecutará un signal(s)
que colocará el valor del semáforo en 1 y que habilitará para su ejecución al siguiente proceso
de la cola de espera del semáforo.
El algoritmo quedaría así:
/* programa de exclusión mutua usando un semáforo*/

int n = /*número procesos*/
semaforo s=1;
void P(int i) {
while (true) {
wait(s);
/*seccion crítica*/
signal(s);
/*código restante*/
}
}
int main() {
}
Observamos los siguiente detalles:
1. Si algún proceso no libera el semáforo, se puede provocar un bloqueo.

2. No hace falta que un proceso libere su propio recurso, es decir, la operación signal() puede
que sea ejecutada por otro proceso.
3. Con simples semáforos no se puede imponer un orden en los procesos accediendo a dife-
rentes recursos.
Unas principales desventajas de semáforos son:
1. Depende del programador el uso correcto de los wait() y signal()
2. El recurso es independiente del semáforo.
3. Entre wait() y signal() el usuario puede realizar cualquier operación con el recurso.
2.4.6. Monitores
Los monitores son estructuras que implementa un lenguaje de programación y ofrece una
mayor funcionalidad que los semáforos pues son más fáciles de controlar. El concepto de moni-
tor fue definido por primera vez en Hoare mencionado por [33]. La estructura de monitor se ha
implementado en varios lenguajes de programación como: Pascal concurrente, Modula-2, Java,
y otros.
En concreto, para una lista enlazada se puede necesitar un cerrojo que bloquee todas las
listas enlazadas o bien un cerrojo por cada elemento de una lista. En la figura 2.3
Figura 2.3: Estructura general de un monitor

2.4.6.1. Monitores con Señales
Un monitor es un módulo de software que consta de uno o más procedimientos[48], una

secuencia de inicio y uno datos locales. Sus características son las siguientes:
1. Sólo los procedimientos del monitor acceden a variables de datos locales.
2. Un proceso entra en el monitor invocando a uno de sus procedimientos.
3. En el monitor solo un proceso puede ser ejecutado en un momento dado; cualquier otro
proceso quedará suspendido esperando la disponibilidad del monitor.
Al ser un proceso por vez, el monitor puede ofrecer un servicio de exclusión mutua fácil-
mente. Así una estructura de datos puede protegerse situándola dentro de un monitor.
Los monitores deben ofrecer herramientas de sincronización. Por ejemplo: si un proceso
llama a un monitor y una vez dentro de él el proceso queda suspendido esperando alguna condi-
ción, hará falta un servicio que libere al monitor y lo deje disponible para el siguiente proceso.
Más tarde cuando la condición se cumpla, el proceso suspendido podrá regresar al monitor y
ejecutarse desde el momento de la suspensión.
El monitor proporciona variables de condición que son accesibles sólo desde dentro del
monitor.
Hay dos funciones para operar variables de condición:
cwait (c). Suspende la ejecución del proceso que llama bajo la condició+n ç". El monitor está
ahora disponible para otro proceso.
csignal (c). Retorna la ejecución de un proceso suspendido después de un cwait, bajo la misma
condición. Si hay varios procesos elige uno de ellos.
Si un proceso de monitor ejecuta un csignal() y no hay tareas esperando entonces el csig-

nal() se pierde.
Aunque un proceso puede entrar al monitor llamando a cualquiera de sus procedimientos, se
puede decir que el monitor tiene un solo punto de acceso, custodiado para que sólo un proceso
esté en el monitor en un instante dado. Si existen otros procesos tratando de entrar al monitor,
éstos se colocan en una cola de procesos suspendidos esperando la disponibilidad del monitor.
Un proceso dentro de un monitor puede suspenderse a sí mismo, temporalmente, bajo la
condición X ejecutando cwait(x), entonces se coloca en una cola de procesos que esperan que
cambie la condición X entonces ejecuta un csignal(x) que avisa a la cola de condición corres-
pondiente de que la condición a cambiado.
2.4.6.2. Monitores con Notificación y Difusión
Son varios los inconvenientes que presenta la solución de Hoare[48, 60]:
1. Si el proceso que ejecuta el csignal() no ha terminado en el monitor, se necesitarán dos

cambios de procesos adicionales: uno para suspender el proceso y otro para reanudarlo.
2. La planificación de procesos asociados con las señales debe ser muy fiable. Si un proceso
ejecuta un csignal(), el proceso de la cola de condición correspondiente debe activarse de
inmediato, antes de que ingrese otro proceso del exterior o cambie la condición bajo la
que se activó el proceso.
Lampson y Redell desarrollaron una definición de monitores para el lenguaje MESA [60].
La estructura de mesa reemplaza la primitiva csignal() por cnotify(). Cuando un proceso ejecuta
cnotify(x) envía una notificación a la cola de condición X, lo cual no significa que el proceso
que esta ocupando el monitor vaya a detenerse, simplemente el cnotify(x) avisa al proceso de la
cola de condición correspondiente de que será reanudado en un futuro cercano. Puesto que ésta
no garantiza que un proceso exterior entre al monitor, el proceso debe comprobar la condición
nuevamente.
En el código, la sentencia IF se reemplaza por un bucle While, lo cual genera una evaluación
extra de la variable, pero sin embargo no hay cambios de procesos extra.
Una modificación útil sería asociar un temporizador de guardia a cnotify() que permitiría
que un proceso que ha esperado durante el intervalo máximo sea situado en estado de listo,
independientemente de si se ha notificado la condición o no.
Con la norma de notificar a los procesos en lugar de reactivarlos, es posible añadir una primi-
tiva de difusión cbroadcast(). La difusión provoca que todos los procesos que están esperando
por una condición se coloquen en el estado de listo. Esto es útil cuando un proceso no sabe
cuantos procesos deben reactivarse.
El método Lampson/Redell es menos propenso a errores debido a que cada procedimiento
comprueba la condición luego de ser despertado, por medio de la instrucción while, un proceso
puede realizar una señal o una difusión incorrectamente sin provocar un error en el programa
que la recibe.
Además este modelo presenta un método más modular de construcción de programas.
Hay dos niveles de condición que deben satisfacerse para los procesos secuenciales coope-
rantes.
1. Estructura de datos consistentes: significa que el monitor hace cumplir la exclusión mutua
y concluye la operación de entrada o salida antes de permitir cualquier otra operación
sobre el búfer.
2. La misma condición del nivel 1 y, además disponer de suficiente memoria para que este
proceso pueda completar su solicitud de asignación.
Un monitor, a diferencia de un semáforo es una estructura que permite tener un control ma-
yor sobre los procesos que van a hacer uso de un recurso. Los sistemas operativos y los lenguajes
de programación proporcionan mecanismos muy similares para implementar las funcionalida-
des de semáforos y monitores. Por ejemplo Solaris pone a disposición del programador mútex
adaptativos, variables de condición, semáforos, bloqueos o cerrojos del tipo lector-escritor y co-
las de bloqueos. Solaris se apega a la estructura de monitor analizada en esta sección. Además,
Solaris uso ciclos infinitos para proteger el acceso a datos compartidos, solamente si el código
consta de algunos cientos instrucciones, de otra forma este mecanismo sería muy ineficiente.
Cuando el código se excede de este número de instrucciones entonces se usa un semáforo o
variables de condición. De esta forma si el hilo ya está ocupando el cerrojo, entrará en un ciclo
infinito y pasará al estado durmiente. Cuando se libere el cerrojo, el hilo que la ocupa ejecutará
una instrucción signal() dirigida al hilo siguiente en estado de espera, de modo que pueda pasar
a ejecución. Es más económico en términos de instrucciones de CPU, realizar un cambio de
contexto a estar ejecutando quizás miles de ciclos de espera en un ciclo infinito.
Windows XP al igual que en Solaris protege los bloques de datos mediante ciclos infinitos
en segmentos de código pequeños, pero por razones de eficiencia, el kernel no sacará un hilo
mientras mantenga un cerrojo que esté ejecutando un ciclo infinito. Para la sincronización de
hilos que no se ejecutan en el kernel Windows XP proporciona mútex, semáforos, sucesos y
temporizadores. El sistema protege los datos compartidos requiriendo que un hilo adquiera la
propiedad de un mútex para acceder a los datos y libere dicha propiedad cuando termine. Los
sucesos son similares a las variables de condición y los temporizadores se emplean para notificar
a uno o más hilos que ha transcurrido un determinado período de tiempo.
En Linux la sincronización se lleva a cabo mediante ciclos infinitos y semáforos usando
también versiones lector-escritor de éstos, de esta forma, se pueden establecer bloqueos en el
kernel. En una máquina de multiprocesadores, el mecanismo fundamental de bloqueo se basa en
ciclos infinitos y el kernel se diseña de modo que dicho tipo de bloqueo se mantenga sólo durante
períodos de tiempo cortos. En máquinas monoprocesador, los bloqueos mediante ciclos infinitos
no resultan apropiados y se reemplazan por un mecanismo de activación y desactivación de la
función de apropiación en el núcleo.
2.4.7. Paso de mensajes

Los semáforos, los monitores y los mútex están pensados principalmente para la sincroni-
zación entre procesos. Los monitores proporcionan adicionalmente abstracción de datos, pero
tienen algunos problemas de implementación y tienden a ser restrictivos en cuanto al rango de

interpretaciones permisibles de los datos. Además, la implementación de esos mecanismos tien-
de a confiar en gran medida en la suposición de acceso común a memoria por parte de todos
los procesos que intervienen en la sincronización. Por ejemplo, las variables semáforo son glo-
bales y las estructuras de monitor (datos locales, procedimientos públicos) están generalmente
centralizados. El acceso a las variables globales puede ocasionar considerables retrasos de co-
municación en sistemas distribuidos que no disponen de memoria común. Como resultado, la
aplicación directa de mecanismos centralizados para control de concurrencia en entornos distri-
buidos suele ser ineficaz y lenta.
Los mensajes son un mecanismo relativamente sencillo adecuado tanto para comunicación
como para sincronización entre procesos en entornos centralizados además de entornos distri-
buidos. Muchos sistemas operativos de multiprogramación comerciales soportan algún tipo de
mensajes entre procesos. El envío y recepción de mensajes es una forma estándar de comuni-
cación entre nodos de redes de computadoras, lo que hace que sea muy atractivo aumentar esta
facilidad para proporcionar las funciones de comunicación y sincronización entre procesos. Por
esta razón, los mensajes son muy populares en sistemas operativos distribuidos.
En esencia, un mensaje es una colección de información que puede ser intercambiada entre
un proceso emisor y un receptor. Un mensaje puede contener datos, órdenes de ejecución o
incluso código a transmitir entre dos o más procesos. Los mensajes suelen ser utilizados en
sistemas distribuidos para transferir porciones importantes del sistema operativo y/o programas
de aplicación a nodos remotos.
El formato del mensaje es flexible y negociable por cada pareja específica emisor-receptor.
Un mensaje se caracteriza por su tipo, longitud, identificadores de emisor y receptor y un campo
de datos.
2.4.7.1. Operaciones típicas de los mensajes
Las operaciones más comunes que proporcionan los sistemas operativos son enviar (send)
mensaje y recibir mensaje. Los aspectos de implementación más importantes acerca de los men-
sajes son:
Denominación Existen dos tipos:
Denominación directa. Es aquella que cuando se invoca una operación de mensaje, cada
emisor debe designar al receptor específico, y a la inversa, cada receptor debe designar una
fuente desde la cual desea recibir un mensaje. Por ejemplo
proceso A;
/*Mucho código de A*/
send(B, mensaje)
/*Más Código de A*/
fin
proceso B;
/*Mucho código de B*/
receive(A, mensaje)
/*Más Código de B*/
fin
donde mensaje es el mensaje que se ha transmitido desde A hacia B. A y B son las entida-
des que interactúan y que deben ser especificadas al momento de efectuar las correspondientes
llamadas. En este caso, si B se ejecuta antes, tendrá que esperar a que A envíe el mensaje. Si
A se ejecuta antes B tendrá que esperar a que B pueda recibir el mensaje. Esta forma de comu-
nicación es segura en el sentido de que los procesos saben exactamente a donde va y de donde
viene la información, pero bajo ciertos entornos no puede ser posible tener una lista de todos los
emisores y receptores.
Denominación indirecta. Los mensajes son enviados y recibidos a través de depósitos espe-
cializados dedicados para este propósito. A estos depósitos se les denomina buzones debido a su
modo de funcionamiento. Un ejemplo del uso de buzones puede verse en el siguiente listado:
proceso A;
/*Mucho código de A*/
send(buzón1, mensaje)
/*Más Código de A*/
fin
proceso B;
/*Mucho código de B*/
receive(buzón1, mensaje)
/*Más Código de B*/
fin
Observe que ahora que A no necesita que esté disponible B o viceversa. Si A se ejecuta antes
envía su mensaje al buzón y hasta que se ejecute B lo podrá recoger. Si B se ejecuta antes que A
tendrá que esperar a que llegue el mensaje al buzón revisándolo continuamente.
El sistema operativo tendrá que proporcionar las facilidades necesarias para poder hacer uso
de los buzones, tal como la de crear un nuevo buzón y la de eliminar un buzón.
La comunicación indirecta es muy versátil en el sentido de que puede proporcionar corres-
pondencias uno a uno o de uno muchos, de muchos a uno y de muchos a muchos entre los
procesos emisores y los receptores.
Copia. El intercambio de mensajes entre dos procesos, por definición, transfiere el contenido
del mensaje desde el espacio de direcciones del emisor al espacio de direcciones del receptor.
Esto se logra copiando todo el mensaje al espacio de direcciones del receptor o simplemente
pasando un apuntador al mensaje entre los dos procesos. En otras palabras, la transferencia
del mensaje puede ser por valor o por referencia. En sistemas distribuidos que no disponen de
memoria común, la copia es obviamente inevitable. En sistemas centralizados, el compromiso
está entre la seguridad y la eficiencia.
Como aspecto negativo, la copia de mensajes consume memoria y ciclos de CPU. La comu-
nicación asíncrona de mensajes y/o esquemas de protección de memoria pueden requerir que
cada mensaje sea copiado primero desde el espacio del emisor a un búfer en el sistema operativo
y desde ahí posteriormente al espacio de proceso del receptor. Esto significa que se hace una
doble copia para un solo mensaje. Aparte la estructura de datos dinámica que debe de manejar
el sistema operativo para la administración de los mensajes. Algunos diseñadores enfrentan este
problema proporcionando solamente un apuntador al espacio de direcciones del emisor, pero
este enfoque disminuye la seguridad al estar abriendo una ventana al proceso receptor con sus
consecuentes peligros.
Mach. enfrenta este problema al asignar una sola copia, tanto al emisor como al receptor,
siempre y cuando sólo la usen para lectura. En el momento en que alguno quiera realizar una
operación de escritura, se crea entonces una copia física se actualizan las tablas de direcciones
y entonces cada proceso continúa con una copia separada del mensaje.
Intercambio síncrono frente a asíncrono. El intercambio de un mensaje entre un emisor y un

receptor pude ser síncrono o asíncrono. Cuando un intercambio de mensajes es síncrono, tanto
el emisor como el receptor deben de proceder juntos a completar la transferencia. En sistemas
síncronos la operación enviar es bloqueante. es decir, cuando un emisor desea enviar un mensaje
para el cual no se ha emitido el correspondiente recibir, el emisor debe quedar suspendido hasta
que un receptor acepte el mensaje. En consecuencia, sólo puede haber un mensaje pendiente
como máximo en cada momento por cada emisor-receptor.
Las ventajas del mecanismo síncrono de enviar-recibir mensajes son su recargo comparati-
vamente bajo y su facilidad de implementación, además del hecho de que el emisor sabe que
sumensaje ha sido realmente recibido en el momento en que deja atrás la operación enviar. Una
desventaja de este método es la obligada operación síncrona de emisores y receptores, que puede
no ser deseable en algunos casos.
Con el intercambio asíncrono de mensajes, el emisor no queda bloqueado cuando no hay
un recibir pendiente. El enviar asíncrono, sin bloqueo, se implementa haciendo que el sistema
operativo acepte y almacene temporalmente los mensajes pendientes hasta que se emita el co-
rrespondiente recibir. De esta forma el emisor puede continuar su ejecución después de enviar
un mensaje y no necesita quedar suspendido, independientemente de la actividad de los recep-
tores. Este modo de operación de “depositar y olvidar” aumenta el grado de concurrencia del
sistema. Por ejemplo, un proceso que desee imprimir algo puede incluir simplemente los datos
en cuestión en un mensaje y enviarlo al proceso servidor de impresoras. Incluso si el servidor de
impresoras está ocupado en ese momento, el mensaje será almacenado en la cola por el sistema y
el emisor podrá continuar sin necesidad de esperar. Esta forma de operar también conlleva ries-
gos. Podemos notar que si se llega a tener un proceso que genere muchos mensajes sin sentido
puede llegar a llenar el almacenamiento temporal del sistema operativo, impidiendo así la co-
municación normal entre los demás procesos. Una forma de evitar este problema es imponiendo
un límite al número de mensajes que puede tener pendiente un proceso.
Un problema relacionado con el anterior se le llama aplazamiento indefinido. Este ocurre
cuando se envía un mensaje pero nunca se recibe debido, por ejemplo, a que el receptor ya no
está en el sistema, o cuando un receptor está esperando un mensaje que nunca se produce. Para
evitar este tipo de problemas se puede implementar a recibir sin bloqueo. De esta forma si el
mensaje se encuentra disponible, lo leerá, de otro modo, continuará con su ejecución normal y
después en otro momento volverá a intentar la lectura para ver si está disponible, evitando así el
bloqueo.
Longitud. El último punto en cuanto a la implementación de los mensajes es determinar el ta-

maño adecuado de cada mensaje, esto es, si deben de tener longitud fija o longitud variable. Aquí
tenemos un compromiso de recargo del sistema frente a flexibilidad. Se se hace la transferencia
vía apuntadores, entonces no hay tanto problema. Sin embargo, cuando los mensajes deben ser
copiados y almacenados temporalmente este aspecto debe ser evaluado cuidadosamente.
Los mensajes de tamaño fijo suelen producir una recarga del sistema relativamente baja,
en virtud de que permite a los buferes del sistema ser también de longitud fija, lo que hace su
asignación bastante sencilla y eficaz. Aquí el problema es que en un ambiente real, los mensajes
llegan de todos tamaños haciendo casi imposible la asignación de memoria sin desperdicio de
ésta. Los mensajes de tamaño dinámico alivian este problema pero incrementan la complejidad
del diseño del manejador de memoria del sistema operativo al tener que manejar estructuras de
control para memoria dinámica, que puede conducir a problemas de fragmentación de memoria.
2.4.7.2. Comunicación y sincronización interprocesos con mensajes
Aunque los mensajes son adecuados tanto para comunicación como para sincronización en-
tre procesos, analicemos primero el aspecto de la sincronización de sus operaciones con el fin
de establecer un punto de referencia con lo visto en el punto 2.4.7.1. Hay que observar que in-
tercambiar un mensaje vacío, sin datos entre dos procesos equivale a señalizar. Un proceso al
enviar un mensaje, transfiere una señal de temporización a otro proceso, el receptor. Por lo que
se refiere a la señalización, esto tiene el mismo efecto que si un proceso (el emisor) ejecuta una
operación signal() y el otro (el receptor) ejecuta un wait() sobre el mismo semáforo. En esta
analogía. la identidad del buzón corresponde con el nombre de la variable del semáforo.
Dado el poder de señalización del de los mensajes, la exclusión mutua puede lograrse si-
guiendo la lógica de una solución similar con semáforos. En el siguiente algoritmo se representa
el código de usuario que accede a un recurso compartido protegido por el buzón mútex. De
acuerdo con la lógica de los semáforos, cuando se crea un buzón está vacío, es decir, no contie-
ne mensajes. Esto es equivalente a los semáforos se inicialicen por el sistema en ocupado. Para
hacer que el recurso esté disponible para el primer solicitante, el proceso padre envía un mensaje
al buzón antes de iniciar los procesos usuarios del recurso. Puesto que este mensaje se utiliza
únicamente para fines de señalización, su contenido es irrelevante, y se supone que es un men-
saje nulo, vacío. Algún tiempo después, el primer proceso que desea utilizar el recurso invoca la
operación recibir sobre el buzón mútex. Esto ocasiona a que el mensaje nulo inicial sea retirado
del buzón y entregado al proceso a través del parámetro mensaje. Cuando ya recibió el mensaje,
el proceso es libre de continuar y entra a la sección crítica. Si cualquier otro proceso ejecuta
una instrucción recibir sobre el buzón mútex durante ese tiempo quedará suspendido debido a
que el buzón se encuentra vacío. Cuando el proceso completa su sección crítica, el propietario
devuelve un mensaje en mútex y continúa ejecutándose. Uno de los procesos suspendidos en
mútex, si los hay, recibe entonces el mensaje y por tanto, se ve capacitado para proseguir con su
sección crítica. Los restantes procesos es espera, en caso de que los haya, obtendrán sus turnos,
uno cada vez, cuando el mensaje sea devuelto por os procesos que abandonen su sección crítica.
Como se ve, este esquema es conceptualmente parecido al de los semáforos. Un solo mensa-
je circula a lo largo del sistema como testigo del permiso de utilización del recurso compartido.
puesto que sólo un proceso como máximo puede tener la propiedad del mensaje en cada ins-
tante, la exclusión mutua está asegurada. Esto, naturalmente, depende de la suposición de que
la operación recibir es indivisible en el sentido de entregar el mensaje, en caso de haberlo, a
un solo invocador cuando sea invocado concurrentemente por varios. Virtualmente todas las im-
plementaciones de mensajes proporciona este tipo de facilidad y se supone que esta propiedad
existe a lo largo del análisis efectuado en esta sección. Cuando se utilizan para señalización, el
mismo acto de recibir un mensaje logra el propósito deseado, y el contenido efectivo del mensaje
no importa. Después se verá que la verdadera potencia de los mensajes es cuando los procesos
transfieren datos al mismo tiempo, combinando así la comunicación y la sincronización entre
procesos dentro de una sola actividad.
En el algoritmo siguiente vemos cómo podría implementarse la protección de la sección
crítica con mensajes.
...
const int tamano;
typedef struct mensaje{
char elmensaje[tamano];
/*Otra información del mensaje*/
} Tmensaje;
int usuarioX(){
Tmensaje mensaje;
while (true) {
recibir(mútex, mensaje);
sección_critica(),
enviar(mútex, mensaje);
} /*fin while*/
} /*Fin usuarioX*/
/*Cuerpo del proceso padre*/

int main(){
/*Todos los procesos hijo
acceden al buzón
*/
crear_buzon(mútex);
enviar(mútex,nulo);
parallelbegin(proceso1,proceso2,...,procesoX);
}
El programa de la página 108 demuestra informalmente cómo se puede utilizar una facili-
dad de mensajes para implementar semáforos binarios. La implicación importante es que los
mensajes no son un mecanismo más débil que los semáforos. Los semáforos generales pueden
simularse aumentando el número de mensajes testigo en el sistema hasta que coincida con el
valor inicial de un semáforo general equivalente.
2.4.7.3. Envío de señales de interrupción con mensajes
El mecanismo de interrupción proporciona un enlace entre los sucesos externos asíncronos

y las rutinas software que le prestan el servicio. Esto es, las interrupciones indican la llegada de
sucesos externos. Teóricamente es como si un proceso enviara una señal dado un cierto suceso.
Tomando en consideración lo anterior, es posible implementar mecanismos de señales que sea
uniforme y que incluya tanto la sincronización ordinaria como las interrupciones, ya sea de
hardware o de software. En la realidad, la mayoría de los sistemas comerciales tienden a separar
el manejo de interrupciones y el de las señales debido a que las primeras cuentan con mayor
información para ser se manejadas por rutinas generales.
No obstante, desde el punto de vista conceptual, la sincronización tiene requisitos parecidos
en ambos casos y tiene poca justificación mantener dos conjuntos de procesos separados a nivel
de usuario. El sistema operativo podría convertir cada interrupción en una señal enviada por el
sistema a un proceso que la espere. Por ejemplo, puede crearse un semáforo por cada interrup-
ción. entonces las rutinas de servicio de interrupción pueden conectarse a los sucesos externos
ejecutando una operación wait() sobre el semáforo asociado cada vez que estén preparadas para
dar servicio a una interrupción. La llegada de un suceso externo, indicada por una interrupción,
se puede utilizar para activar el servidor mediante la operación signal() ejecutada por el sistema
operativo sobre el semáforo asociado.
2.4.8. Concurrencia e interbloqueo (deadlock)

En general, una elevada utilización de recursos y la posibilidad de la operación paralela
de muchos dispositivos de entrada/salida gobernados por procesos concurrentes, contribuyen
a mejorar el potencial de rendimiento de los sistemas multitarea y de multiprogramación. Al
mismo tiempo, la concurrencia y la elevada utilización de recursos también proporciona las
condiciones necesarias y la base para que se produzcan interbloqueos que puedan ocasionar que
el rendimiento general del sistema baje, en ocasiones hasta quedar completamente inutilizado.
int proceso1(){ int proceso2()\{

... ....
wait(impresora); wait(disco1);
wait(disco1); wait(impresora);
wait(disco2); procesar(disco1,impresora);
procesar(disco1,
disco2,
impresora); signal(impresora);
signal(disco1); signal(disco1);
signal(disco2);
signal(impresora); .....
.....
} }
Hasta ahora hemos hablado de los mecanismos para poder manejar la sección crítica evitando
que lleguen a acceder dos o más procesos al mismo tiempo y al mismo recurso. No obstante,
un mal uso, algunas omisiones e incluso algún código malicioso, pueden llegar a hacer que
los procesos queden esperando indefinidamente por un recurso que muchas de las veces está
desocupado, pero por los problemas anteriores parece que está siendo utilizado por otro proceso.
Un interbloqueo (también conocido como deadlock o abrazo mortal) es una situación donde
un conjunto de procesos están permanentemente bloqueados como consecuencia de que cada
proceso ha adquirido un subconjunto de los recursos necesarios para su operación y está espe-
rando la liberación de los recursos restantes mantenidos por otros del mismo grupo, haciendo
imposible que alguno de los procesos pueda continuar su ejecución.
Los interbloqueos pueden ocurrir en entornos concurrentes como resultado de la concesión
incontrolada de recursos del sistema a los procesos que hacen la petición.
Vamos a poner un ejemplo, considérese que un sistema contiene una impresora y dos uni-
dades de disco. Supóngase que dos procesos concurrentes efectúan las peticiones de recursos
indicadas en la página 109. La secuencia presentada supone que los recursos son solicitados
y devueltos al asignador de recursos por medio de las operaciones que ya conocemos wait() y
signal() sobre las variables de semáforo binario impresora y disco (general inicializado a dos),
respectivamente, Ahora suponemos que tenemos dos procesos concurrentes P1 y P2, se entrela-
zan de tal modo que en un cierto momento el proceso P1 tiene concedido el uso de la impresora
y P2 trata de conseguir una unidad de disco. En este caso, los dos procesos están interbloquea-
dos, ya que ninguno de ellos puede adquirir el conjunto de recursos que necesita para continuar
su ejecución y liberar los recursos que le han sido asignados.
2.4.9. Principios del interbloqueo

Generalizando algunas características de los interbloqueos, el listado de la página 109 ilustra
que el problema es el resultado de la ejecución concurrente, ya que cada proceso podría com-
pletarse correctamente si se ejecutase en forma serie en cualquier orden arbitrario. Además, el

problema sólo ocurre para algunas situaciones específicas de entrelazamiento de los dos pro-
cesos. Esto es, si alguno logra hacerse de los recursos que necesita antes de que el otro tome
alguno, entonces no se dará el interbloqueo y ambos podrán ejecutarse adecuadamente. En el
listado de la página 109 se hace uso de wait() y signal para hacer notar que los procesos mantie-
nen los recursos que han obtenido, mientras esperan los que que necesitan, también se sugiere
que sólo pueden entrar a su región crítica en el momento en que disponen de todos los recursos
solicitados, también en el ejemplo se usaron dispositivos físicos, pero en realidad, puede usar-
se cualquier recurso del sistema. en general los interbloqueos pueden ocurrir como resultado de
competencias sobre cualquier clase de recurso compartido, incluyendo la memoria principal, da-
tos globales, búferes y archivos o registros. Las situaciones mencionadas anteriormente ilustran
las condiciones necesarias para que se produzca el interbloqueo, las cuales pueden formularse
más explícitamente del modo siguiente:
Exclusión mutua. Los recursos compartidos son asignados y usados de modo mutuamente ex-
clusivo, esto es, por un proceso como máximo en cada instante.
Conservar y esperar. Cada proceso conserva los recursos que ya le han otorgado mientras es-
pera a adquirir los otros recursos que necesita.
No expropiación. Solamente el proceso puede regresar voluntariamente los recursos que le han
sido asignados. El sistema operativo no puede revocarlos.
Espera circular. Los procesos interbloqueados forman una cadena circular de modo que cada
proceso conserva uno o más recursos que son requeridos por el siguiente proceso de la
cadena.
La existencia simultánea de estas condiciones define el estado de interbloqueo. En otras

palabras, las cuatro condiciones deben estar presentes para que se produzca un interbloqueo. Por
lo tanto, un modo de manejar los interbloqueos es asegurarse que en cada momento al menos una
de las cuatro condiciones necesarias para que se produzca el interbloqueo sea evitada por diseño.
Otra posibilidad es hacer que el asignador de recursos examine las posibles consecuencias de
asignar un recurso solicitado particular y evite las situaciones inseguras que puedan conducir
a interbloqueos y tomar acciones que lo remedien cuando sea necesario. La mayoría de las
técnicas de manejo de interbloqueos caen en una de esas tres categorías, que normalmente se
denominan prevenir, evitar, detectar y recuperarse de un interbloqueo.
2.4.10. Acciones a realizar ante un interbloqueo

Antes de hablar de las técnicas de prevenir, evitar, detectar y recuperarse de un interbloqueo,
es necesario saber algunas características de los recursos del sistema.
2.4.11. Recursos reutilizables y consumibles del sistema

Los recursos de un sistema de computadora cuya asignación está sujeta a interbloqueos se
pueden clasificar en dos grupos:
1. Recursos reutilizables.
2. Recursos consumibles.
Los recursos reutilizables se caracterizan porque pueden ser utilizados con seguridad por un
proceso sólo cada vez como máximo. Tales recursos son normalmente asignados a un proceso
solicitante cuando están disponibles. Cuando son liberados explícitamente pos su propietario
temporal, un recurso reutilizable puede ser asignado al siguiente proceso solicitante, si es que
hay alguno. Los recursos hardware compartidos y las estructuras de datos globales estáticas y
a largo plazo pertenecen habitualmente a esta categoría. algunos ejemplos incluyen la memoria
principal, los buses de entrada salida, las unidades de disco y los búferes del sistema. por lo
común existe un número fijo de recursos reutilizables en el sistema. Pueden existir diferentes
instancias de un mismo tipo de recurso reutilizable, como las páginas de memoria o impresoras.
Si las unidades individuales de un tipo particular de recurso son indistinguibles en el sentido
de que cualquiera de ellas puede satisfacer una solicitud determinada, entonces tales unidades
no son tenidas en cuenta separadamente por lo que respecta a la detección de interbloqueos; el
sistema únicamente contabiliza el número total. En cada momento, cada recurso reutilizable está
o bien disponible, o bien temporalmente concedido a un proceso. La suposición más común es
que el propietario temporal de un recurso lo devolverá en un tiempo finito a menos que resulte
interbloqueado.
Los recursos consumibles, por ejemplo los mensajes, se producen y se consumen por pro-
cesos que se encuentran activos. Esto significa que el número de esos recursos puede variar a
medida que transcurre el tiempo. Una causa que es común de ocasionar un interbloqueo y que
afecta a los recursos consumibles es la espera de un evento, por ejemplo una señal o un mensaje,
que nunca van a llegar. Esto suele suceder por una sincronización inadecuada, un direcciona-
miento erróneo de los mensajes, el proceso encargado de generar la señal o el mensaje terminó
anormalmente o en última instancia a errores de programación.
2.4.11.1. Prevención de interbloqueos
Como se mencionó en la sección 2.4.9, el punto básico es evitar al menos una de las cuatro
condiciones necesarias para que se produzcan los interbloqueos. La exclusión mutua es gene-
ralmente difícil de evitar, por lo que es costumbre prevenir una o más de las tres condiciones
restantes.
Exclusión mutua Esta se aplica a los recursos que no pueden ser compartidos. Por ejemplo,
varios procesos no pueden compartir simultáneamente una impresora. Los recursos que sí pue-
den compartirse y por lo tanto, no pueden generar una situación de interbloqueo. Dentro de éstos
podemos poner como ejemplo un archivo de sólo lectura. Si varios procesos desean abrir un ar-
chivo en modo de sólo lectura entonces se les puede conceder a todos de forma simultánea. Así
un proceso no necesita esperar por un recurso compartible. No obstante, no se puede ignorar
la exclusión mutua diciendo que simplemente nunca va a suceder, por que varios recursos son
explícitamente no compartibles.
Conservar y esperar Esta condición se puede eliminar exigiendo o forzando a un proceso

a que libere todos los recursos asignados a él cada vez que solicite un recurso que no esté
disponible. Esto quiere decir que los interbolqueos se previenen debido a que los procesos en
espera no retienen recursos. Existen dos posibles formas de implementar esta estrategia:
Solicitar todos los recursos. El proceso solicita de una sola vez todos los recursos antes de
entrar en su sección crítica. esto es, espera hasta que pueda recibir los recursos necesarios
antes de que pueda ejecutarse.
Petición incremental de recursos. El proceso pide los recursos uno a uno, pero si se niega
alguna petición de recurso y tiene recursos asignados entonces los libera.
Para solicitar los recursos al comienzo, un trabajo o proceso debe de indicar al sistema ope-
rativo todas sus necesidades de recursos. Esto implica que se debe de saber con anticipación
todos los recursos que va a ocupar el proceso y muchas veces, se sobreestima el número de
recursos que se usan dejando muchos de ellos inutilizados por largos períodos de tiempo. Por
ejemplo, esto puede pasar cuando se trabaja con una base de datos, en vez de solicitar un con-
junto de registros sobre los que se va a trabajar, puede solicitarse la base de datos completa con
la subsecuente pérdida de disponibilidad del recurso.
Cuando el sistema operativo asigna todos los recursos a un proceso, éstos quedan fuera
del alcance de los demás procesos durante todo el tiempo de vida del proceso propietario, en
contraposición con los realmente utilizados durante una parte de la ejecución del proceso en
cuestión. El problema es que algunos recursos son utilizados una pequeña parte del tiempo de
ejecución del proceso, por lo tanto pueden permanecer inactivos o sin ser utilizados por otros
procesos durante períodos de tiempo relativamente largos. Pero para garantizar la prevención
del interbloqueo no pueden ser asignados a otros procesos, aunque ya no los ocupe el proceso
propietario.
Cuando el proceso adquiere los recursos incrementalmente, según se vayan necesitando, y
evitar interbloqueos mediante la liberación de todos los recursos retenidos por un proceso si
solicita un recurso temporalmente inalcanzable. Esta estrategia evita las desventajas de solicitar
todos los recursos desde el comienzo del proceso. Sin embargo, las desventajas es que algunos
recursos no pueden ser liberados y readquiridos en tiempo posterior fácilmente. Por ejemplo
algunos cambios efectuados en memoria o sobre archivos pueden corromper el sistema si no
se llevan a cabo completamente. Así la reanudación de un recurso solo tiene sentido si no se
compromete la integridad del sistema y además cuando el gasto debido a las operaciones de
guardar y restablecer el estado del proceso por la reanudación es lo suficientemente pequeño.
Otro problema con este enfoque es que puede pasar un tiempo exageradamente largo debido
a que puede existir un recurso que sea ocupado continuamente y como el proceso, cada vez que
solicita todos los recursos, no lo encuentra disponible liberará nuevamente todos los ya adquiri-
dos generándose entonces un problema de inanición, esto es, el proceso nunca se ejecutará por
falta de uno o dos recursos.
No expropiación La condición de no expropiación puede ser negada obviamente permitiendo

que el sistema operativo pueda apropiarse de la CPU y de los recursos a los procesos bloqueados.
Como el proceso no cede voluntariamente los recursos, el sistema operativo tiene que encargar-
se de guardar y restaurar su estado cuando el proceso vuelva a ponerse en ejecución, esto hace
que la expropiación de recursos se aún más difícil que la liberación voluntaria y reanudación de
recursos analizada anteriormente. La expropiación se puede llevar a cabo sobre ciertos recursos
tales como la CPU y la memoria principal. Sin embargo, algunos recursos como los archivos
parcialmente escritos, no pueden ser expropiados sin riesgo de corromper el sistema. Sin embar-
go, como algunos recursos no pueden ser expropiados con garantías, este método por sí mismo
no puede proporcionar prevención completa de los interbloqueos.
Espera circular Para evitar esta condición un enfoque es ordenar linealmente los diferentes
tipos de recursos del sistema. Con este método, los recursos del sistema se dividen en clases di-
ferentes. Los interbloqueos se previenen exigiendo que todos los procesos soliciten y adquieran
sus recursos en orden estrictamente creciente de las clases de recursos de sistema especificados.
Además, la adquisición de todos los recursos pertenecientes a una clase deben efectuarse con
una sola petición y no incrementalmente. Esto quiere decir que si ya solicitó un recurso de una
clase colocada delante de un recurso de otra clase ya no podrá solicitar ninguno anterior. La
ordenación lineal elimina la posibilidad de espera circular, por que con este enfoque, ningún
proceso puede esperar un recurso que debió haber solicitado antes.
Una desventaja de este método es que los recursos deben ser adquiridos en el orden prescrito,
en vez de ser solicitados cuando realmente se ocupen. Esto puede hacer que algunos recursos
sean adquiridos con bastante antelación a su uso efectivo, bajando así el grado de concurrencia
de todo el sistema al impedir que otros procesos hagan uso de ese recurso cuando no se ocupa.
2.4.11.2. Evitar interbloqueos
El principio básico para evitar interbloqueos es conceder únicamente las peticiones de recur-
sos disponibles que no puedan dar lugar a un estado de interbloqueo. La estrategia se implementa
haciendo que el asignador de recursos examine los efectos de la concesión de una petición par-
ticular. Se la concesión de un recurso no puede de ningún modo conducir a interbloqueo, se
concede el recurso al proceso solicitante. De otro modo, el proceso que lo solicita queda suspen-
dido hasta el momento en que su petición pendiente pueda ser concedida sin problemas. Esto
suele pasar después de que han sido liberados los recursos ocupados por otros procesos.
Esta estrategia requiere que todos los procesos especifiquen los recursos que van a usar. Una
vez que el el proceso comienza su ejecución, cada proceso solicita sus recursos como y cuando
los necesita, hasta el límite máximo solicitado. El planificador de recursos lleva la cuenta del
número de recursos que lleva asignados cada proceso y del número de recursos disponibles de
cada tipo, además de anotar el número de recursos restantes solicitados con anticipación pero
aún no requeridos por el proceso en ejecución. Si un proceso solicita un recurso que no esté
disponible tendrá entonces que esperar. En cambio, si está disponible, el planificador de recursos
examina si la concesión de la petición puede conducir a interbloqueo comprobando si cada uno
de los procesos ya activos puede terminar su ejecución sin problemas, en ese caso se asigna el
recurso al proceso.
Estado seguro Un estado es seguro si el sistema puede asignar recursos a cada proceso (hasta
su máximo) en determinado orden sin que eso produzca un interbloqueo. Más formalmente, un
sistema se encuentra en estado seguro sólo si existe lo que se denomina secuencia segura. Una
secuencia de procesos < P1 , P2 , ..., Pn > es una secuencia segura para el estado de asignación
actual si, para cada Pi , las solicitudes de recursos que PI pueda todavía hacer se pueden satisfa-
cer mediante los los recursos que se disponen actualmente, junto con los recursos retenidos por
todos los Pj , con j < i. Bajo esta situación, si los recursos que Pi necesita no están inmediata-
mente disponibles, entonces Pi puede esperar a que todos los Pj hayan terminado, cuando esto
suceda, Pi puede obtener los recursos faltantes para que pueda terminar su tarea asignada, y de-
volver entonces todos los recursos que solicitó y terminar su ejecución. Cuando Pi termina Pi+1
puede obtener los recursos que necesita y continuar de esta forma para los demás procesos. Si tal
secuencia no existe, entonces se dice que el estado actual del sistema es no seguro o inseguro y
por lo tanto existe un riesgo potencial de interbloqueo, y viceversa un estado seguro implica que
no puede producirse un interbloqueo. Hay que aclarar, que no obstante, un estado inseguro no
implica que habrá interbloqueo, como se dice existe un riesgo potencial. Pero un estado seguro
no podrá llevar nunca a un interbloqueo. Como ejemplo supongamos que se tiene un sistema de
arreglos de discos con 12 unidades en total y tenemos a su vez tres procesos P0 , P1 , P2 , el pro-
ceso P0 requiere para trabajar diez unidades, el proceso P1 puede necesitar como mucho cuatro
unidades, y el proceso P2 puede necesitar hasta nueve. Ahora suponemos que en el instante t0 el
proceso P0 tiene asignadas cinco unidades, el proceso P1 está usando dos unidades y el proceso
P2 tiene dos unidades. Esto significa que quedan tres unidades libres.
Necesidades máximas Necesidades actuales

P0 10 5
P1 4 2
P2 9 2
Cuando el sistema se encuentra en el instante t0 , el sistema está en estado seguro. La secuen-

cia < P1 , P0 , P 2 > satisface la condición de estado seguro. Al proceso P1 se le pueden asignar
inmediatamente todas sus unidades, después de los cual el proceso terminará por devolverlas
teniendo entonces el sistema cinco unidades disponibles. En seguida, el proceso P0 puede tomar
las unidades que le restan para completar sus necesidades y devolverlas cuando las desocupe.
en este instante el sistema contará con diez unidades y por último el proceso P2 puede obtener
todas sus unidades y devolverlas. Al final el sistema tendrá las doce unidades disponibles. Ob-
sérvese que un sistema puede pasar de un estado seguro a uno inseguro. Vamos a suponer ahora
que en el instante t1 el proceso P2 hace una solicitud y se le asigna una unidad más. El estado
del sistema pasará a inseguro. En este momento, sólo pueden asignarse todas sus unidades al
proceso P1 y cuando las devuelva, el sistema sólo dispondrá de cuatro unidades. Pero como el
proceso P1 tiene asignadas cinco, pero puede solicitar hasta diez, y en ese instante el sistema
no podrá cubrir este requerimiento y tendrá entonces que esperar. El proceso P2 tiene asignadas
en este punto tres unidades pero para completar su tarea necesita solicitar seis lo que tampoco
es posible dado que el sistema solo tiene cuatro disponibles de modo que también tendrá que
esperar, dando lugar a un interbloqueo. El error que se cometió fue autorizar la solicitud de una
unidad al proceso P2 . Si se hubiera hecho esperar a P2 hasta que los demás procesos hubieran
terminado y liberado sus recursos no se hubiera generado el interbloqueo.
Grafos de asignación de recursos En un sistema de asignación de recursos que tenga sólo

una instancia de cada tipo de recurso, se puede utilizar una variante del grafo para describir
los algoritmos usados para evitar el interbloqueo. Dado el grafo G = (N, A) que consta de un
conjunto finito no vacío de nodos (vértices), N , y arcos, A. Si los arcos son pares ordenados de
nodos (x, y), se dice que el grafo es dirigido. Un camino en un grafo dirigido es una secuencia de
arcos de la forma (x1 , x2 ), (x2 , x3 ), ...(xn−1 , xn ),. Un ciclo es un camino formado por al menos
dos nodos, en donde el primer nodo y el último son iguales. Un grafo bipartito (bicoloreado) es
un grafo G cuyos nodos pueden ser particionados en dos subconjuntos disjuntos, P y R, tales
que cada arco de G conecta un nodo de P y un nodo de R, tales que cada arco de G conecta
un nodo de P y un nodo de R. A la representación descrita se le denomina grafo general de
recursos. El grafo es dirigido y bipartito, formado por dos subconjuntos disjuntos de nodos
procesos y nodos recursos.
El grafo general de recursos de un estado posible del sistema descrito en relación con el
algoritmo de la página 109 se muestra en la tabla 2.1. En la figura 2.4 vemos que los procesos
están representados por un cuadrado y los recursos se representan por un círculo. Dentro de
el círculo se representa cada instancia del mismo con un círculo más pequeño. Los nodos de
los procesos están etiquetados como P1 y P2. Los nodos de los recursos se etiquetan con R1
y R2 respectivamente. Ahora supongamos que R1 representa una impresora, mientras que R2
representa a una unidad de disco. Los círculos pequeños dentro de los grandes indican entonces
que tenemos solamente una impresora y que tenemos dos unidades de disco.
Figura 2.4: Estado del sistema
La asignación de recursos a un proceso se representa mediante un arco que va desde el nodo

recurso correspondiente hasta el nodo proceso asociado. De este modo en la figura 2.4 el proceso
P1 tiene la prioridad de la impresora. Una petición de un recurso se representa mediante un arco
que va desde el nodo proceso solicitante hasta el nodo recurso solicitado. Por ejemplo en la
figura 2.4 se ha representado la petición que hace el proceso P2 de la unidad de disco.
El planificador de recursos puede entonces determinar si es segura o no la concesión de un
recurso utilizando variantes de la representación del grafo general de recursos. Una de estas
representaciones es mediante una matriz bidimensional en donde los procesos son las filas y los
tipos de recursos las columnas. Siguiendo esta línea, los elementos de la matriz corresponden
con los arcos individuales. Llamemos ahora a esta matriz asignados, y supóngase que cada
elemento aij indica el número de unidades de tipo j retenidas por el proceso i. En la tabla 2.1a
podemos ver ver un ejemplo de recursos asignados. En este caso, el proceso P1 tiene asignado
el recurso R1, para el sistema representado en la figura 2.4.
el número de recursos de cada tipo disponibles para asignación en un momento determinado
puede representarse por un vector fila de enteros disponibles, que se observan en la tabla 2.1b.
Las relaciones de recursos de recursos no utilizados pueden representarse por medio de una
matriz reclamados, semejante a la matriz asignados. Los elementos de esta matriz se pueden
calcular mediante la diferencia entre el número máximo de recursos de un tipo determinado
solicitado con anticipación por el proceso correspondiente y el número de recursos del mismo
tipo actualmente en propiedad de ese proceso. En la tabla 2.1b tenemos un ejemplo de la matriz
asignados antes de que sea concedida la petición de una unidad de disco solicitada por el proceso
P2.
La parte más importante para evitar interbloqueos es la prueba de seguridad. Podemos decir
que un estado es seguro si todos los procesos que ya tienen concedidos sus recursos tienen la
oportunidad de terminar su ejecución en algún orden determinado incluso si cada uno de estos
procesos utilizase todos los recursos a los que tiene derecho. De acuerdo a lo anterior, una prueba
de seguridad práctica debe determinar si existe tal ordenación.
Ahora ya podemos definir una operación menor que o igual sobre los vectores, C y A,
de idéntico tamaño r como C ≤ A si y solo si C[i] ≤ A[i] para todo i = 1, 2, ..., r. Con estas
definiciones podemos ahora definir la operación del planificador de recursos cuando recibe una
petición de un proceso.
Petición de recurso.
1. Para cada petición de recurso, verificar que el proceso que la realiza está autorizado a
realizar la petición, esto es, ha solicitado con anterioridad este recurso. No se deben de
autorizar peticiones que no hayan sido expresadas con anterioridad.
R1 R2 R1 R2
R1 R2
P1 1 0 P1 0 2
0 2
P2 0 0 P2 1 1
Asignados Reclamados Disponibles
a) Antes de la asignación
R1 R2 R1 R2
R1 R2
P1 1 0 P1 0 2
0 1
P2 0 1 P2 1 0
Asignados Reclamados Disponibles
b) Después de la asignación
Tabla 2.1: Representación de estados
2. Si un proceso solicita un recurso que no esté disponible, entonces éste será suspendido
hasta que pueda ser asignado cuando haya liberado y pueda ser asignado con seguridad.
3. Si un proceso solicita un recurso libre, se asume que el recurso se le concede actualizando

las estructuras de datos de asignados, reclamados y disponibles . Enseguida desmarcar
todos los procesos.
4. Encontrar un proceso desmarcado tal que: reclamadosi ≤ disponibles Si se encuentra,

marcar el proceso i,actualizar los vectores disponibles, disponibles := disponibles +
asignadosi y repetir este paso. Si no hay procesos que cumplan esta condición, pasar al
paso que sigue.
5. Si todos los procesos ya están marcados, el estado del sistema es seguro; por lo tanto, se
concede el recurso solicitado, se restaura el vector disponibles a su valor establecido en el
paso 2 y salir al sistema operativo. En caso contrario, el estado del sistema no es seguro
y por lo tanto se debe suspender el proceso solicitante, restaurar Xasignados, reclama-
dos y disponibles a sus valores anteriores a la ejecución del paso 2 y regresar al sistema
operativo.
Liberación del recurso.
Cuando se libera un recurso, se debe actualizar la estructura de datos de disponibles y

reconsiderar las peticiones pendientes, si las hay, del tipo de recurso que se liberó.
Como se ha visto, el evitar los interbloqueos no requiere la adquisición de todos los recursos
de una vez, ni tampoco necesita la expropiación de recursos. Los recursos son solicitados como
y cuando se necesitan. Esto elimina el problema de la inactividad de los recursos debido a
un adquisición prematura, que aparece con frecuencia en otras estrategias de prevención de
interbloqueos. Una de sus desventajas, de evitar los interbloqueos requiere que los procesos
soliciten previamente sus recursos e impone recargos de almacenamiento y tiempo de cómputo
para detectar los estados inseguros del sistema.
La estrategia de evitar interbloqueos tiende a ser conservadora y por lo tanto, reduce la
concurrencia en los sistemas donde se utiliza y puede posponer innecesariamente la asignación
de recursos disponibles a procesos que los solicitan.
2.4.11.3. Detección y recuperación de interbloqueos
Varios sistemas operativos, en vez de sacrificar el rendimiento previniendo o evitando los in-
terbloqueos, conceden libremente los recursos disponibles a los procesos solicitantes y comprue-
ban ocasionalmente el sistema para determinar si existen interbloqueos con el fin de reclamar
los recursos retenidos por los procesos involucrados, si es que existen.
Se ha demostrado que la existencia de un ciclo (o un circuito) en un grafo general de re-
cursos es una condición necesaria para la existencia de interbloqueo. La existencia de un ciclo
del cual ninguno de los nodos que lo forman sale un camino que no sea ciclo, es condición
suficiente para la existencia de interbloqueos en un grafo general de recursos. De este modo la
existencia de interbloqueos puede determinarse mediante el uso de algoritmos muy conocidos
para la determinación de ciclos en grafos. El método más común es intentar reducir el grafo
general de recursos suprimiendo todas las retenciones y peticiones de cada proceso cuyas soli-
citudes puedan ser concedidas, hasta que se efectúen todas las reducciones posibles. Si el grafo
queda completamente reducido (no quedan arcos) después de esta operación, el estado del siste-
ma no presenta interbloqueos. En otro caso, existirán procesos o (nodos con arcos) que son los
involucrados en el interbloqueo.
Cuando un algoritmo de detección determina que existe un interbloqueo, se tienen varias
alternativas. Una de ellas es informar al operador que se ha producido un interbloqueo y dejar
que lo trate manualmente. Otra posibilidad es dejar que sea el sistema el que haga la recuperación
del interbloqueo de forma automática. Existen dos opciones para romper un interbloqueo. Una
de ellas consiste en interrumpir uno o más de los procesos bloqueados.
Terminación de procesos Para eliminar un interbloqueo interrumpiendo uno o más procesos

, se puede utilizar cualquiera de los dos siguientes métodos:
Interrumpir todos los procesos bloqueados. Este método interrumpirá todos los procesos in-
volucrados en el interbloqueo, pero el costo será muy alto. Es posible que varios procesos
hayan invertido ya mucho tiempo de ejecución y hecho cálculos que deben reiniciarse
después de que se ponga en marcha nuevamente el proceso.
Interrumpir un proceso por vez. Este método requiere una gran cantidad de trabajo extra, por
que después de haber interrumpido un proceso, es necesario llamar al algoritmo de detec-
ción de interbloqueos.
Este método, en general no toma en cuenta los potenciales daños que pueden ocasionarse al
sistema de archivos por una actualización incorrecta o a la pérdida de consistencia en los datos
por una actualización no llevada a término adecuadamente. Decidir qué proceso debe eliminarse
no es una cuestión sencilla. Es común establecer una métrica desde un punto de vista de coste
mínimo, no obstante ser algo difícil de precisar. Dentro de los factores que se consideran pueden
ser:
1. La prioridad del proceso.
2. Tiempo que lleva en ejecución el proceso.
3. Qué tipo de recursos ha usado y durante cuánto tiempo.
4. Cuántos recursos adicionales requiere para terminar.
5. Cuántos procesos tendrán que eliminarse para que pueda continuar.
6. En interactivos o procesamiento por lotes.
Apropiación de recursos Con este método el sistema operativo va quitando recursos a los
procesos y asignándolos a otros hasta que se interrumpa el interbloqueo. Para llevar a cabo esta
estrategia es necesario tomar en cuenta lo siguiente.
1. Selección de un proceso a eliminar. El sistema debe seleccionar un proceso con un re-
curso determinado que ayude a eliminar el interbloqueo.
2. Anulación. ¿Qué debe hacerse con el proceso al que se le expropió el recurso? Este pro-
ceso debe suspenderse y colocarlo en un estado tal que pueda reanudar sus operaciones
cuando las condiciones lo permitan.
3. Inanición. El sistema debe asegurarse de que al proceso al que se le expropiaron los

recursos, pueda continuar su ejecución en un tiempo finito a partir del momento de la
expropiación.
122 2.5. NIVELES, OBJETIVOS Y CRITERIOS DE PLANIFICACIÓN
2.5. Niveles, objetivos y criterios de planificación

N este capítulo se analizarán las diversas formas de administrar el tiempo de la CPU. Cuando
E tenemos una sola CPU, entonces se puede atacar el problema de la ejecución de muchos
procesos organizándolos serialmente, ya sea por como van llegando, por tiempo aproximado
de ejecución o para que se ejecuten solamente un determinado tiempo en la CPU Todos estos
algoritmos son la base para el desarrollo de los sistemas operativos multiprogramación.
2.5.1. Planeación de trabajos

La administración del CPU es una de las tareas más importantes en los sistemas operativos
con multiprogramación. Mediante la conmutación de la CPU entre distintos procesos, el sistema
operativo puede hacer que la computadora sea más productiva y darle al usuario la sensación
de que tiene un equipo de cómputo dedicado. En este capítulo se analizarán las técnicas de ad-
ministración del procesador más comunes usadas en los sistemas operativos actuales. Ya hemos
hablado en el capítulo 2 de cómo es que se administran los procesos y los hilos. En este capítulo
se hablará de los diferentes algoritmos utilizados para poder distribuir el tiempo de la CPU entre
los diferentes procesos y los hilos.
2.5.2. Conceptos básicos de planificación

En una computadora de un solo procesador solamente puede ejecutarse un proceso cada
vez, cualquier otro proceso tendrá que esperar hasta que la CPU se desocupe para que pueda
tomar el control otro proceso y si el que se estaba ejecutando necesita ejecutarse nuevamente
debe entonces ser replanificado. El objetivo de un sistema multitarea o multiprogramación es
tener continuamente varios procesos en ejecución con el fin de maximizar el uso de la CPU. El
concepto básico es muy sencillo: un proceso se ejecuta hasta que tenga que esperar, normalmente
porque es necesario completar alguna solicitud de entrada/salida. En una computadora de un
solo procesador, la CPU permanece inactiva la mayor parte del tiempo y todo ese tiempo de
espera se desperdicia y no se realiza ningún trabajo útil. Con la multitarea o multiprogramación
se intenta usar ese tiempo de forma productiva. En este caso se mantienen varios procesos en
memoria a la vez. Cuando un proceso tiene que esperar, el sistema operativo retira el uso de la
CPU a ese proceso y se lo cede a otro proceso. Este ciclo se repite continuamente y cada vez
que un proceso tiene que esperar, otro proceso puede hacer uso de la CPU. Este es el trabajo
fundamental del sistema operativo; casi todos los recursos de la computadora se planifican antes
de usarlos. Por supuesto, la CPU es uno de los principales recursos de la computadora, así que
su correcta planificación resulta crucial en el diseño del sistema operativo.
2.5.2.1. Ciclos de CPU y ciclos de entrada/salida
Una planificación adecuada de la CPU depende de una propiedad observada de los procesos:
la ejecución de un proceso consta de un ciclo de ejecución en la CPU, seguido de una espera de
entrada/salida; los procesos alternan entre estos dos estados. La ejecución del proceso comienza
con una ráfaga de CPU. Esta va seguida de una ráfaga de entrada/salida, a la cual sigue otra
ráfaga de CPU, luego otra ráfaga de entrada/salida. la ráfaga final de la CPU concluye con una
solicitud al sistema para terminar la ejecución.
La duración de las ráfagas de CPU se ha medido exhaustivamente en la práctica. Aunque
varían enormemente de un proceso a otro y de una computadora a otra, tienden a presentar
una curva de frecuencia que es de tipo exponencial o hiperexponencial, con un gran número de
ráfagas de CPU cortas y un número menor de ráfagas de CPU largas. Normalmente, un programa
limitado por la entrada/salida presenta muchas ráfagas de CPU cortas. Esta distribución puede
ser importante en la selección de un algoritmo apropiado para la planificación de la CPU.
2.5.3. Niveles de planificación

Cuando la CPU queda inactiva, el sistema operativo debe seleccionar uno de los procesos
que se encuentran en la cola de procesos preparados para ejecución. En general existen tres
diferentes tipos de planificadores mediante los cuales puede escogerse al siguiente proceso a
ejecutarse. Estos diferentes tipos de planificadores pueden coexistir en un sistema operativo
complejo. Éstos son: planificadores a largo plazo, a mediano plazo y a corto plazo. Estos a su
vez se pueden caer dentro de dos tipos de planificación planificación apropiativa y planificación
no apropiativa
2.5.3.1. Planificación apropiativa
El sistema operativo debe de decidir qué proceso es el que entrará a la CPU en cualquiera de
los siguientes casos:
1. Cuando un proceso cambia del estado de ejecución al estado de espera.
2. Cuando un proceso cambia del estado de ejecución al estado preparado.
3. Cuando un proceso cambia del estado de espera al estado preparado.
4. Cuando finaliza un proceso.

124 2.5. NIVELES, OBJETIVOS Y CRITERIOS DE PLANIFICACIÓN
En las opciones 1 y 4 sólo hay una opción en términos de planificación que es la de selec-
cionar un nuevo proceso para su ejecución. En las opciones 2 y 3 existe la opción de planificar
un nuevo proceso o no.
Cuando las decisiones de planificación tienen lugar en las circunstancias 1 y 4, se dice que
el esquema de planificación es no apropiativo. Esto es, el sistema operativo no podrá obtener la
CPU a menos que el proceso la entregue voluntariamente. En el esquema apropiativo el sistema
operativo obtendrá el control de la CPU en el momento que considere necesario. En Microsoft
windows 3.x se usaba un esquema no apropiativo, mientras que en windows 95 se cambió por
un esquema apropiativo y actualmente la mayoría de los sistemas operativos comerciales usan
un esquema apropiativo.
2.5.4. Objetivos y criterios de planificación

Se ha propuesto una gran diversidad de criterios para comparar los algoritmos de planifi-
cación y aquellos que se utilicen pueden afectar enormemente las bondades o fortalezas de los
algoritmos que se comparen. Dentro de los muchos criterios utilizados a continuación se pro-
porciona una lista de los más comunes:
Tiempo de respuesta. En sistemas multiusuario de de tiempo real es importante que el

sistema operativo sea capaz de responder lo suficientemente rápido como para no notar
que se están compartiendo los recursos.
Utilización de CPU. La CPU debe de estar ocupada el mayor tiempo posible haciendo
tareas útiles. Es común medir su ocupación en términos de porcentajes. esto es, en un
sistema real la utilización de la CPU debe variar entre un 40 por ciento para un sistema
desahogado y un 90 por ciento para un sistema cargado. Ir abajo de este límite indica
que la CPU está siendo desaprovechada y arriba del 90 por ciento indica que no se está
excediendo la capacidad de respuesta del sistema.
Tiempo de ejecución. Desde el punto de vista de un proceso individual, el criterio im-

portante es cuanto tarda en ejecutarse un proceso. El intervalo que va desde el instante en
que se ordena la ejecución de un proceso hasta el instante en que se completa el tiempo de
ejecución. Ese tiempo de ejecución es la suma de los períodos que el proceso invierte en
esperar para cargarse en memoria, esperar en la cola de procesos preparados, ejecutarse
en la CPU y realizar sus operaciones de entrada/salida.
Tasa de procesamiento. Es el número de procesos que se completan por unidad de tiem-

po. Para procesos que tardan mucho puede ir en intervalos de horas o procesos por hora.
En procesos que se ejecutan rápido esta tasa puede hasta de diez o más procesos por se-
gundo.
Tiempo de espera. Es el tiempo transcurrido entre el envío de una solicitud al sistema

operativo para ejecutar un programa y hasta que éste entregue los primeros resultados. Es
común que este tiempo de respuesta esté afectado principalmente por las operaciones de
entrada/salida que por la velocidad de la CPU.
2.6. Técnicas de administración del planificador

Los diferentes algoritmos de planificación de la CPU tienen distintas propiedades, y la elec-
ción de un algoritmo es particular puede favorecer a una clase de procesos sobre otros. Al mo-
mento de decidir qué algoritmo se debe de utilizar en una situación particular, se debe considerar
las propiedades de diferentes algoritmos.
De acuerdo a lo visto hasta ahora el objetivo principal es la maximización del uso de tiempo
de la CPU y por lo tanto, elevar la tasa de procesamiento, minimizando el tiempo de espera y el
tiempo de respuesta.
2.6.1. Tipos de planeación

La planificación hace referencia a un conjunto de políticas y mecanismos incorporados al
sistema operativo que gobierna el orden en que se ejecutan los trabajos que deben ser ejecutados
por la computadora.
Como se comentó en la sección 2.5.3 existen tres tipos de planificadores: planificadores a
corto, mediano y largo plazo. Ahora nos dedicaremos a analizar estas formas de planificación.
2.6.1.1. Planificador a largo plazo
Cuando se implementa este tipo de planificador, y el sistema operativo usa procesamiento

por lotes, trabaja con la cola de lotes y selecciona el siguiente trabajo por lotes a ejecutar. Los
trabajos por lotes están generalmente reservados a programas de baja prioridad y de uso intensivo
de recursos y que comúnmente son utilizados como relleno para tener ocupada a la CPU. Los
trabajos por lotes tienen además un conjunto de recursos necesarios para llevar a cabo su tarea
previamente especificados por el programador, lo que facilita la tarea de planificación del mismo.
El principal objetivo del planificador a largo plazo es proporcionar una mezcla equilibrada
de trabajos, de modo que puedan satisfacerse sus requerimientos de procesador y de tiempo de
entrada/salida de modo que pueda proporcionar esta planificación al planificador de corto plazo.
126 2.6. TÉCNICAS DE ADMINISTRACIÓN DEL PLANIFICADOR
El planificador de largo plazo actúa como una válvula de admisión de primer nivel para mante-
ner la utilización de recursos al nivel deseado. Por ejemplo, cuando la utilización del procesador
es baja, el planificador puede admitir más trabajos para incrementar el número de procesos que
se hallen en la cola de preparados, y con ello la probabilidad de disponer de alguna operación
útil que espere asignación de procesador. En caso contrario, si se observa que el procesador está
en un porcentaje alto de utilización entonces el planificador puede decidir bajar el número de
procesos seleccionados para ejecución, de modo que el procesador pueda responder mejor a to-
dos los trabajos que se están ejecutando. El planificador a largo plazo es generalmente mandado
a traer cuando un proceso finaliza su ejecución.
2.6.1.2. Planificador a mediano plazo
Cuando un proceso se ha ejecutado durante algún tiempo, puede resultar que debe suspen-
derse debido a una solicitud de entrada/salida o al emitir una llamada al sistema. Dado que los
procesos suspendidos no pueden progresar hacia su terminación hasta que se elimine la condi-
ción de suspensión, en ocasiones es conveniente retirarlos de memoria principal de modo que
el sistema pueda acomodar otros procesos que estén listos para ejecutarse. Cuando una serie de
estos procesos resultan estar en el estado de suspendidos y todos ellos permanecen en memoria
llegará el momento en que el sistema operativo no tendrá opción para elegir un proceso para
ejecución sabiendo, obviamente que están suspendidos esperando una señal de terminación de
operación de entrada/salida, lo que ocasionaría una degradación significativa del tiempo de res-
puesta del sistema frente a otros procesos que sí pueden ejecutarse. cuando un proceso se lleva
desde memoria principal hasta la memoria secundaria, se dice que el sistema tiene soporte de
memoria virtual. A esta operación se le denomina intercambio y al proceso que se eliminó de
memoria se le denomina retirado. El planificador a medio plazo tiene la misión de manejar los
procesos retirados, y tiene poco que hacer mientras un proceso permanezca suspendido. Cuando
desaparece la condición de suspensión, el planificador a medio plazo intenta asignarle la canti-
dad necesaria de memoria principal, de modo que pueda incorporarse a la memoria principal y
dejarlo en el estado de preparado. La información que necesita para trabajar este planificador es
la cantidad de memoria que usa el proceso al regresar a la memoria y la cantidad de memoria
que ocupan los procesos suspendidos, lo que en la práctica no es difícil de implementar.
2.6.1.3. Planificador a corto plazo
El planificador a corto plazo asigna el procesador entre el conjunto de procesos preparados

residentes en memoria. Su objetivo principal es maximizar el rendimiento del sistema de acuerdo
con el conjunto de criterios elegidos.
Al estar a cargo de las transiciones de estado de preparados a ejecución, el planificador a

corto plazo debe ser invocado en cada conmutación de proceso para seleccionar el siguiente
proceso a ser ejecutado por la CPU. En un sistema operativo real, el planificador a corto plazo
es invocado también cuando sucede un evento externo, interno o cuando ocurre una señal o
una interrupción. Esto es debido a que cualquiera de los eventos mencionados anteriormente
puede causar que un proceso sea suspendido o haya pasado al estado de preparado, de modo que
el planificador a corto plazo tendría que ser ejecutado para determinar si realmente ocurrieron
tales cambios y de esta forma, verificar si es necesario seleccionar un nuevo proceso para su
ejecución. Algunos sucesos que tienen la capacidad de modificar el estado global del sistema
son:
Tics de reloj (Interrupciones basadas en el tiempo).
Interrupciones y terminaciones de operaciones de entrada/salida.
La mayoría de las llamadas al sistema operativo.
El envío y recepción de señales.
La activación de programas interactivos.
En general cada vez que sucede uno de estos eventos el sistema operativo invoca al plani-
ficador a corto plazo para determinar si debería planificarse otro proceso para su ejecución. La
mayoría de las tareas de administración de procesos analizados en la sección 2.1 requieren que
se mande a llamar al planificador a corto plazo como parte de su procesamiento.
Los programas interactivos suelen entrar a la cola de preparados directamente después de
ser remitidos al sistema operativo, lo que ocasiona la creación del proceso correspondiente. A
diferencia de los trabajos por lotes, el flujo de programas interactivos no está limitado, y puede
supuestamente saturar el sistema.
La figura 2.5 ilustra objetivamente los papeles y la interacción entre los diferentes tipos de
planificadores en un sistema operativo. Muestra el caso más general en donde están presentes
los tres tipos. Es claro que de todos los planificadores pueden convivir en un sistema operativo
grande y que puede dar soporte a una gran empresa, pero en un sistema operativo pequeño
y posiblemente de uso personal puede que solamente tenga un planificador a corto plazo. El
planificador a mediano plazo lo podemos encontrar en sistemas operativos que tienen soporte
de memoria virtual para poder hacer el intercambio de procesos a disco. En la actualidad la
mayoría de los sistemas operativos comerciales usan algún tipo de memoria virtual, por ejemplo,
los sistemas operativos basados en UNIX/Linux usan un área de intercambio que está definida
desde el momento de la instalación del sistema operativo. Es un área llamada swap y los usuarios
Figura 2.5: Ubicación de los planificadores
no tienen derecho a escribir en ella. Los basados en windows XX, XP o vista normalmente
toman parte de la capacidad del disco no usada por el usuario como área de intercambio, por
lo que se debe tener cuidado de dejar siempre varios megabytes (por lo común el doble de
memoria principal) para que el sistema operativo pueda funcionar sin problemas. No obstante
el usuario puede guardar información en todo el disco duro, de esa forma la memoria virtual
va disminuyendo hasta que sea incapaz de trabajar normalmente, siendo un error oscuro por
resolver, debido a que el usuario determinará que es el sistema operativo el que está funcionando
mal, no obstante, como se comentó, el problema se soluciona dejando libres varios megabytes
para que el sistema operativo lo use como memoria virtual.
2.6.1.4. First In First Out (FIFO)
La disciplina de planificación más sencilla es la FIFO o la FCFS (First-Come, First-Served)

o primero en llegar, primero en ser atendido. La carga de trabajo se procesa simplemente en
orden de llegada, sin expropiaciones. La implementación del planificador FIFO es bastante di-
recta, y su ejecución da lugar a pocos recargos.
Por no tener en consideración el estado del sistema ni las necesidades de recursos de las
entidades de planificación individuales, la planificación FIFO puede dar lugar a rendimientos
pobres. Como consecuencia de la no expropiación, la utilización de componentes y la tasa de
productividad del sistema puede ser bastante baja. Como no existe discriminación en base al
servicio solicitado, los trabajos cortos pueden sufrir retrasos considerables en los tiempos de
retorno y de espera cuando hay uno o más trabajos largos en el sistema. Por esta razón, el
tiempo medio de espera con el algoritmo FIFO es frecuentemente muy grande.Vamos a suponer
que el siguiente conjunto de procesos llega en el instante 0, estando la duración de la ráfaga de
la CPU especificada en milisegundos:
Proceso Tiempo de Ráfaga

P1 25
P2 4
P3 4
Figura 2.6: Tiempos totales de ejecución de los procesos
en la figura 2.6 observamos que de acuerdo al orden de llegada de los procesos P1 , P2 y

P3 el planificador los ejecutará en ese orden dando como resultado que el proceso P1 espere 0
segundos, el proceso P2 , tiene que esperar 25 milisegundos, y el proceso P3 espera 29 milise-
gundos. El tiempo promedio es entonces (0 + 25 + 29)/3 = 18 milisegundos. Si el orden de
llegada fuera P2 , P3 y por último P1 entonces el tiempo promedio de espera es para P2 de 0
milisegundos, para P3 será de 4 milisegundos y para P1 es entonces de 8 milisegundos dando
entonces un promedio de espera total de (0 + 4 + 8)/3 = 4 milisegundos. como puede verse en
la figura 2.7.
Figura 2.7: Tiempos totales de ejecución de los procesos
Como puede observarse, hay una drástica reducción del tiempo medio de espera, pero no
es generalmente el mínimo y puede variar significativamente si la duración de las ráfagas de
CPU de los procesos es muy variable. Depende mucho de la duración de los procesos y puede
llegarse el momento en que haya tantos procesos de corta duración esperando a que termine
uno de larga duración, lo que ocasiona una utilización menor de la CPU y de los dispositivos
de entrada/salida que la que se conseguiría si se permitiera a los procesos más cortos ejecutarse
primero.
2.6.1.5. Round Robin (RR)
En entornos interactivos, tal como en sistemas de tiempo compartido, el requisito principal

es compartir los recursos del sistema equitativamente entre todos los usuarios. Como puede
verse, sólo las estrategias expropiativas pueden ser consideradas en tales entornos, y una de las
más populares es la reparto de tiempo. Bajo esta estrategia, el tiempo del procesador se divide
en cuantos de tiempo. Un grupo de cuantos de tiempo forma la cuota que se le concede a cada
proceso. Ningún proceso puede ejecutarse durante más de una cuota de tiempo si es que hay más
procesos en el sistema. Si un proceso necesita más tiempo para completarse después de agotar su
cuota de tiempo, se coloca al final de la lista de preparados para esperar una asignación posterior.
Esta reordenación de la lista de preparados tiene el efecto de rebajar la prioridad de planificación
del proceso expropiado. En la figura 2.8 podemos ver cómo el proceso Px va al final de la cola
cuando ha terminado su cuota de tiempo.
Figura 2.8: Funcionamiento del algoritmo Round Robin
En el caso de que el proceso en ejecución ceda el control al sistema operativo antes de acabar
su tiempo asignado, se declara un suceso significativo y se planifica la ejecución de otro proceso.
De esta manera, el tiempo del procesador es asignado efectivamente a procesos en ase a una
prioridad rotatoria y cada uno de ellos recibe aproximadamente 1/N de tiempo del procesador
en donde N es el número de procesos preparados.
La planificación por reparto del tiempo logra una compartición equitativa de los recursos
del sistema. Los procesos cortos pueden ser ejecutados dentro de una única cuota de tiempo
y por tanto exhiben buenos tiempos de respuesta. Los procesos largos pueden requerir varias
cuotas y por tanto, ser forzados a circular a través de la cola de preparados unas cuantas veces
antes de terminar. con la planificación RR, el tiempo de respuesta de los procesos largos que
constan de una serie de secuencias interactivas con el usuario, lo que importa principalmente es
el tiempo de respuesta entre dos interacciones consecutivas. Si las necesidades computacionales
entre dos de tales secuencias pueden completarse dentro de una sola cuota de tiempo, el usuario
debería experimentar un buen tiempo de respuesta. RR tiende a someter a los procesos largos sin
secuencias interactivas a tiempos de espera y de retorno relativamente largos. Sin embargo, tales
procesos pueden ser mejor ejecutados en modo lote, y podría ser incluso deseable desaconsejar
a los usuarios que los remitan al planificador interactivo.
La implementación de la planificación por reparto de tiempo requiere el soporte de un tem-
porizador de intervalos -preferiblemente uno dedicado, en lugar de compartir la base de tiempos
del sistema-. El temporizador se programa generalmene para que interrumpa al sistema operati-
vo cada vez que expire una cuota de tiempo forzando así la invocación del planificador. El propio
planificador almacena simplemente el contexto del proceso en ejecución, lo translada al final de
cola de preparados y despacha el proceso que se encuentre a la cabeza de la cola de preparados
El planificador también es invocado para despachar un nuevo proceso cada vez que el proceso
en ejecución cede el control al sistema operativo antes de que expire su cuota de tiempo, por
ejemplo, cuando el procesos se suspende debido a una solicitud de entrada/salida. El temporiza-
dor de intervalos es generalmente reinicializado en ese momento, con el fin de proporcionar un
intervalos de tiempo completo al nuevo proceso en ejecución. La frecuente inicialización y re-
inicialización de un temporizador de intervalos dedicado hace deseable la existencia de soporte
de hardware en sistemas que utilizan cuotas de tiempo.
El rendimiento de la planificación por reparto del tiempo es muy sensible a la elección de
la cuota del tiempo. Por esta razón, la duración de la cuota de tiempo suele ser modificable por
el usuario durante la compilación o instalación del sistema operativo, aunque en los sistemas
operativos actuales esta tarea se deja solamente a usuarios administradores avanzados.
La relación entre la cuota de tiempo y el rendimiento es pronunciadamente no lineal. La re-
ducción de la cuota no debería ser llevada demasiado lejos tratando de alcanzar mejores tiempos
de respuesta. Una cuota demasiado corta puede dar lugar a significativos recargos debido a las
frecuentes interrupciones del temporizador y consiguientes cambios de contexto de los procesos
involucrados. Por ejemplo, una cuota de dos milisegundos en un sistema donde una conmuta-
ción de proceso tarda quinientos microsegundos supone un recargo del veinticinco por ciento.
Por otra parte, una cuota de tiempo demasiado larga reduce el recargo por expropiación pero
aumenta el tiempo de respuesta. Por ejemplo, una cuota de 100 milisegundos en un sistema con
50 usuarios activos implica un molesto tiempo de respuesta de 5 segundos. En el extremo, una
cuota muy larga transforma un planificador RR en un planificador FIFO.
En resumen, la planificación por reparto del tiempo se utiliza principalmente en sistemas
multiusuario de tiempo compartido en donde es importante el tiempo de respuesta de terminal.
La planificación por reparto de tiempo penaliza generalmente a los trabajos largos no inter-
activos y depende de la elección juiciosa de la cuota de tiempo para obtener un rendimiento
adecuado. La duración de una cuota de tiempo es un parámetro ajustable del sistema que puede
ser modificado durante la compilación o instalación del sistema operativo.
2.6.1.6. Shortest Job First (SJF)
Otro método de planificación de la CPU es el algoritmo de planificación con selección del

trabajo más corto. Este algoritmo asocia con cada proceso la duración de la siguiente ráfaga de
CPU del proceso. Cuando la CPU está disponible, se asigna al proceso que tiene la siguiente
ráfaga de CPU más corta. Si las siguientes ráfagas de CPU de dos procesos son iguales, se usa
la planificación FIFO para romper el empate. Considérese el siguiente conjunto de procesos,
estando especificada la duración de la ráfaga de CPU en milisegundos.
Proceso Tiempo de Ráfaga

P1 11
P2 8
P3 9
P4 7
Usando SJF, los procesos quedarían como se muestra en la figura 2.9. Para el proceso P4 el
tiempo de espera es de 0 milisegundos. El tiempo de espera es de 7 milisegundos para el proceso
P3 , para el proceso P2 es de 15 milisegundos y para el proceso P1 es de 24 milisegundos. Por lo
tanto, el tiempo medio de espera es de (0 + 7 + 15 + 24)/4 = 15,3 milisegundos. Si se usara el
esquema de planificación FIFO el tiempo promedio de espera sería (0 + 11 + 19 + 28)/4 = 19,3
milisegundos.
El algoritmo de planificación es probablemente óptimo, en el sentido de que proporciona
el tiempo medio de espera mínimo para un conjunto de procesos dado. Anteponer un proceso
corto a uno largo disminuye el tiempo de espera del proceso corto en mayor medida de lo
que incrementa el tiempo el tiempo de espera del proceso largo. Por lo tanto, el tiempo medio
de espera disminuye. El principal problema de la estrategia SJF es conocer la duración de la
siguiente solicitud de CPU. En una planificación a largo plazo de trabajos en un sistema de
Figura 2.9: Organización para ejecutar los cuatro procesos con SJF
procesamiento por lotes, podemos usar como duración el límite de tiempo del proceso que el
usuario especifique en el momento de enviar el trabajo. Con este mecanismo, los usuarios están
motivados para estimar el límite de tiempo del proceso en forma precisa, dado que el valor
menor puede significar una respuesta más rápida.
Aunque el algoritmo SJF es óptimo , no puede implementarse en el nivel de la planificación
de la CPU a corto plazo, ya que no hay manera de conocer la duración de la siguiente ráfaga de
la CPU directamente. No obstante, se puede predecir su valor por el método de confiar en que
la siguiente ráfaga de CPU será similar en duración a las anteriores. De este modo, calculando
una aproximación de la duración de la siguiente ráfaga de CPU, se puede tomar el proceso que
tenga la ráfaga de CPU predicha más corta.
2.6.1.7. Shortest Remaining Time (SRT)
La estrategia de planificación en seguida el de menor tiempo restante es aquella en la que

la siguiente entidad de planificación, trabajo o proceso, se selecciona sobre la base del menor
tiempo de ejecución restante. La planificación SRT puede ser implementada ya sea en forma
expropiativa en su versión no expropiativa. La versión no expropiativa de SRT se denomina SJF
vista en la sección anterior. En cualquier caso, cada vez que e invoca al planificador SRT, éste
busca en la correspondiente cola (de lotes o de preparados) el trabajo o proceso con el menor
tiempo de ejecución restante. La diferencia entre los dos casos se encuentra en las condiciones
que conducen a la invocación del planificador y, en consecuencia, en su frecuencia de ejecución.
Sin expropiación, el planificador SRT es invocado cada vez que se completa un trabajo o que el
proceso en ejecución cede el control al sistema operativo. En la versión expropiativa, cada vez
que ocurre un suceso que hace que un nuevo proceso esté preparado, se invoca al planificador
para que compare el tiempo de ejecución restante del proceso actualmente en ejecución con el
tiempo necesario para completar la siguiente ráfaga de procesador del proceso recién llegado.
Dependiendo del resultado, el proceso en ejecución puede continuar o puede ser expropiado
y substituido por el proceso con tiempo restante más corto. Si es expropiado, el proceso en
ejecución se une a la cola de preparados.
LA estrategia SRT es óptima en el sentido de que minimiza el tiempo medio de espera de

una carga de trabajo determinado. La estrategia SRT se efectúa de una manera consistente y
predecible, favoreciendo los trabajos cortos. Añadiendo la expropiación, puede acomodar tra-
bajos cortos que lleguen después de comenzar un trabajo largo. El tratamiento preferencial de
los trabajos cortos en SRT tiende a aumentar los tiempos de espera de los trabajos largos en
comparación con FIFO, pero en general es un costo aceptable.
SRT planifica óptimamente suponiendo que los tiempos futuros de ejecución de los trabajos
o procesos son conocidos con exactitud en el momento de la planificación. En el caso de la
planificación a corto plazo y de las expropiaciones, se requiere un conocimiento incluso más
detallado de la duración de cada ráfaga de procesador individual. La dependencia sobre el
conocimiento futuro tiende a limitar en la práctica la efectividad de las implementaciones SRT,
ya que en general el comportamiento futuro del proceso es desconocido y difícil de estimar
fiablemente, excepto para algunos casos determinados muy especializados.
La planificación SRT tiene importantes implicaciones teóricas y puede servir como referen-
cia para valorar el rendimiento de otras disciplinas de planificación realizables en términos de
su desviación con respecto al óptimo. En la práctica su aplicación depende de la precisión de
predecir el comportamiento del trabajo y del proceso, sabiendo que aumentar la precisión su-
pone emplear métodos más sofisticados y por tanto, producir un sobrecargo mayor. La variedad
expropiativa de SRT incurre en el recargo adicional de las frecuentes conmutaciones de procesos
y de invocaciones al planificador para examinar todas y cada una de las transiciones de procesos
al estado de preparado. Estas acciones son inútiles cuando el nuevo proceso preparado tiene un
tiempo de ejecución restante mayor que el de los procesos en ejecución actual.
2.6.1.8. Highest Response Ratio Next (HNR)
Brinch Hansen desarrolló la estrategia de prioridad a la tasa de respuesta más alta (HNR,
highest-response-ratio-next) que corrige algunas deficiencias de SJF, particularmente el retraso
excesivo de trabajos largos y el favoritismo excesivo para los trabajos cortos. HRN es un disci-
plina de planificación no apropiativa en la cual la prioridad de cada proceso no sólo se calcula
en función del tiempo de servicio, sino también del tiempo que ha esperado para ser atendido.
Cuando un trabajo obtiene el procesador, se ejecuta hasta terminar. Las prioridades dinámicas
en HNR se calculan de acuerdo con la siguiente expresión:
prioridad = (tiempo de espera + tiempo de servicio)/tiempo de servicio
Como el tiempo de servicio aparece en el denominador, los procesos cortos tendrán prefe-
rencia. Pero como el tiempo de espera aparece en el numerador, los procesos largos que han
esperado también tendrán un trato favorable. Obsérvese que la suma tiempo de espera mas el
tiempo de servicio es el tiempo de respuesta del sistema para el proceso si éste se inicia de
inmediato.
2.6.2. Multiprocesamiento
El objetivo principal de los desarrolladores de hardware de procesadores es el incremento
de velocidad de proceso. La velocidad de proceso puede incrementarse básicamente de dos
maneras:
Incremento de la velocidad de reloj. Incrementando el número de ciclos del reloj del proce-
sador, es posible también incrementar la velocidad de ejecución de las microinstrucciones
y por ende también las instrucciones máquina. No obstante, el principal problema es que
a mayor velocidad de reloj se produce un calentamiento mayor de los circuitos y se incre-
menta también la posibilidad de interferencias. Deben de resolverse estos problemas antes
de pensar en un incremento de velocidad de reloj.
Agregar más procesadores de baja velocidad al sistema. La otra posibilidad es la de agregar

más procesadores a la placa base de modo que pueda ejecutarse el “doble” de instrucciones
en el mismo sistema. Los problemas que se presentan ahora son para el sistema operativo
que debe de administrar los procesos que se van a ejecutar en cada procesador.
2.6.3. Conceptos básicos

Como se comentó en 2.6.2, existen dos maneras de incrementar la velocidad. La primera
tiene límites tecnológicos obvios, en cuanto al incremento de la velocidad de reloj y el diseño
de los componentes de la placa base.
Al agregar un mayor número de procesadores es posible incrementar la velocidad de proce-
samiento con una relación de costo/beneficio más favorable.
2.6.3.1. multiprocesador
Se define como una computadora que contiene dos o más unidades de procesamiento que tra-
bajan sobre una memoria común bajo un sistema operativo que proporciona control integrado.
Si el sistema de multiprocesamiento posee procesadores de las mismas características, habla-
mos entonces de multiprocesamiento simétrico; de otra forma se habla de multiprocesamiento
asimétrico.
Si un procesador falla, los restantes continúan operando, lo cual no es automático y requiere
de un diseño cuidadoso. Un procesador que falla habrá de informarlo a los demás de alguna
manera, para que se hagan cargo de su trabajo . Los procesadores en funcionamiento deben
poder detectar el fallo de un procesador determinado. El Sistema Operativo debe percibir que
ha fallado un procesador y ya no podrá asignarlo y también debe ajustar sus estrategias de
asignación de recursos para evitar la sobrecarga del sistema que está degradado.
El multiprocesamiento puede proporcionar las siguientes ventajas:
Aumento de productividad. Pueden ejecutarse tantos procesos como procesadores tenga

el sistema en paralelo, incrementando de esta forma el tiempo de respuesta.
Disminuir el tiempo de ejecución de un proceso. Mediante el uso de técnicas de mul-

tiprogramación es posible dividir un proceso en varias tareas independientes que pueden
ejecutarse en paralelo.
En entornos multiusuario, la productividad puede aumentarse ejecutando una serie de proce-

sos de usuario no relacionados entre sí sobre diferentes procesadores corriendo en paralelo. Así
aunque no se incrementa la velocidad de ejecución de un proceso, sí es posible mejorar la pro-
ductividad al terminar un mayor número de tareas por unidad de tiempo, no habiendo necesidad
de modificar las aplicaciones de usuario para adecuarlo a un sistema multiprocesamiento. La
ganancia de velocidad para una aplicación en particular involucra modificar la aplicación para
poder ejecutar en paralelo aquellas tareas que sean independientes entre sí, siendo entonces res-
ponsabilidad de los programadores la comunicación entre estas tareas, para llevar a buen término
la tarea global encomendada. Estas tareas pueden implementarse de las formas vista en las sec-
ciones 2 y en la sección 2.3, esto es, pueden crearse varios procesos en donde cada uno resuelve
una parte del problema o pueden crearse también varios hilos para atacar más eficientemente el
problema.
Hay fuertes investigaciones en cuanto a la automatización de estas tareas y el resultado
de estas investigaciones es en parte los llamados compiladores paralelizantes que ayudan a
encontrar aquellos conjuntos de instrucciones que no dependen de otras y que son susceptibles
de ejecutarse en paralelo.
Como puede verse, la otra forma es permitir al programador que indique cuales son aquellas
tareas que deben de ejecutarse en paralelo y cuáles son las que deben de ejecutarse en serie.
Las diferentes partes de una aplicación paralelizada necesitan generalmente sincronizarse e
intercambiar datos después de completar una etapa de cálculo. La comunicación y sincroniza-
ción entre los procesadores reduce la ganancia de velocidad global al frenar cálculos individuales
y consumir mucho de banda de interconexión del sistema. Uno de los principales retosen el di-
seño de sistemas multiprocesadores es la reducción de las interacciones entre procesadores y
proporcionar un mecanismo eficiente para llevarlas a cabo cuando sean necesarias.
2.6.4. Paralelismo
El paralelismo consiste en ejecutar más instrucciones en una misma unidad de tiempo, aun-
que las instrucciones sigan tardando lo mismo en ejecutarse. Estas instrucciones le dicen al
procesador cómo tiene que ir modificando diferentes posiciones de memoria, y le indican el flu-
jo de ejecución. Se tiende a pensar, que un procesador con un reloj a 400 MHz (400 millones de
ciclos por segundo) ejecuta 400 millones de estas operaciones por segundo. Por lo común una
instrucción no se ejecuta en un ciclo de reloj, salvo algunas instrucciones sencillas como la ins-
trucción INC sobre un registro interno. La mayoría de las instrucciones tardan en promedio de
5 a 15 ciclos, llegando algunas a necesitar 50 o más ciclos para completarse, como por ejemplo
aquellas instrucciones que llevan a cabo operaciones con números reales de doble precisión o
aquellas instrucciones utilizadas en el manejo de vídeo, por ejemplo en juegos.
2.6.5. Paralelismo por hardware

Es aquella en la que la ejecución de un programa se lleva a cabo tomando en consideración
el hardware con que va a ser ejecutado.
Un procesador incluye dentro de su arquitectura una manera de ejecutar más eficientemente
sus instrucciones. En general lo primero que debe de hacer es traer de memoria la instrucción
que va a ejecutar. A este proceso se le denomina fetch. Cuando ya ha traído la instrucción de
memoria, ahora sí ya pasa a su ejecución, pero mientras está ejecutando la instrucción, el módulo
de fetching está obteniendo una nueva instrucción y depositándola en la cola de instrucciones. Si
el procesador efectúa una instrucción de salto, entonces las instrucciones que se encuentran en
la cola deben ser borradas y el módulo de fetching empezará nuevamente a traer las siguientes
instrucciones a ejecutar.
Como se puede apreciar, tenemos ya dentro de un procesador al menos dos módulos que
trabajan en paralelo, el módulo de fetching y la unidad de ejecución. De esta manera, Se puede
dividir cualquier instrucción en fases más o menos comunes a todas: fetch (traer la instrucción
desde la memoria al procesador), decodificación (determinar la instrucción que se va a ejecutar),
carga de operandos, ejecución de la operación y modificación de los registros o las localidades de
memoria afectadas, así como el registro de banderas en donde se guarda el estado del procesador.
Este esquema simplificado, proporciona una idea de las fases que todo microprocesador tiene.
Vamos a suponer un microprocesador ideal donde todas las operaciones que se pueden ejecutar
en él tardan 15 ciclos, correspondientes a tres ciclos por cada una de las 5 fases que hemos
descrito. Si ejecutáramos tres de estas operaciones sin ningún tipo de paralelismo, tardaríamos
45 ciclos, según el siguiente esquema:
Instrucción Ciclos de Ejecución

Mov AX,Arreglo[20] 111222333444555
Add AX,Arreglo[21] 111222333444555
Mov AX,Arreglo[22] 111222333444555
Ahora dividamos el microprocesador en circuitos independientes de modo que cada uno
pueda ejecutar cada una de las cinco fases anteriores. Así, cuando la instrucción uno ha acabado
ya la fase de fetch y pasa a la decodificación, deja libre el módulo que se encarga del fetch,
donde puede estar ejecutándose la segunda instrucción. Así se ahorra tiempo y no se neceesita
esperar a que se termine de ejecutar una instrucción antes de traer otra a la unidad de ejecución.
Resultado: las tres instrucciones, por separado, siguen ejecutándose en el mismo tiempo, pero
en conjunto ya no tardan 45 ciclos, sino solo 21 ciclos. Más de un 45 % de incremento en el
rendimiento.
Instrucción Fetch Decodificación Carga Ejecución Resultados
Mov AX,Arreglo[20] 111 222 333 444 555
Fetch Decodificación Carga Ejecución Resultados
Add AX,Arreglo[21] 111 222 333 444 555
Fetch Decodificación Carga Ejecución Resultados
Mov AX,Arreglo[22] 111 222 333 444 555
De esta forma es como algunos procesadores muy paralelizados logran ejecutar, en prome-
dio, más de una instrucción por ciclo de reloj, aunque estas instrucciones tarden, por sí mismas,
más de un ciclo en ejecutarse. En la realidad, no todo es sencillo y existen muchos problemas
al diseñar un procesador con paralelismo. Por citar algunos de los problemas más comunes, hay
veces que una instrucción no se puede ejecutar ya que requiere un dato que quizás calculaba la
operación anterior (cosa muy habitual). Claro, si ante este problema detuviéramos la anterior
instrucción, bloquearía el procesador y se acabaría el paralelismo hasta que acabara la primera
instrucción y con ella se pudiera reanudar la segunda. Para evitar estos problemas se recurre a
cortocircuitos, o lo que es lo mismo, se comunican diferentes fases del microprocesador inter-
namente para pasarse antes los datos. Esto, sin embargo, también nos da otros problemas, ya
mucho más complicados, como el encontrarnos con que hay que decidir que datos son los co-
rrectos en cada momento. Estos problemas se pueden resumir en que el procesador ha de decidir
como paralelizar las instrucciones.
2.6.5.1. Paralelismo por software
En el paralelismo por software ya no es el procesador el que decide cómo paralelizar las ins-
trucciones, sino que es el compilador del software es el que decide qué conjunto de instrucciones
puedeejecutar el procesador paralelamente.
Se define paralelismo en software como la ejecución de un programa sin tomar en cuenta
al hardware con que va ser ejecutado. El paralelismo en software es considerado como el caso
ideal de la ejecución de las instrucciones que forman parte de un programa, ya que no toma en
cuenta las limitantes del hardware con que el mismo va ser ejecutado.
El paralelismo en Software representa el caso ideal con que dicho programa puede ser eje-
cutado. Por otro lado podemos observar las limitantes que genera la ejecución de este mismo
programa con un hardware en particular (procesador Superescalar con capacidad de ejecutar
un acceso a la memoria y una operación aritmética simultáneamente) obteniendo 6 ciclos de
maquina para ejecutar el programa. Tomando como base este ejemplo, la ejecución paralela de
las instrucciones de un programa se mide mediante el parámetro conocido como Promedio de
Ejecución Paralela de instrucciones (PEP). Este parámetro está definido como la relación entre
el número de instrucciones del programa y el número de ciclos de máquina realizados en su
ejecución. Su expresión matemática es: PEP = No. de Instrucciones / No. de Ciclos de Máquina.
Por consiguiente, el promedio de ejecución paralela de instrucciones en software para este
ejemplo es: 8/3 = 2,667 y el promedio de ejecución paralela de instrucciones en hardware es:
8/6 = 1,333.
El desarrollo de hardware y software es un proceso integral que busca soluciones que permi-
tan satisfacer cada vez más las condiciones de paralelismo con el fin de incrementar el promedio
de ejecución paralela de instrucciones. Para lograr este objetivo es necesario detectar y resolver
las dependencias entre instrucciones. El proceso de detección y resolución de dependencias entre
instrucciones se conoce como el proceso de planificación de instrucciones. Cuando la planifica-
ción de instrucciones es llevada a cabo únicamente por el compilador se dice que la planificación
de instrucciones es estática. Y cuando la planificación de instrucciones es llevada a cabo única-
mente por hardware, se dice que la planificación de instrucciones es dinámica. La planificación
de instrucciones en los microprocesadores súper escalares es un proceso de planificación de
instrucciones estático y dinámico.
Las técnicas estáticas de planificación de instrucciones están compuestas por tres grupos:
Planificación de instrucciones de bloques de un programa. Divide un programa en bloques

para luego detectar y resolver solamente las dependencias entre las instrucciones de cada
bloque. Esta técnica es la más utilizada en los últimos veinte años ya que es la más simple
de implementar.
Planificación de instrucciones de lazos iterativos continuos. Consiste planificar las instruc-

ciones que forman parte de los lazos continuos de un programa. Esta técnica está com-
puesta básicamente por dos técnicas: Unrolling y Software Pipeline.
planificación de instrucciones global. Planifica todas las instrucciones que forman parte de un
programa.
2.6.6. Sistemas multiprocesamiento

Un sistema multiprocesador, es una computadora que tiene soporte para más de un procesa-
dor.
Cuando se han colocado dos procesadores en la misma placa base, hablamos entonces de
procesamiento dual. Por ejemplo, el procesador Pentium MMX, Pentium II, Pentium III con
núcleo Katmai o Coppermine, Pentium III-S de Intel y el Athlon MP de AMD pueden funcionar
en modo dual. Para que puedan trabajar los dos procesadores se necesita tener una placa base y
un sistema operativo que permita explotar estas configuraciones por ejemplo tenemos a Windows
NT/2000/XP o Linux. Las aplicaciones también deben de estar diseñadas de manera que puedan
aprovechar el aumento de velocidad. No pueden combinarse procesadores de formatos diferentes
en una misma placa base, deben utilizarse siempre dos variantes con el mismo formato.
Es común que en multiprocesamiento se combinen los procesadores en potencias de dos.
Tenemos multiprocesamiento cuando se utilizan más de dos procesadores juntos en un mis-
mo sistema. El Pentium Pro, Pentium II/III Xeon, Xeon (basado en Pentium 4) y el Itanium de
Intel, así como el Opteron de AMD, están especialmente diseñados para el multiprocesamiento
y pueden trabajar en grupos de dos, cuatro, ocho y más.
En la figura 2.10 puede verse cómo se organiza la placa madre para dar cabida a cuatro
procesadores.
Figura 2.10: Placa base para cuatro CPU’s

Sólo pueden emplearse uno, dos, cuatro o más procesadores de distintos tipos en una placa
si todos ellos están diseñados para el procesamiento dual o multiprocesamiento. Además los re-
querimientos de disipación de calor o de refrigeración aumentan con el número de procesadores.
Intel ha presentado una nueva tecnología llamada HyperThreading Pentium 4 a partir de 3,06
GHz y el Xeon a partir de 2,4 GHz. El HyperThreading consiste en que dentro del procesador
se tienen dos procesadores lógicos. Algunos sistemas operativos pueden ejecutarse más rápido
así como algunas aplicaciones de software. No obstante, el incremento de velocidad no es tan
elevado como en el caso de un sistema dual con dos CPU’s físicas.
Tanto Intel como AMD han desarrollado ya la tecnología de los llamados procesadores de
doble núcleo. Estos procesadores tienen colocados dos núcleos de procesador completos dentro
de un mismo recubrimiento que cuente con una conexión para el socket de la placa base. Este
truco técnico ofrece las prestaciones de un sistema dual en una placa base que sólo tiene un
socket (se requiere que sea compatible con el sistema operativo).
A principios del 2007 Intel lanzó al mercado procesadores cuádruples y AMD los hizo a
mediados del mismo año. El problema principal es que la tecnología del software tarda más en
aprovechar toda esa potencia de cómputo.
Los sistemas basados en Linux tienen soporte actualmente hasta para 16 procesadores y
Solaris puede soportar hasta 256 procesadores.
Los sistemas operativos de microsoft, por ejemplo windows XP tiene soporte solamente has-
ta dos procesadores, y su última versión windows vista tiene soporte hasta cuatro procesadores
en versiones domésticas o pequeñas empresas, pero puede soportar 8 o hasta 32 procesadores
en el servidor avanzado y en el servidor de centro de datos, aunque básicamente es el mismo
núcleo.
Sin embargo, tanto Intel como AMD planean sacar al mercado procesadores con 8 procesa-
dores para el siguiente año.
2.6.6.1. Ventajas de los sistemas multiprocesadores
Las principales ventajas de los sistemas de multiprocesamiento incluyen:
Crecimiento modular. Puede adquirirse una placa base que soporte varios procesadores
con sólo uno e ir adquiriendo los demás a medida que vayan aumentado las exigencias de
cómputo.
Tolerancia a fallos. Si algún procesador deja de funcionar, el rendimiento se degrada,

pero el sistema continuará trabajando,
Rendimiento. Si tenemos una aplicación diseñada para explotar el paralelismo, ésta podrá
ejecutarse mucho más rápido.
Relación Costo/Beneficio.los procesadores comerciales son mucho más baratos, que los
de una súper computadora. Así, podemos encontrar diferentes configuraciones multipro-
ceso de acuerdo a las necesidades de cómputo.
2.6.6.2. Clasificación de los sistemas multiprocesadores
Existen diversas categorías para los sistemas multiprocesadores. Flynn [40] introdujo un es-
quema general para clasificar a las arquitecturas de computadora de acuerdo a cómo la compu-
tadora relaciona sus instrucciones con los datos a procesar. Así define los siguientes grupos:
SI. Single Instruction (Una sola instrucción).
MI. Multiple Instruction (Múltiples instrucciones).
SD. Single Data (Operación sobre un solo dato).
MD. Multiple Data (Operación sobre múltiples datos).
Con estas definiciones puede hacerse la siguiente clasificación:
SISD. Flujo de una sola instrucción con flujo de un solo dato. Incluye a las computadoras
serie convencionales.
SIMD. Flujo de una sola instrucción, Flujo de múltiples datos. Se refiere a los típicos
procesadores vectoriales y a los arreglos de computadoras en donde una sola instrucción
puede operar sobre diferentes datos en unidades distintas de ejecución.
MISD. Flujo de múltiples instrucciones con flujo de un solo dato. Esta organización casi
no se utiliza, pero básicamente sería aquella en la que múltiples instrucciones operan sobre
un único flujo de datos, lo que puede compararse con las técnicas de acceso concurrente.
MIMD. Flujo de múltiples instrucciones con flujo de múltiples datos. La ejecución simul-
tánea de múltiples instrucciones que operan sobre varios flujos de datos.
Los sistemas MIMD, se basan en la relación entre procesadores y memoria, los multiproce-
sadores se pueden clasificar bajo este enfoque es:
Sistemas multiprocesadores Fuertemente acoplados. Los multiprocesadores contienen

memoria globalmente compartida a la que todos los procesadores tienen acceso.
Sistemas multiprocesadores débilmente acoplados. Los procesadores individuales tie-

nen memorias privadas y no existe una memoria global compartida.
Esta división no es muy estricta y podemos encontrar sistemas que manejen tanto memoria
compartida como memoria privada. La memoria compartida es esencial para la comunicación
y sincronización entre procesadores en sistemas fuertemente acoplados. Estos sistemas se han
distinguido por tener un mayor ancho de banda y menores retardos en sus rutas de interconexión.
En los sistemas débilmente acoplados puros, el mecanismo principal de comunicación entre
procesadores es el paso de mensajes. En el pasado éstos estaban caracterizados por un reducido
ancho de banda y por retardos elevados en sus rutas de interconexión.
Las configuraciones híbridas y algunos sistemas débilmente acoplados permiten a los proce-
sadores acceder a una memoria no local e incluso a la memoria privada de otros procesadores.
Existe generalmente una penalización por acceder a la memoria no local en forma de retardos
añadidos provocados por el arbitraje de contención y el paso a través de las rutas de intercone-
xión procesador-memoria. Estos factores dan lugar a la siguiente clasificación de los sistemas
multiprocesadores de memoria compartida en base a la arquitectura de la memoria y los retardos
de acceso.
Acceso uniforme a memoria. (UMA, Uniform memory access). Sistemas en donde los
procesadores pueden acceder a toda la memoria disponible con la misma velocidad; esto
incluye muchas arquitecturas con bus compartido.
Acceso no uniforme a memoria. (NUMA nonuniform memory access). Sistemas en don-

de existe una diferencia de tiempo en el acceso a diferentes áreas de memoria, dependien-
do de la proximidad a un determinado procesador y la complejidad del mecanismo de
conmutación entre el procesador y la sección referenciada de la memoria del sistema. En
ocasiones de le añade a esta clasificación una tercera categoría denominada acceso no
remoto a memoria (NORMA no remote memory access).
2.6.7. Organización del multiprocesador

En esta sección haremos una descripción básica de los tipos de multiprocesador más comu-
nes incluyendo:
Sistemas orientados a bus.
Sistemas conectados por barras cruzadas.
Hipercubos.
Sistemas basados en conmutadores multicapa.
Los sistemas multiprocesadores se caracterizan por los siguientes aspectos:
1. Un multiprocesador contiene dos o más procesadores con capacidades aproximadamente

comparables.
2. Todos los procesadores comparten el acceso a un almacenamiento común y a canales de

Entrada / Salida, unidades de control y dispositivos.
3. Todo está controlado por un Sistema Operativo que proporciona interacción entre pro-
cesadores y sus programas en los niveles de trabajo, tarea, paso, archivo y elementos de
datos.
2.6.7.1. Sistemas orientados a bus.
Uno de los modos más sencillos de construir un multiprocesador es utilizar un bus compar-
tido para conectar procesadores y memorias. En la figura 2.11 podemos ver el esquema básico
del método de bus compartido.
Figura 2.11: Organización de un sistema multiprocesador orientado a bus
El bus común es en esencia una unidad pasiva. Un procesador o procesador de Entrada/Salida

que desee transferir datos debe efectuar los siguientes pasos:
1. Verificar que el conductor no esté ocupado y que esté disponible la unidad de destino.
2. Avisar a la unidad destino de lo que se va a hacer con los datos.
3. Comenzar la transferencia de datos.
Las unidades receptoras deben poder reconocer qué mensajes del bus son enviados hacia
ellas y confirmar las señales de control recibidas de la unidad emisora.
Una multitud de procesadores pueden comunicarse unos con otros y con la memoria global-
mente compartida a través de un bus compartido. Puede haber muchas variantes de este esquema
básico: los procesadores individuales pueden o no disponer de memoria privada. Los dispositi-
vos de entrada/salida pueden estas conectados a procesadores individuales o al bus compartido y
la propia memoria compartida se implementa generalmente en forma de múltiples bancos físicos
conectados al bus compartido.
Se deben tener en cuanta dos aspectos importantes: El propio bus y la memoria compartida.
Para disminuir los tiempos de contención es común que se use una memoria caché entre la
memoria compartida y cada procesador. De esta forma la mayoría de las referencias pueden
ser resueltas por la memoria caché y hacer un menor uso del bus común. Si no hay memoria
caché puede llegar a haber una saturación del bus y los tiempos de espera pueden llegar a ser
intolerables en un sistema con mucho tráfico entre los procesadores y la memoria.
Si los procesadores usan memoria caché entonces teóricamente existe una proporción de
aciertos del 90 %, lo que podría permitir a un bus compartido de la misma velocidad soportar
diez veces el número de procesadores que se soportarían si no existiera la memoria caché.
Es una organización económica, simple y flexible pero con una sola vía de comunicación,
por lo cual pueden generarse los siguientes problemas.
El sistema falla totalmente si falla el bus.
La tasa neta de transmisiones está limitada por la tasa neta de transmisión del conductor.
La contención por el uso del bus en un sistema sobrecargado puede ocasionar una seria
degradación.
Debe de mantenerse la coherencia de la caché de modo que múltiples copias físicas de una
sola localidad de memoria contengan los mismos valores en las cachés correspondientes.
2.6.7.2. Sistemas de Barras Cruzadas e Interruptores
La conmutación por barra cruzada es la única fuente de retardo entre un procesador y una
memoria. Si los procesadores no tienen memorias privadas, el sistema resultante es un multipro-
cesador con acceso uniforme a memoria (UMA).
En este caso existe un camino diferente para cada unidad de almacenamiento, por lo cual las
referencias a dos unidades diferentes de almacenamiento no son bloqueantes sino simultáneas y
la multiplicidad de caminos de transmisión puede proporcionar tasas de transferencia muy altas.
Figura 2.12: Conexión mediante barra cruzada
El esquema de barras cruzadas permite un elevado grado de paralelismo entre tareas no

relacionadas, pero la contención de memoria es probable si la sincronización entre procesos y
entre procesadores está basada en memoria compartida.
La barra cruzada requiere N 2 conmutadores de punto de cruce para conectar completamente
N puntos con otros N puntos, tales como procesadores y memorias. El crecimiento cuadrático
de la complejidad con el número de componentes hace que las barras cruzadas sean costosas y
limiten la escalabilidad de los sistemas resultantes.
En la figura 2.12 se observa cómo se implementa este tipo de conexión. La propia barra
cruzada no tiene contención. Permite el acceso simultáneo de N procesadores a N memorias,
supuesto que cada procesador acceda a una memoria diferente. La barra es el opuesto al bus
común.
2.6.7.3. Hipercubos
La topología de hipercubos afronta cuestiones de escalabilidad y costos cuyas complejidad

de conexiones crece logarítmicamente. En general la topología de un hipercubo, puede repre-
sentarse en tres dimensiones con un cubo, y en cada vértice se coloca un nodo, dando en total
ocho. En la figura 2.13 vemos cómo se representa este hipercubo.
Figura 2.13: Hipercubo con ocho nodos
Aunque son posibles otras distribuciones, el sistema multiprocesador dibujado en la figura

2.14 está construido con nodos formados por un procesador y su memoria privada. El resultado
es un multiprocesador tipo NORMA, que es una implementación bastante común de hipercubo.
Los hipercubos tienen una serie de interesantes propiedades matemáticas. Por ejemplo, cada
procesador de un hipercubo tiene enlaces físicos directos con log2 N nodos en un sistema de N
nodos. La máxima distancia entre dos nodos cualesquiera, medida como el número de enlaces
físicos entre nodos, es también log2 N . Los hipercubos son estructuras recursivas en el sentido
de que los hipercubos de dimensiones mayores contienen hipercubos de dimesiones menores
como subconjuntos propios. Por tanto un hipercubo complejo puede particionarse en una serie
de hipercubos más simples de dimensión menor. en el ejemplo del sistema dibujado en la figura
2.14, para N = 8; cada nodo tiene enlaces directos con log2 8 = 3 otros nodos, la máxima
distancia entre nodos es 3, y el sistema puede particionarse en dos hipercubos bidimensionales
disjuntos de tres modos distintos.
Los hipercubos proporcionan una buena base para sistemas escalables, ya que su compleji-
dad crece logarítmicamente con el número de nodos. Al mismo tiempo, la comunicación entre
nodos adyacentes es directa y el mayor retardo entre nodos está acotado por log2 N . Los hiper-
cubos son adecuados para muchos problemas que encajan fácilmente en su estructura, específi-
camente aquellos que se apoyan en la recursión o que exhiben localidad de referencias en forma
Figura 2.14: Conexiones entre procesadores
de afinidad para comunicación con nodos adyacentes. los hipercubos están considerados como
una prometedora base para el multiprocesamiento a gran escala.
Las implementaciones hipercubo de principios de los noventa tienden a incorporar memorias
privadas en cada procesador. La arquitectura NUMA resultante dicta el paso de mensajes como
mecanismo primario de comunicación y sincronización entre procesadores. Además de efectuar
el procesamiento, los nodos individuales manejan generalmente protocolos de comunicación.
También se encargan de encaminar y entregar mensajes externos para formar rutas de comuni-
cación. También se encargan de encaminar y entregar mensajes externos para formar rutas de
comunicación indirectas ente nodos remotos directamente conectados unos a otros. Los dispo-
sitivos de entrada/salida pueden estar asociados localmente a nodos individuales. Para aumentar
el ancho de banda de entrada/salida, algunas implementaciones disponen de nodos inteligentes
de entrada/salida dedicados que actúan como fuentes y depositarios de los flujos de datos de
entrada/salida para grupos de nodos.
2.6.7.4. Sistemas basados en conmutadores multietapa
Los procesadores y las memorias de un sistema multiprocesador pueden conectarse por me-
dio de un conmutador multietapa. Existen muchas variantes de este método. Una forma gene-
ralizada de este tipo de interconexión proporciona enlaces entre N entradas y N salidas. Tiene
m = log2 N etapas. Cada etapa consta de un conjunto de N enlaces conectad a N/2 cajas de
intercambio.
Las redes de conmutación multietapa proporcionan una forma de conmutación de circuito.
Existe un breve tiempo para la preparación de la interconexión, pero una vez establecida, se
aprovecha todo el ancho de banda, y es deseable transferir bloques de memoria grandes de
modo que una sola preparación pueda aprovecharse mejor.
El conmutador multietapa puede conectar simultáneamente todas las entradas a todas las
salidas, suponiendo que no haya dos procesadores que intente acceder al mismo módulo de
memoria al mismo tiempo. En caso contrario, puede aparecer contención en los módulos de
memoria y dentro de la red de conmutación lo que hace que el tráfico descienda.
El almacenamiento en búferes dentro de la red de conmutación o en la memoria puede aliviar
parte de la contención, pero no puede hacer desparecer los puntos calientes de los módulos
de memoria. Un punto caliente ocurre cuando algunos módulos de memoria son referenciados
frecuentemente por una serie de procesadores. Es obvio que solamente un procesador puede
tener acceso al módulo de memoria y los restantes deben esperar su turno. El problema es que
ese punto caliente puede también bloquear otras rutas de otros módulos de memoria durante
largos largos períodos de tiempo, afectando en consecuencia la capacidad de otras entradas y
salidas no relacionadas para establecer conexiones.
2.6.8. Sistemas operativos del multiprocesador

Cuando surgen nuevas tecnologías emergentes, el estímulo de las primeras investigaciones y
las implementaciones de los primeros multiprocesadores se dedican la demostración de concep-
tos. Los principales objetivos de investigación eran las arquitecturas y los modos de explotar el
paralelismo para aumentar la velocidad.
Debido a la relativa falta de experiencia y al limitado uso de los multiprocesadores queda
mucho trabajo por realizar en cuanto al desarrollo e implementación de los principios sobre la
metodología de diseño para sistemas operativos en multiprocesadores. Los tres tipos básicos de
sistemas operativos multiprocesadores son:
1. Supervisores separados. Cada nodo tiene un sistema operativo autónomo que administra
el procesador local, la memoria y los recursos de entrada/salida
2. Maestro/esclavos. Un procesador se dedica a ejecutar el sistema operativo y los restantes

procesadores son generalmente idénticos y forman un depósito de procesadores compu-
tacionales.
3. Simétrico. Todos los procesadores son funcionalmente idénticos. Todos los recursos están
disponibles para todos los procesadores. Si sólo algunos procesadores tienen acceso a
algunos recursos entonces se habla de un sistema asimétrico.
2.6.8.1. Supervisores separados
Los sistemas supervisores separados, tienen nodos que contienen un sistema operativo inde-
pendiente que administra el procesador local, la memoria y los recursos de entrada/salida. En
su forma rudimentaria este método administra efectivamente cada procesador como un sistema
independiente. Sólo hay que añadir unos pocos servicios y estructuras de datos adicionales para
soportar los aspectos multiprocesadores del hardware. Tales implementaciones de supervisores
separados ofrecen poca capacidad de equilibrio de cargas y raramente soportan el paralelismo
dentro de las aplicaciones.
2.6.8.2. Maestro/Esclavos
En este método, un procesador se dedica a ejecutar el sistema operativo. los demás proce-
sadores comúnmente son idénticos y están disponibles para ejecutar las tareas que les asigne
el procesador maestro. El procesador maestro, planifica las tareas y controla la actividad de los
esclavos. Casi todas las estructuras de datos concernientes al sistema operativo las controla el
procesador maestro y las almacena en su memoria privada. Los procesadores esclavos pueden
ser capaces de procesar directamente algunas consultas locales simples, pero la mayoría de los
servicios del sistema operativo son proporcionados por el procesador maestro.
Esta disposición permite el paralelismo dentro de una aplicación mediante la asignación a
ella de múltiples esclavos. No obstante, poco o ningún paralelismo es posible para el sistema
operativo, ya que éste se ejecuta en un solo procesador.
Los temas maestro/esclavo son relativamente fáciles de desarrollar e implementar. Aña-
diéndole la planificación de esclavos a un sistema operativo monoprocesador serie se puede
adaptar con bastante facilidad para que pueda operar como un sistema multiprocesador maes-
tro/esclavos. El problema principal con este enfoque es su poca escalabilidad, puesto que con
muchos procesadores el sistema operativo ejecutándose en un solo procesador se vuelve un cue-
llo de botella.
2.6.8.3. Simétrico
En esta arquitectura, todos los procesadores son funcionalmente idénticos. El sistema opera-
tivo también es simétrico en el sentido de que cualquier procesador puede ejecutarlo. En teoría,
la organización simétrica permite la ejecución paralela del sistema operativo en varios proce-
sadores. A este extremo, el sistema operativo necesita ser codificado en forma de una serie de
tareas autónomas, y tienen que existir los cerrojos adecuados para acceder a estructuras de datos
compartidas.
En la forma más sencilla de organización simétrica, la conocida como maestro flotante, el
sistema operativo es más o menos una única sección critica de grandes dimensiones. En respues-
ta a los requisitos de la carga de trabajo y la disponibilidad de procesadores, el sistema operativo
se ejecuta en diferentes procesadores en instantes diferentes. Bajo esta organización, el procesa-
dor en donde se ejecuta el sistema operativo actúa como maestro en el sentido de que se encarga
de planificar las tareas para los demás procesadores. Así el sistema operativo no está ligado a
ningún procesador y flota de un procesador a otro.
Como ejemplo podemos hablar un poco del sistema operativo Solaris. La Arquitectura avan-
zada de este sistema operativo incluye multiprocesamiento totalmente simétrico (SMP) y mul-
tithreading sofisticado (MT). El SMP/MT acelera el rendimiento del sistema al permitir que dife-
rentes aplicaciones puedan ejecutarse en múltiples procesadores concurrentemente. Así mismo,
SUN implementa un kernel de multithreading sin quebrar las interfaces del SVR4. El Kernel
de multithreading le asigna "multithreading.al hardware; esto es, muchos procesos pueden eje-
cutarse paralelamente en diferentes CPU’s incrementando el rendimiento del sistema; muchas
aplicaciones pueden beneficiarse con esto, incluyendo manejadores de bases de datos.
La multitarea significa que el sistema operativo puede realizar varias tareas al mismo tiempo.
El multiprocesamiento simétrico permite sacar toda la ventaja de los procesadores múltiples. El
multiprocesamiento asimétrico (en donde un microprocesador se dedica exclusivamente a una
tarea específica), da lugar a que un microprocesador permanezca inactivo en cuanto finaliza su
tarea. En el multiprocesamiento simétrico, el sistema operativo puede asignar diferentes tareas
a un mismo procesador; así, si uno de ellos termina su trabajo antes que otro, el sistema ope-
rativo podrá ocuparlo en otra actividad. El multiprocesamiento simétrico es bastante difícil de
implementar, pero ofrece un rendimiento muy superior. Cabe mencionar que la característica de
multithreading sólo se presenta en equipos de arquitectura Sun4m, Sun4d y Sun4u.
2.7. Problemas
2.1. Defina con sus propias palabras qué es un proceso.
2.2. Describa brevemente los estados de un proceso.
2.3. Dibuje un diagrama que indique las transiciones de un proceso.
2.4. ¿Qué es la concurrencia?

152 2.7. PROBLEMAS
2.5. Proporcione cinco ejemplos de la vida real en donde esté presente la concurrencia.
2.6. ¿Qué problemas se presentan en la concurrencia?
2.7. ¿De qué manera evitaría los problemas de concurrencia de la pregunta anterior?
2.8. ¿Cómo definiría la sección crítica?
2.9. Proporcione cinco ejemplos de la vida real en la que se presente algo parecido a la
sección crítica (Solamente una entidad puede estar haciendo uso de un recurso en un
solo momento).
2.10. ¿A qué se refiere la exclusión mutua?
2.11. Explique las formas para garantizar la exclusión mutua.
2.12. ¿Quién inventó los semáforos? Defina con sus palabras un semáforo.
2.13. ¿Qué es un monitor?
2.14. Señale las ventajas y desventajas de un monitor con respecto a un semáforo.
2.15. ¿Para qué sirven los mensajes?
2.16. Describa las operaciones típicas de los mensajes.
2.17. ¿Es posible garantizar la exclusión mutua por medio de mensajes? Explique su res-
puesta.
2.18. ¿Qué es una interrupción?
2.19. ¿Por qué es necesario el bloqueo de recursos?
2.20. Defina qué es un interbloqueo.
2.21. ¿Cuáles son las condiciones para que se dé un interbloqueo?
2.22. ¿En qué recursos no es posible que se dé un interbloqueo y en cuáles sí es posible?

Explique.
2.23. ¿Cómo se previenen los interbloqueos? Explique.
2.24. ¿Es posible que un sistema operativo no apropiativo pueda evitar un interbloqueo?
Sustente su respuesta.
2.25. ¿Qué tan correcto es terminar un proceso para romper un interbloqueo? Explique.
2.26. Investigue las formas en las que los sistemas operativos comerciales enfrentan el pro-
blema de interbloqueo.
2.27. Explique el concepto de espera circular.
2.28. ¿Cuando sabemos que el sistema se encuentra en “estado seguro”?
2.29. Suponga que usted es el encargado de determinar la existencia de interbloqueos. ¿Bajo

qué condiciones indicaría que existe un interbloqueo?
2.30. Explique las ventajas y desventajas de que el sistema operativo se apropie de los recur-
sos que tiene asignados un proceso.
2.31. Defina qué es un trabajo(job).
2.32. ¿Qué es un ciclo de instrucción?, ¿Qué es un ciclo de reloj?,¿Cuál es la diferencia?
2.33. Defina qué es un ciclo de entrada/salida.
2.34. ¿Por qué surgió la necesidad de planificar el tiempo de CPU?
2.35. Explique las dos estrategias generales de planificación de CPU.
2.36. Explique los criterios de planificación. ¿Cuáles piensa que son más importantes? .¿Por
qué?
2.37. Explique brevemente los tipos de planeación más utilizados.
2.38. ¿Qué tipo de planeación se considera óptimo?
2.39. ¿Cómo está constituido un sistema multiprocesador?
2.40. Defina los conceptos de multiprogramación, multitarea, tiempo compartido y multipro-

cesamiento.
2.41. Explique las diferencias clave entre los conceptos anteriores.
2.42. ¿Qué es paralelismo?
2.43. Explique las formas con las que se puede implementar el paralelismo.
2.44. Considerando la precedencia de operadores, escriba cinco ecuaciones y determine qué

operaciones pueden ejecutarse en paralelo.
154 2.7. PROBLEMAS
2.45. Obtenga el promedio de ejecución de las ecuaciones anteriores. Establezca sus propios
tiempos de ejecución para cada operación.
2.46. Defina un sistema operativo para multiprocesamiento.
2.47. ¿Qué ventajas y desventajas ofrecen los sistemas de multiprocesamiento?
2.48. Describa otras maneras de reducir el tiempo de ejecución de un proceso.
2.49. Mencione la clasificación de los sistemas multiprocesadores.
2.50. Describa brevemente los tipos de multiprocesador más comunes.
2.51. ¿Cuáles son las características de los sistemas multiprocesadores?
2.52. Describa la arquitectura orientada a bus. ¿Cuáles son sus ventajas y desventajas?
2.53. ¿Qué ventajas ofrece que cada procesador tenga su propia memoria caché?
2.54. ¿Qué desventajas tiene la arquitectura orientada a bus?
2.55. Describa la arquitectura de los sistemas de multiprocesamiento de barras cruzadas.
2.56. ¿Qué ventajas y desventajas presenta esta arquitectura?
2.57. Haga un diagrama que represente la arquitectura de multiporcesador usando hipercu-

bos.
2.58. Describa sus ventajas y desventajas.
2.59. Explique la arquitectura de un sistema multiprocesador basado en conmutadores mul-

ticapa.
2.60. ¿Cuáles son los tres tipos básicos de sistemas operativos multiprocesadores? Explique
cada uno de ellos.
2.61. ¿Cómo implementa Solaris el multiprocesamiento simétrico?
2.62. ¿Como definiría el multiprocesamiento asimétrico?


En Silberchatz[95] páginas 137-169 podemos encontrar los criterios y algoritmos más im-
portantes para la planificación de la CPU. Milenkovic[94] no separa la planificación de la CPU
e incluye estos algoritmos como parte de los procesos en las páginas 65 a la 94. Tanenbaum[98],
al igual que Milenkovic no presentan una separación entre procesos y la planificación del pro-
cesador, pero podemos ver en Tanenbaum[98, 101] a partir de la página 84 una descripción de
los algoritmos de planificación en Tanenbaum[101] lo denomina calendarizador de procesos.
En cuanto a la investigación sobre la planificación de procesos tenemos muchísimos trabajos
que hablan acerca de ella.
Chekuri[26] habla sobre algunos algoritmos de aproximación para problemas de planifica-
ción.
Chaitanya Swamy y Sachin Jain[97] explican algunos algoritmos de planificación
Laurent George, Nicolas Rivierre y Marco Spuri[41] desarrollaron una versión modificada
del algoritmo de asignación de prioridad óptimo propuesto por Audsley[9, 10], para planifica-
dores expulsivos y no expulsivos.
Yue[110], por su parte, aborda el tema de asignación dinámica de procesadores en el sistema
Solaris. Bogdan Caprita, Wong Chun Chan, Jason Nieh, Clifford Stein y Haoqiang Zheng[19]
hablan sobre el algoritmo de planificación Roun-Robin modificado con una tasa de grupo y
sobre la planificación proporcional compartida.
Ellard Roush[89] compara el desempeño del subsistema de procesos de un sistema operativo.
En la actualidad, ha cobrado mucha importancia el procesamiento masivamente paralelo.
Engels y Feldman [36] hablan sobre la planificación de procesadores paralelos con restricciones
de retardo.
El equipo de Emilia Rosti[88] habla sobre las planeación de políticas de ahorro de procesa-
dores para sistemas multiprocesador.
Audsley[9, 10] explica que la planificación de procesos es un problema difícil, pero que
la mayoría de las veces se simplifica imponiendo severas restricciones sobre las características
del tiempo proporcionado a cada proceso, e investiga qué tanto influye la asignación de tiempo
cuando ésta es menor al período asignado por el procesador.
Liu y James W. Layland[66] abordan los algoritmos de planificación en entornos de mul-
tiprogramación en ambientes de tiempo real y Damir Isovic[52] trata sobre una planificación
flexible para un entorno de tiempo real con recursos restringidos.
En los artículo de Ritchie[84, 83] podemos apreciar los comienzos del sistema operativo
UNIX.
Jochen Liedtke[65] justifica desde el punto de vista de tecnología del software que es mejor
la construcción de µ-kernels que los kernels monolíticos.

Hoare[48] describe las primitivas necesarias para la comunicación secuencial interprocesos.
Lampson [60] describe su experiencia al usar procesos y monitores con mesa.
Tevanian[103] explica la implementación de los hilos en el sistema operativo Mach y en
UNIX. David. L. Black[16] describe la planificación para el soporte de concurrencia y paralelis-
mo en el sistema operativo Mach
Feitelson[38] nos habla sobre la teoría y la práctica de la planificación de trabajos que co-
rren paralelamente (procesamiento paralelo). Blumofe[17] hace lo propio pero enfocado en a la
ejecución de programas con hilos o trheads.
Capítulo 3
Administración de Memoria
A memoria es uno de los componentes más importantes. En un sistema operativo multi-

L programación, el sistema operativo debe ser capaz de mantener muchos procesos en la
memoria de forma tal que pueda hacer un intercambio de contexto lo más rápido posible de
modo que el sistema aproveche más eficientemente el tiempo de CPU. Dicho de otro modo el
sistema operativo comparte la memoria entre varios procesos.
En este capítulo se hará un análisis de los diferentes algoritmos de administración de me-
moria y los cuales, muchas de las veces dependen de la arquitectura específica utilizada en el
hardware. Enumeraremos sus ventajas y desventajas y los diferentes factores que deben de te-
nerse en cuenta cuando se seleccione alguno de ellos para alguna implementación dentro de un
sistema operativo.
3.1. Política y filosofía

La administración de memoria se ocupa principalmente de la asignación de memoria física
de capacidad limitada a todo aquel proceso que la solicita. Incluso, la propia carga del proceso
en memoria es una solicitud de memoria que debe ser asignada previamente para poder acomo-
dar el código del proceso. Luego, se debe de proporcionar la memoria adicional para los datos
y para otros requerimientos propios del proceso. El administrador de memoria trabaja conjun-
tamente con el planificador, por ejemplo, cuando ya no queda más memoria por asignar, pero
existe un proceso que se encuentra en el estado de bloqueado, entonces el planificador podrá
removerlo de memoria y notificarle al administrador de memoria. Así, el administrador de me-
mora podrá entonces cumplir nuevos requerimientos, para incluso colocar otros procesos en el
espacio liberado previamente.
157
158 3.1. POLÍTICA Y FILOSOFÍA
3.1.1. Organización de la memoria

La memoria física principal de una computadora está compuesta de un arreglo de bytes
o de palabras de un tamaño específico. La cantidad de bytes o palabras a las que se puede
acceder depende en cierta forma de la capacidad de direccionamiento de la arquitectura de la
computadora. El tamaño del byte es estándar y comúnmente se refiere a 8 bits. No obstante, la
definición de una palabra puede variar de arquitectura a arquitectura y puede ir desde los 16,
32 ó 64 bits. Incluso en un futuro podríamos tener palabras de 128 o más bits. En la actualidad
con 64 bits para aritmética de enteros es más que suficiente para la mayoría de las aplicaciones
existentes. En la figura 3.1 podemos ver la organización general de una memoria típica.
Figura 3.1: Disposición general de la memoria física
Como se puede observar en la figura 3.1, una palabra es un múltiplo de un byte. Si el me-
canismo de direccionamiento cuenta con 16 bits entonces seremos capaces de acceder hasta 216
bytes. Si hablamos de palabras entonces habría un compromiso entre tener la posibilidad de
acceder también a bytes individuales de las palabras o exclusivamente a palabras. Si se da la
opción de acceder a bytes entonces la memoria tendrá solamente la mitad de palabras suponien-
do que sean de 16 bits. Esto es, solamente a 215 palabras. Si sólo podemos acceder a palabras
completas entonces existe la posibilidad de acceder a 216 palabras.
La unidad de memoria necesita entonces saber únicamente la dirección de la localidad de
CAPÍTULO 3. ADMINISTRACIÓN DE MEMORIA 159
memoria que se desea acceder, después de un breve tiempo tendremos disponible los bits al-
macenados en ella. La unidad de memoria no conoce el tipo de información que se guarda en
ella. Tan solo ve un flujo continuo de direcciones y regresa entonces para cada una los bytes o
palabras correspondientes. La unidad de control de la CPU es la encargada de determinar si la
información traída de memoria es una instrucción o un dato, dependiendo esto de los registros
que haya usado para indicar la dirección a la unidad de memoria. Como se vio en la sección
1.1.1.2. Existe un registro especial llamado PC Program Counter o contador de programa el
cual siempre indica la localidad de la memoria que contiene la siguiente instrucción a ser eje-
cutada. También cuenta con un conjunto de registros de direccionamiento que permiten apuntar
a las localidades de la memoria, y en arquitecturas que permiten multiprogramación existe tam-
bién un par de registros que indican la dirección base y la dirección límite a las cuales puede
tener acceso el programa ejecutándose actualmente en memoria. Como se puede ver, en realidad,
no interesa cómo es que se genera la dirección. El administrador de memoria debe solamente
administrar los bloques de memoria que se le soliciten.
3.1.2. Administrador de la memoria

El administrador de memoria es el encargado de crear y mantener un conjunto de estructuras
de datos y algoritmos para poder llevar el registro de la memoria que se solicita y de aquella que
se libera. Atendiendo, mediante solicitudes, todos los requerimientos tanto del sistema operativo
como de los procesos que estén ejecutándose en ese momento.
El administrador de memoria trabaja conjuntamente con los demás módulos del sistema
operativo, puesto que incluso, antes de cargar el sistema operativo el administrador de memoria
debe de asignar un espacio para poder alojar el núcleo del mismo. También cuando se hace
la solicitud de creación de un nuevo proceso, el sistema operativo hará una solicitud de un
bloque del tamaño adecuado al proceso al administrador de memoria. Si éste puede encontrar
un bloque que cumpla con lo solicitado, entonces el sistema operativo procederá a cargarlo de
disco y ponerlo en la cola de ejecución en el estado de listos. De otro modo no podrá crearse
el proceso y el sistema operativo mostrará un mensaje de error indicando la causa del fallo de
operación.
El administrador de memoria, las estructuras de datos y los algoritmos son muchas veces
dependientes del hardware.
La memoria principal y los registros del procesador son las únicas áreas de almacenamiento
a las que puede acceder la CPU para realizar su trabajo. El conjunto de instrucciones definido
para cada procesador, indican a la unidad de control los distintos modos de direccionamiento
que son soportados. En general, existen los siguientes:
1. Registro a registro. Se hace una operación que involucra los registros dentro de la propia
CPU.
2. Registro a memoria/Memoria a registro Se hace una operación que involucra una loca-
lidad de memoria, ya sea como fuente o como destino.
3. Directo a registro. Se hace una operación en donde el destino es un registro y la fuente

es un valor constante.
4. Directo a memoria. Se hace una operación con una localidad de memoria como des-
tino y un valor constante como fuente. Algunas arquitecturas no permiten este modo de
direccionamiento, y otras solamente es posible hacerlo en ciertas instrucciones.
5. Direccionamiento Directo. Es aquel en el cual se necesita especificar una dirección den-

tro de la propia instrucción.
6. Direccionamiento indirecto. La dirección se encuentra almacenada dentro de un registro

de la CPU. En algunas arquitecturas existen registros especializados para ello y en otras
todos los registros pueden funcionar con como registros indirectos en algunas o en todas
las instrucciones.
En arquitecturas que soportan la multiprogramación existen dos registros muy importantes

llamados registro base y registro límite, que como se comentó, mantienen el rango de direcciones
a las cuales tiene derecho a acceder el proceso que se encuentra ejecutándose actualmente. Si
en algún momento, el proceso sale fuera de este rango el hardware genera una interrupción
de violación de segmento y regresa el control al sistema operativo para corregir el problema o
eliminar al proceso que causó la violación, de modo que no pueda afectar a otros procesos a al
propio sistema operativo.
Algunas arquitecturas tienen también soporte de hardware para la administración de páginas,
que aparte de los registros base y límite permiten dividir el área de memoria en bloques de
tamaño fijo denominado páginas de memoria. El hardware al calcular la dirección generará un
número de página determinado y si en ese momento no se encuentra en memoria generará una
interrupción. Enseguida el administrador de páginas toma el control y si es necesario tendrá que
bajar algunas páginas a disco y reemplazarlos.
De acuerdo a la arquitectura de hardware, al administrador de memoria podrá implementarse
siguiendo uno o varios de los algoritmos que se verán en las siguientes secciones.
La utilización general de recursos y otros criterios de rendimiento de un sistema de compu-
tadora se ven afectados por el rendimiento del módulo de administración de memoria no sólo en
cuanto a su efectividad para asignar memoria, sino también como consecuencia de la influencia
e interacción que mantiene con el planificador.
La coexistencia de múltiples espacios de direcciones pertenecientes a procesos residentes en
memoria principal introduce la necesidad de satisfacer dos necesidades conflictivas: la separa-
ción de los espacios de direcciones y la compartición de memoria. El administrador de memoria
debe forzar el aislamiento de los espacios de direcciones distintos para evitar que un proceso ac-
tivo acceda errónea o maliciosamente, y destruya potencialmente los contenidos de los espacios
de direcciones de otros procesos.
Un administrador de memoria en un entorno de multiprogramación debería soportar simul-
táneamente la protección de memoria, aislando espacios de direcciones disjuntos, y la comparti-
ción de memoria, para permitir que procesos cooperativos accedan a áreas comunes de memoria
que satisfacen estos difíciles y en ocasiones conflictivos requisitos con distintos grados de cum-
plimiento.
3.1.3. Jerarquía de la memoria

En la sección 1.1.1.2 explicamos la importancia de la memoria principal y en la figura 1.3
observamos cómo disminuye el costo del almacenamiento a medida en que nos alejamos del
procesador. Como podemos deducir, la jerarquía de los diferentes tipos de memoria puede es-
tablecerse de acuerdo a la velocidad, el costo y la capacidad de la misma. Vamos a describir
brevemente los diferentes tipos de memoria que podemos encontrar en un sistema de compu-
tadora.
Registros del procesador. El almacenamiento más rápido al que puede acceder el procesador
es a sus propios registros. En general tardará unos pocos ciclos de reloj para hacer alguna
operación que utilice el direccionamiento de registros.
Memoria Caché. La memoria caché puede ser de dos tipos:
Memoria caché interna. Es aquella que se encuentra dentro del chip del procesador
lo que le da una velocidad de acceso mayor que a la memoria principal.
Memoria caché externa. Es aquella que colocan fuera del chip del procesador, pero
muy cerca de éste, su tecnología de construcción es la misma que la que usan para
la memoria caché interna, pero con la ventaja de que el usuario puede ampliar este
tipo de memoria. Aunque su velocidad de acceso es intermedia entre la velocidad de
la memoria caché interna y la velocidad de acceso de la memoria principal.
La capacidad de las memorias caché varía entre los 4kbytes en sistemas pequeños hasta
512kbytes o más en servidores dedicados.
Memoria principal. La memoria principal puede construirse con diversas tecnologías, pero lo
más importante es saber su velocidad de acceso, que es comúnmente medida por la veloci-
dad del bus. Actualmente son comunes velocidades que varían desde los 33 Megahertz en
bus, 100 Megahertz, 333 Megahertz, 512 Megahertz, 800 Megahertz y en modelos espe-
ciales hasta de un gigahertz o más. En cuanto a la capacidad podemos encontrar memorias
desde 32 Megabytes, 64, 128, 256, 512 Megabytes, 1 Gigabyte, 2, 4, 8 Gigabytes o más
en servidores de alto desempeño.
La velocidad de la memoria suele verse restringida por la velocidad del bus de la tarjeta base,
que también podemos encontrar en diferentes velocidades, con obviamente diferentes precios.
Estas velocidades, comparadas con las velocidades de los procesadores actuales, que gene-
ralmente varían desde los 800 Megahertz, en modelos relativamente antiguos cuando se usaban
memorias a 100 o 333 Megahertz, hasta los más actuales que llegan a velocidades cercanas a los
3 Gigahertz y que como podemos ver, triplican la velocidad del bus de la tarjeta madre y de las
mismas memorias, implica que cuando un dato no se encuentra en los registros del procesador,
éste tenga buscarlo en la memoria caché, y esperar algunos ciclos de reloj en lo que la memoria
recupera los datos. Si éstos no se encuentran tampoco en la caché el procesador insertará más
ciclos de espera, debido a que la velocidad del bus de la memoria es mucho más lenta que la
velocidad del procesador y que la memoria caché. Por eso los fabricantes de procesadores miden
la eficiencia de la memoria caché basados el número de fallos y aciertos de la caché. Un fallo, se
refiere a que el dato buscado por el procesador no se encuentra en la caché y un acierto si es que
sí se encuentra. El manejador de la caché intenta “adivinar” cuál será el siguiente dato solicitado
por el procesador y tenerlo disponible antes de que lo pida. Es normal tener tasas de acierto que
van del 90 al 95 % lo que ayuda a paliar la lentitud del bus de la tarjeta base y de la memoria
principal.
3.1.4. Estrategias para la administración de la memoria

Ahora que ya conocemos los diferentes tipos de memoria, hay que hacer notar que la me-
moria caché la administra el hardware del procesador, lo que significa que el sistema operativo
no puede hacer nada a ese respecto. Únicamente puede administrar los registros a nivel de in-
tercambio de contexto y la memoria principal. Los registros se optimizan comúnmente durante
el proceso de compilación de la aplicación, haciendo uso intensivo de ellos en operaciones que
involucran ciclos.
las estrategias para la administración de memoria están divididas en dos grandes categorías:
1. Asignación de memoria contigua. En esta estrategia se asigna una partición al sistema

operativo y la memoria restante forma otra particiones que serán ocupada por los procesos
y que serán asignadas a medida que sean solicitadas.
2. Asignación de memoria no contigua. Significa que la memoria se asigna de tal modo

que partes de un solo objeto lógico pueden colocarse en áreas no contiguas de la memoria
física. El sistema operativo o el hardware realiza una traducción de direcciones en tiempo
de ejecución de las instrucciones para establecer la correspondencia necesaria entre el
espacio de direcciones virtuales contiguo y las direcciones físicas no continuas de las
posiciones en donde realmente residen los objetos en memoria física.
3.1.5. Multiprogramación con particiones fijas y variables

La asignación contigua significa que cada objeto lógico es colocado en un conjunto de posi-
ciones de memoria con direcciones estrictamente consecutivas. Un método habitual de asigna-
ción contigua consiste en particionar la memoria física disponible y satisfacer las solicitudes de
memoria asignando particiones libres adecuadas, si existen.
Cuando un objeto residente termina, su partición es liberada y queda disponible para ser
asignada a otro solicitante. Las particiones de memoria pueden ser definidas estáticamente o de
tamaño fijo, por ejemplo, durante la generación del sistema, o de forma variable (dinámicamen-
te), en respuesta a demandas del usuario o de los procesos.
Ahora analizaremos las dos estrategias más comúnmente usadas en la asignación de memoria
contigua. y que básicamente son:
1. Particiones fijas.
2. Particiones variables
3.1.5.1. Particiones fijas.
Cuando se usan particiones fijas se desaprovecha memoria en cada partición en donde se

carga un objeto de tamaño más pequeño que el de la propia partición. El desaprovechamiento
de la memoria dentro de una partición debido a la diferencia entre el tamaño de la partición y el
objeto residente se le conoce como fragmentación interna.
En el esquema de particiones fijas, el sistema operativo mantiene una tabla que indica qué
particiones de la memoria están disponibles y cuáles ya han sido asignadas. Inicialmente toda la
memoria está disponible para los procesos de usuario y se considera como un único bloque de
gran tamaño, cuando hay una solicitud o llega un proceso y se necesita memoria, se asigna la
memoria necesaria, manteniendo el resto para cumplir con solicitudes futuras.
En la figura 3.2 vemos un ejemplo de cómo quedaría ocupada la memoria mediante este
mecanismo.
Figura 3.2: Distribución con particiones fijas
Obsérvese que el sistema operativo ocupa una porción de memoria. En este caso tenemos
un sistema operativo residente Además otros tres procesos tienen asignada su correspondiente
memoria. Las particiones en color obscuro son áreas que se encuentran libres.
3.1.5.2. Particiones variables.
La partición dinámica elimina la fragmentación interna haciendo que cada partición tenga el
tamaño justo necesario para satisfacer la petición de espacio de un objeto, tal como un programa
o un área de datos compartida.
A medida que entran más procesos al sistema, se introducen en una cola de entrada. El
sistema operativo considera los requisitos de memoria en cada proceso y la cantidad de memoria
disponible a la hora de determinar a qué procesos se les asignará su memoria, cuando se le asigna
su espacio al proceso, se carga a memoria y puede empezar a competir por el uso de la CPU.
Cuando termina un proceso, el sistema operativo recoge su bloque de memoria ya desocupado y
lo integra a la lista de bloques libres para su futura utilización con otra solicitud u otro proceso
que necesite ejecutarse.
Cuando un objeto es eliminado de la memoria, el espacio que ocupaba es devuelto a la
memoria libre, desde el cual se efectúan las nuevas asignaciones. Después de algún tiempo
de operación, la partición dinámica de la memoria tiene la tendencia a fragmentar la memoria

principal entremezclando áreas de memoria asignada y memoria no utilizada. Esto da como
resultado, que ante una nueva solicitud de memoria, el administrador sea incapaz de encontrar
una región libre que cumpla con los requisitos de la solicitud. Incluso en el caso de que los
tamaños combinados de las áreas libres excedan a las necesidades de la petición por un amplio
margen. A este tipo de desaprovechamiento se le conoce como fragmentación externa .
Pueden implementarse algunas técnicas para evitar en lo posible la fragmentación externa.
Una de ellas es verificar si el bloque liberado tiene algún otro bloque continuo. Si es así, entonces
puede procederse a unirlos para tener un bloque más grande. El sistema operativo puede entonces
buscar en la cola de procesos si ya es posible cumplir el requerimiento de memoria de algún otro
proceso que esté esperando su asignación de espacio.
Este procedimiento es un caso particular del problema general de asignación variable de
memoria, que se ocupa de cómo satisfacer una solicitud de tamaño n a partir de una lista de
bloques libres. Las estrategias más comunes para seleccionar un bloque de memoria son las
siguientes:
1. Primer ajuste. Se asigna al primer bloque que sea lo suficientemente grande. La búsqueda
puede comenzar al principio de la lista o donde se quedó la última búsqueda efectuada para
encontrar otro bloque.
2. Mejor ajuste. Se asigna al bloque más pequeño que tenga el tamaño suficiente. Es ne-
cesario hacer una búsqueda por toda la lista de bloques libres o en su defecto mantenerla
ordenada para reducir el tiempo de búsqueda. Esta estrategia logra que se genera el agujero
más pequeño posible.
3. Peor ajuste. Se asigna al bloque de mayor tamaño. Otra vez debe de hacerse una búsqueda
por toda la lista de bloques libres o en su defecto tenerla ordenada disminuyendo así
el tiempo de búsqueda. Esta estrategia produce un bloque más grande con la memoria
sobrante, lo que puede ser útil, por que disminuye la probabilidad de que haya bloques lo
suficientemente pequeños como para ya no ser útiles como podría suceder en la estrategia
del mejor ajuste.
Tanto la estrategia del mejor como el por ajuste sufren del problema de fragmentación exter-
na. El uso de cualquiera de estos algoritmos puede afectar el grado de fragmentación, por que
la estrategia de primer ajuste es mejor para algunos sistema, mientras que para otros resulta más
adecuado la de mejor o peor ajuste en otros sistemas.
Una solución al problema de la fragmentación externa consiste en la compactación. El obje-
tivo es mover el contenido de la memoria con el fin de que toda la memoria libre quede de forma
166 3.2. MEMORIA REAL
contigua. No obstante, la compactación no es posible bajo algunas condiciones. Si la reubicación

es estática y se lleva a cabo en tiempo de ensamblado o en tiempo de carga, no es posible usar el
mecanismo de compactación. Éste sólo es posible si tenemos reubicación dinámica y además se
lleva a cabo en tiempo de ejecución. Si es posible hacer esto entonces, sólo es necesario mover
el proceso al nuevo bloque y cambiar su registro base y su registro límite para reflejar el cambio
de bloque de memoria. Además aunque sea posible la compactación es necesario calcular su
costo computacional, para saber si es viable o no.
3.2. Memoria real

3.2.1. Administración de la memoria con mapa de bits
La estrategia de manejo por medio de mapa de bits, divide la memoria en bloques de di-
ferentes tamaños y registra en un mapa de bits qué unidades están ocupadas con un cero (0)
y cuáles están desocupadas (1). Los bloques pueden ir desde unas pocos bytes cada uno hasta
algunos kilobytes. Si los bloques de memoria son mayores, menor es el tamaño del mapa de bits
y viceversa. Aquí tenemos un compromiso entre aprovechamiento de la memoria y tamaño de
bloques. Puesto que si en promedio existen procesos pequeños ejecutándose en memoria y los
bloques son grandes, entonces existe una posibilidad mayor de que haya un gran desperdicio por
no ajustarse el proceso al bloque y por lo tanto aumenta la fragmentación interna. Si son bloques
muy pequeños, entonces puede ser necesario asignar a un mismo proceso varios bloques, que
posiblemente sea difícil encontrarlos juntos. Si este es el caso, entonces se incrementará la frag-
mentación externa. La principal desventaja de esta estrategia es que para encontrar un bloque de
memoria libre de n unidades hay que recorrer el mapa hasta encontrar n ceros seguidos, lo cual
puede significar recorrer todo el mapa y en el peor de los casos no encontrarlos.
Figura 3.3: Disposición general de la memoria física
En la figura 3.3 podemos observar cómo se diseña el mapa y su correspondencia con la

memoria física. Observe cómo un bit puede indicar si está ocupado o no un bloque de memoria.
3.2.2. Administración de la memoria con listas enlazadas

En esta estrategia de administración de memoria, el sistema operativo usa listas enlazadas
para mantener el registro de la memoria libre y de la memoria ocupada.
En general, los nodos de la lista contienen los siguientes campos: Un indicador de si está
libre o pertenece a algún proceso, el comienzo del bloque, su longitud, estado en el que se
encuentra (si está en memoria principal o en disco) y un apuntador al siguiente nodo.
Cuando finaliza un proceso se pasa a disco, el sistema operativo puede ocupar los bloques
asignándolos a otro proceso. Si quedan dos bloques vacíos juntos, se unen en un solo segmento.
Si el algoritmo de la lista simplemente ligada incluye ordenación por dirección, entonces se
puede usar cualquiera de los algoritmos vistos en la sección 3.1.5.2 para seleccionar un bloque
donde poner un nuevo proceso.
Cada vez que se asigna un bloque a un proceso, a menos que quepa exactamente, se convierte
en un segmento asignado y se crea un bloque más pequeño. Esto, como sabemos, es un caso de
fragmentación interna.
Figura 3.4: Manejo de memoria con listas ligadas
En la figura 3.4 vemos cómo se implementa esta solución. Observemos que existen tres
procesos P1 , P2 y P3 . P1 y P2 se encuentran activos en memoria, pero P3 ahora se encuentra
en disco y el sistema operativo podrá ocupar esa memoria para otro proceso si es necesario
en la siguiente ejecución del planificador. Se tiene también, un área libre que empieza en la
dirección 150H y que ocupa 10h bytes. Para asignar memoria a un proceso, el administrador de
memoria debe recorrer la lista hasta que encuentre un nodo con suficiente espacio para cubrir el
requerimiento solicitado. Si no lo encuentra, puede que sea necesario bajar a la memoria virtual
algún bloque o proceso que no esté siendo ocupado en ese momento.
En las estrategias vistas anteriormente se tiene el problema de fragmentación interna. Una
168 3.3. ORGANIZACIÓN DE LA MEMORIA VIRTUAL
solución para este problema consiste en la compactación esto es, buscar aquellos bloques que
estén contiguos para unirlos y en el peor de los casos podría ser necesario ejecutar un procedi-
miento que reacomode todas las áreas de memoria no contiguas de tal manera que ahora queden
juntas. Esta estrategia requiere primeramente un algoritmo que determine qué tan fragmentada
está la memoria y si sobrepasa cierto umbral, entonces será necesario ejecutar el defragmentador.
3.3. Organización de la memoria virtual

Hasta ahora, se ha visto que que la asignación de memoria depende básicamente de las
siguientes estrategias:
1. Asignación Estática. Se asigna un espacio fijo a los procesos y requerimientos de éstos.
2. Asignación Dinámica. Se pueden asignar espacios más adecuados al tamaño de los pro-
cesos y sus requerimientos.
Ahora, ¿Qué pasa cuando en cualquiera de las estrategias anteriores, se termina la memoria
física? En esta situación pueden surgir las siguientes posibles respuestas del sistema operativo.
La memoria se ha terminado.
El sistema operativo busca la manera de reacomodar la memoria ocupada y así intentar

satisfacer nuevamente el requerimiento solicitado.
El sistema operativo busca procesos que se encuentren suspendidos, y si los encuentra en-
tonces puede guardarlos en disco y así liberar memoria principal y de esta forma satisfacer
la solicitud de memoria.
como puede verse, a medida que se incrementa la complejidad de las soluciones es mayor el
tiempo necesario para que el sistema operativo proporcione una respuesta al requerimiento. Esto
es, implica una degradación del desempeño del sistema, sin embargo, los últimos dos puntos
arriba mencionados ofrecen una mejor respuesta al usuario a indicarle solamente que se le acabó
la memoria.
Para que pueda darse una solución al problema de asignación, cuando la memoria física
se ha agotado, debe de planearse adecuadamente la técnica de asignación de memoria. Para
ello deben de responderse muchas preguntas de diseño, por ejemplo: ¿Qué soporte de hardware
proporciona la CPU para el manejo de memoria? La arquitectura de la CPU es la que va a dictar
en la mayoría de los casos qué estrategia de administración de memoria se va a implementar.
¿El esquema permite la asignación dinámica de direcciones? Si es así entonces el manejador
de memoria implementará un mecanismo de bloques de tal manera que se hagan coincidir con
archivos de disco en un lugar denominado espacio de swapping o intercambio. Este espacio es
manejado por el administrador de memoria en cooperación con el administrador del sistema de
archivos. El área de intercambio, comúnmente será un reflejo en disco de la administración en
memoria de tal forma que facilite la tarea de lectura/escritura entre ésta y el disco.
Las primeras versiones de los microprocesadores de Intel, 8088 y 8086, no contaban con
soporte de paginación y se dejaba a los compiladores el manejo de la memoria virtual.
Básicamente, el mecanismo utilizado para la administración de memoria era el de segmen-
tación. Cuando se administra la memoria con segmentos, se usa una división manejada por los
programadores, y esta consiste en:
1. Segmentos de Código. Aquí se almacena todo o parte del código de la aplicación.
2. Segmentos de datos. Aquí se guardan todos o parte de los datos de la aplicación. Existe
también otro denominado segmento extra.
3. Segmento de pila. Utilizado frecuentemente para mantener un registro de las llamadas a

funciones y para el paso de parámetros entre las mismas y el programa principal.
El primer intento fue la implementación de las bibliotecas dinámicas. Si no se ocupan la

mayoría de las rutinas de un programa al mismo tiempo, no es necesario entonces que se en-
cuentren todas ellas ocupando memoria que podría usarse para tener a otros procesos que sí se
estén ejecutando. En el momento en que se llame una rutina, ésta se lee de la librería, se le asig-
na su espacio en memoria y se encadena dinámicamente para que pueda continuar la ejecución.
Cuando ha dejado de ejecutarse, en la misma área de memoria puede entonces guardarse otra
rutina u otro proceso. La tarea de determinar que rutinas pueden ser o no ligadas dinámicamente
se le deja al programador. Por ejemplo, Borland implementó una estrategia de ligado dinámico
al que denominó overlays que consistían en un conjunto de rutinas explícitamente marcadas co-
mo dinámicas por el programador, de tal manera que éste podía ahora hacer programas mucho
más grandes basados en segmentos.
Actualmente, casi todas las CPU’s comerciales tienen hardware de soporte de paginación de
modo que la mayoría de los sistemas operativos utilizan técnicas de paginación. Así, la orga-
nización de la memoria física es idéntica a la del área de intercambio. El sistema operativo es
capaz de trasferir páginas del mismo tamaño directamente de la memoria al área de intercambio
y viceversa, este intercambio se hace en el momento en que el hardware detecta lo que se conoce
como fallo de página, esto es, cuando calculó la dirección real no encontró el marco de página
correspondiente en memoria e indica al sistema operativo que la cargue para continuar con la
ejecución del proceso. Este tema se analizará detalladamente en la siguiente sección.
170 3.4. ADMINISTRACIÓN DE LA MEMORIA VIRTUAL
3.4. Administración de la memoria virtual

Ahora introduciremos el concepto de memoria virtual y de los esquemas de asignación de
memoria no contigua de memoria física. La asignación no contigua significa que un proceso va a
ser cargado en bloques de memoria que no necesariamente van a estar juntos. El proceso tiene la
ilusión de que todo su código y datos están juntos y que puede ir accediendo a sus instrucciones
secuencialmente. El sistema operativo y el hardware se encargan de realizar la traducción de las
direcciones lógicas, las que ve el proceso, a direcciones físicas, que es donde realmente están
guardados los datos.
La memoria virtual permite la ejecución de procesos cuando partes de éste se encuentran
en zonas no secuenciales de memoria, incluso, algunas veces, esas partes de código no están
cargadas en memoria y si en algún momento dado se necesitan, entonces serán traídas de la
memoria secundaria. Existen básicamente dos estrategias para manejar la memoria virtual.
1. Paginación. Puede ser fija o sobre demanda. Divide la memoria física en una serie de
porciones de tamaño fijo llamados marcos de página.
2. Segmentación. También llamado segmentación sobre demanda. Divide la memoria en

unidades lógicas llamadas segmentos. Por ejemplo, segmentos de código, datos y pila.
La necesidad de disminuir la cantidad de instrucciones y datos en memoria física, viene del

hecho que la mayoría de las veces los programa incluyen instrucciones que van a ejecutarse muy
pocas ocasiones incluso nunca, como aquellas instrucciones dedicadas a comprobar situaciones
de error. Otro ejemplo puede venir de las rutinas de procesamiento avanzadas que vienen in-
cluidas en la mayoría de los paquetes comerciales, cuando, por ejemplo, en un procesador de
palabras que use una secretaria, y que lo dedica exclusivamente a la redacción de oficios de una
sola hoja. En un sistema compartido, no tendría caso mantener todas esas funciones inactivas
en memoria ocupando espacio que podría contener otros procesos de usuario que esperan su
momento de ejecución estando guardados en disco.
La posibilidad de permitir que se encuentre en memoria parte del programa, proporcionaría
las siguientes ventajas:
1. Los programas necesitarían menos instrucciones de E/S para cargar o intercambiar los
procesos, puesto que aparte de ellos estaría en memoria y sólo será necesario, si es que lo
es, cargar la parte que va a ejecutarse, por lo tanto, se ejecutaría más rápido.
2. Los programas pueden incluir mayor cantidad de funcionalidades puesto que ya no esta-
rían restringidos al tamaño de la memoria física y el programador puede definir estructuras
de datos tan grandes como crea necesario.
3. Puesto que es muy probable que solamente se estén ejecutando las instrucciones que usa
más comúnmente un usuario, y que son relativamente pocas comparado con el tamaño
total del programa, estas instrucciones ocuparán mucho menos memoria y por lo tanto,
podrá ejecutarse un mayor número de procesos al mismo tiempo, con el correspondiente
incremento en la tase de utilización de la CPU y la tasa de procesamiento sin incrementar
el tiempo de respuesta ni el tiempo de ejecución.
De esta forma, la ejecución de procesos que no se encuentren completamente en memoria

proporciona muchas ventajas tanto para el sistema, como para el usuario. La memoria virtual
separa la memoria lógica de la memoria física. La memoria lógica es lo que percibe el usua-
rio y por tanto, éste no interactúa directamente con la memoria física. Esta separación permite
proporcionar a los programadores una memoria virtual extremadamente grande, cuando sólo
está disponible una memoria física pequeña. La memoria virtual facilita enormemente la tarea
de programación, por que el programador ya no tiene que preocuparse de la cantidad de me-
moria física disponible, y puede concentrarse en el problema que debe resolver su programa,
simplificando de este modo las estructuras de datos que utilizará.
El espacio de direcciones virtuales de un proceso hace referencia a la forma de almacenar
un proceso en la memoria. Generalmente, esta forma consiste en que el proceso comienza en
una cierta dirección lógica( comúnmente la dirección 0) y está almacenado de forma contigua
en la memoria contigua paginada. Esta a su vez se encuentra almacenada en marcos de página
definidos en la memoria física y que estos marcos no precisamente deben de estar juntos. Es
responsabilidad de la unidad de administración de memoria establecer la correspondencia entre
las páginas lógicas y los marcos de página física de la memoria. En la figura 3.5 vemos la
distribución de la memoria virtual en un sistema típico.
Además de separar la memoria lógica de la memoria física, la memoria virtual también
permite que dos o más procesos compartan los archivos y la memoria mediante mecanismos de
compartición de páginas, así se obtienen las siguientes ventajas:
El sistema operativo puede compartir sus bibliotecas con muchos procesos, mapeando las
funciones compartidas sobre un espacio de direcciones virtual. aunque cada proceso con-
sidera que las bibliotecas compartidas forman parte de su propio espacio de direcciones
virtual, las páginas reales de memoria física en las que residen las bibliotecas estarán com-
partidas por todos los procesos. Es común que las bibliotecas se mapeen en modo de sólo
lectura dentro del espacio de cada proceso que las vaya a utilizar.
Los procesos pueden compartir un área de memoria. De esta forma, un proceso, crea una
región de memoria e indica al sistema operativo que desea compartirla con otros procesos.
Figura 3.5: Organización de la memoria virtual
Se pueden compartir páginas durante la creación de procesos mediante la llamada de sis-

tema fork(), acelerando la creación de procesos.
Existen diferentes formas de implementar la paginación, una de ellas es mediante la pagina-

ción fija y otra es la paginación bajo demanda.
3.4.1. Paginación
La paginación es un esquema de administración de memoria que permite que el espacio
de direcciones físicas de un proceso no sea contiguo. Este esquema evita el gran problema de
encajar fragmentos de memoria de tamaño variable en el almacén de respaldo; la mayoría de
los esquemas de administración de memoria antes de que se introdujera la paginación sufrían
de este problema, que surgía debido a que, cuando era necesario proceder a la descarga de
algunos datos o fragmentos de código que estuvieran en la memoria física, debía de encontrarse
el espacio necesario en disco. El disco también sufre problemas de fragmentación, pero con el
problema de hacer todavía el acceso mucho más lento, haciendo que en ocasiones no sea posible
hacer una compactación del disco sin hacer que el sistema de cómputo completo se dedique a
realizar casi exclusivamente a esa tarea.
Básicamente, la memoria física se divide conceptualmente en una serie de porciones de
tamaño fijo, llamadas marcos de página. El espacio de direcciones virtuales de un proceso se
divide además en bloques de tamaño fijo del mismo tamaño llamados páginas. La asignación
de memoria consiste en hallar un número suficiente de marcos de página sin utilizar para cargar
en ellos las páginas del proceso solicitante. Para hacer corresponder las páginas virtuales con
sus marcos de página físicos asociados se utiliza un mecanismo de traducción de direcciones.
Puesto que cada página se hace corresponder separadamente, los diferentes marcos de página
asignados a un proceso no necesitan ocupar áreas contiguas de memoria física.
3.4.1.1. Paginación fija
En la paginación fija, cuando hay que ejecutar un proceso, sus páginas se cargan desde el
disco en los marcos de memoria disponibles. El disco, también está dividido en bloques de
tamaño fijo que tienen el mismo tamaño que los marcos de memoria. Toda dirección generada
por la CPU está dividida en dos partes:
1. Número de página. Determina a qué página nos referimos.
2. Desplazamiento de página. Determina a qué byte dentro de la página queremos acceder.
El número de página se utiliza como índice para una tabla de asignación de páginas. La
tabla de asignación de páginas contiene la dirección base de cada página en memoria física; esta
dirección base se combina con el desplazamiento de página para definir la dirección de memoria
física que se envía a la unidad de memoria. En la figura 3.6 podemos observar la estructura
general para lograr la paginación.
Figura 3.6: Estructura general de un sistema de paginación
El tamaño de página está definido por el hardware, y éste es comúnmente una potencia de dos
y que puede ir desde los 512 bytes hasta los 16 MB por página, esto depende de la arquitectura
de la computadora. La selección de una potencia de dos como tamaño de página hace que la
traducción de una dirección lógica a un número de página y a un desplazamiento de página
resulte particularmente fácil. De esta manera si tenemos un espacio lógico de direcciones de 2m

y el tamaño de página es de 2n unidades de direccionamiento (bytes o palabras), entonces los
m − n bits de mayor peso de cada dirección lógica designarán el número de página, mientras
que los n bits de menor peso indicarán el desplazamiento de página. por lo tanto, la dirección
lógica tiene la estructura siguiente:
Número de página desplazamiento de página

p d
m−n n
donde p es un índice de la tabla de páginas y d es el desplazamiento dentro de la página.

El esquema de paginación es una forma de reubicación dinámica. Cada dirección lógica es
asignada por el hardware de paginación a alguna dirección física. La utilización de la paginación
es similar al uso de una tabla de registros base, pero ahora se asigna uno por cada marco de
memoria y obviamente la estructura que guarda esa información es la tabla de páginas.
En la figura 3.6 vemos que el índice de la tabla de páginas se corresponde con las páginas
en la memoria lógica y el contenido donde apunta el índice dentro de la tabla hace referencia al
marco de página en la memoria física.
Una ventaja de usar paginación es que no se tiene fragmentación externa debido a que se
puede acceder a todos los marcos de página en algún momento dado. No obstante sí puede
sufrir cierto grado de fragmentación interna, esto es debido a que los marcos se asignan como
unidades y comúnmente en el último marco es difícil que coincida exactamente con lo solicitado
y puede que no esté completamente lleno. En el peor de los casos supóngase que el tamaño de la
página es de 512 bytes y un proceso hace una solicitud por 513 bytes. En este caso se necesitan
dos marcos de memoria física para cubrir la solicitud, pero para nuestro ejemplo, tendremos
511 bytes desocupados. En general se puede esperar que la fragmentación interna sea, como
promedio, de media página por proceso. Esta consideración sugiere que se deban usar tamaños
de página pequeños, no obstante, hay que recordar que a medida que disminuye el tamaño
de página aumenta en esa misma proporción el número de páginas que deben administrarse
y aumenta también la cantidad de recursos para ello.
Un aspecto importante de la paginación, es la separación que existe entre la visión que tiene
el usuario sobre la memoria y la memoria física real. El usuario tiene la ilusión de ver a la me-
moria como un espacio secuencial en donde tiene almacenado su programa y sus datos, aunque
en la realidad su programa y sus datos están distribuidos por toda la memoria y en ella también
se encuentran porciones del sistema operativo y otros procesos.
La diferencia entre la visión del usuario y la memoria física es corregida por la unidad
de administración de memoria que se encarga de traducir las direcciones lógicas del usuario a
direcciones físicas de la memoria. Esta conversión está oculta al usuario puesto que la puede
hacer directamente el hardware de la CPU y es controlado a su vez por el sistema operativo.
Los procesos de usuario son incapaces, por el mismo esquema, de acceder a memoria que no les
pertenece. No tienen forma de direccionar la memoria situada fuera de su tabla de páginas y esa
tabla incluye únicamente aquellas páginas que sean propiedad del proceso.
El sistema operativo es el encargado de llevar el control de la asignación de la memoria
física y de las tablas de páginas de los procesos. De modo que puede saber qué marcos ya han
sido asignados y a quién, del mismo modo cuenta con una lista de los marcos que se encuentran
disponibles. Esta información suele estar almacenada en una estructura de datos denominada
tabla de marcos. La tabla de marcos tiene una entrada por cada marco físico que indica si está
libre o asignado y, en caso de estar asignado, a qué página y a qué proceso o procesos lo está.
A su vez el sistema operativo debe de hacer una traducción manual de aquellas direcciones
que proporcione el usuario, puesto que éstas direcciones se encuentran dentro del espacio de
direcciones lógicas.
Soporte de hardware. La implementación del sistema de páginas puede variar en diferentes

sistemas operativos. La mayoría de ellos asignan una tabla de páginas para cada proceso, guar-
dando un apuntador a la tabla de páginas, junto con los otros valores de los registros en el bloque
de control de proceso. cuando el administrador de procesos inicia uno, vuelve a cargar los va-
lores previos que ya tenía si es que el proceso estaba suspendido, si es su primer ejecución, le
asigna las páginas y los marcos de memoria necesaria para su ejecución.
También podemos encontrar soluciones de hardware para la paginación. Este puede ser de
distintas maneras. La manera más sencilla de implementar la tabla de páginas es estructurar-
la como un conjunto de registros dedicados. Estos registros deben construirse con lógica de
muy alta velocidad, para hacer que el proceso de traducción de direcciones sea lo más eficiente
posible. Cada acceso a la memoria debe pasar a través de la tabla de paginación, de ahí el re-
querimiento de alta velocidad. El administrador de la CPU recarga estos registros al igual que
recarga los registros restantes a partir del bloque de control de procesos. Las instrucciones para
cargar o modificar los registros de la tabla de páginas solo pueden ejecutarse en modo kernel
o privilegiado, de esta forma sólo el sistema operativo puede cambiar la tabla de páginas. El
problema de este enfoque es su baja capacidad de direccionamiento puesto que que los sistemas
operativos actuales necesitan en ocasiones poder direccionar más de un millón de páginas. Una
forma de paliar este problema es usando un registro base de la tabla de páginas de manera que
apunte al principio de la tabla de páginas, de esta manera sólo hace falta cambiar un solo registro
para apuntar a una nueva tabla de páginas. Ahora el problema es la velocidad de acceso a una
localidad de memoria solicitada. Esto es, primero hay que hacer una indexación en la tabla de
páginas, usando el valor del registro base de la tabla de páginas, desplazado según el número de
páginas para obtener e número de marco luego combinarlo con el desplazamiento para obtener
la dirección física real. Así, con este esquema se realizan dos accesos a memoria, de modo que
la velocidad de acceso a memoria se ralentiza en un factor de dos.
Este problema se resuelve comúnmente utilizando un chip de hardware especial de pequeño
tamaño y de acceso rápido, denominado búfer de consulta de traducción. Este hardware es
una memoria asociativa de alta velocidad. Cada entrada del búfer se compone de dos partes: una
clave y un valor. Cuando se le presenta un elemento a la memoria asociativa, ese elemento se
compara simultáneamente con todas las claves. Si se encuentra, entonces devuelve el valor co-
rrespondiente. Esta búsqueda -realizada a nivel de hardware- es hecha en paralelo. El problema
es que el hardware es caro y de pequeña capacidad que viene a ser entre los 64 y 1024. Bajo esta
técnica se puede ahorrar hasta el 90 % del tiempo necesario si es que las entradas no fueran con-
vertidas. En caso de que el marco de página no estuviera en la memoria asociativa, entonces es
necesario hacer una consulta a la tabla de páginas en memoria como se haría normalmente pero
ahora se actualizaría la memoria asociativa de manera que la siguiente vez que sea solicitada
pueda regresar su valor inmediatamente.
Protección de memoria. La protección de memoriaen un entorno de páginas se consigue

mediante una serie de bits de protección asociados con cada marco. Normalmente, estos bits se
mantienen en la tabla de páginas.
Uno de los bits puede definir una página como de lectura-escritura o de sólo lectura. Toda
referencia a memoria pasa a través e la tabla de páginas con el fin de encontrar el número de
marco correcto. Al mismo tiempo que se calcula la dirección física, pueden comprobarse los
bits de protección para verificar que no se esté escribiendo en una página de sólo lectura. Todo
intento de escribir una página de sólo lectura provocará una interrupción de hardware al sistema
operativo, denominada violación de protección de memoria.
Generalmente cada entrada de la tabla tiene asociado un bit que indica si la página es vá-
lida o inválida. cuando este bit tiene el valor de “válido”, quiere decir que la página asociada
se encuentra en el espacio de direcciones lógicas del proceso y será entonces una página legal.
Cuando está configurado como “inválido”, la página no se encuentra en el espacio de direccio-
nes lógicas del proceso. El sistema operativo utiliza este bit para permitir o prohibir el acceso
a ciertas páginas a los procesos. Si algún proceso trata de acceder a una página que esté mar-
cada como inválida entonces se generará una interrupción de referencia de página inválida que
mandará a traer al sistema operativo para arreglar la situación (lo más común es que termine la
ejecución del proceso que generó la interrupción).
Los procesos raramente utilizan todo su rango de direcciones. De hecho, muchos procesos
sólo emplean una pequeña fracción del espacio de direcciones que tiene disponible, por tanto
sería un gran desperdicio tener tablas de páginas con entradas para todo el rango posible de
direcciones a utilizar. Algunos sistemas proporcionan mecanismos de hardware especiales en
forma de registros de longitud de la tabla de páginas, para indicar el tamaño de la tabla de
páginas. Este valor es comparado con cada dirección lógica para verificar que esa dirección se
encuentre dentro del rango de direcciones válidas definidas para el proceso.. Si la comprobación
falla, se produce una interrupción para notificar al sistema operativo.
Páginas compartidas. Una ventaja de la paginación es la posibilidad de compartir código

o datos comunes. Esto es muy importante en sistemas de tiempo compartido. Si tenemos un
conjunto de usuarios que manejan el mismo programa por estar relacionadas sus tareas. Así se
puede cargar una sola copia del código, pero con un área de datos diferente para cada cada usua-
rio, bajando considerablemente los requerimientos de memoria si a cada usuario de le diera una
copia de código del programa en memoria. Es fácil compartir el código por que éste raramente
o nunca se modifica. Los datos de los usuarios deben tener forzosamente sus propias páginas
debido a que los usuarios trabajarán en actividades diferentes bajo el mismo programa.
Figura 3.7: Compartición de código mediante páginas
En la figura 3.7 vemos como los procesos P 1 y P 2 comparten el código de un editor en las
posiciones 0, 2 y 4. Mientras que los datos del editor 1 se encuentran en la página 11 y los datos
del editor 2 están en la página 8.
Bajo este enfoque es posible compartir otros programas que se utilicen a menudo por muchos
usuarios, como sistemas de ventanas, bibliotecas dinámicas bases de datos, compiladores y otros.
La compartición de memoria que contengan datos entre los procesos es muy similar a la forma
en que se comparte código.
3.4.1.2. Paginación bajo demanda
Ahora consideremos la carga de un programa ejecutable desde el disco a memoria. Una posi-
ble solución sería cargar el programa completo al momento de ejecutar el programa. El problema
que se presenta bajo este esquema es que en realidad no es necesario tener inicialmente todo el
programa. Por ejemplo, en la mayoría de las ocasiones lo que primeramente se ejecuta es un me-
nú que, cuando el usuario escoge una opción, entonces llamaría al módulo correspondiente, pero
no tendría caso entonces tener en memoria todos los módulos, puesto que comúnmente sólo uno
se ejecutará en un momento dado. De esta forma, si el sistema operativo sólo carga las páginas
que realmente sean necesarias y después a medida que se vayan solicitando, traerlas entonces
desde disco, a esto se le denomina paginación bajo demanda. Esta técnica es comúnmente utili-
zada en los sistemas de memoria virtual. Bajo este esquema, sólo se cargan las páginas cuando
así se solicita durante la ejecución del programa, bajo esta lógica, aquellas páginas que nunca
sean solicitadas para ejecución no serán tampoco nunca subidas a la memoria física.
Cuando el planificador de procesos recibe la orden de cargar de disco un programa, el pa-
ginador realiza una estimación de qué páginas serán utilizadas antes de descargar de nuevo el
proceso. En lugar de cargar el proceso completo, el paginador sólo carga en la memoria las pági-
nas que posiblemente sean necesarias, así evita cargar en la memoria las páginas que no vayan a
ser utilizadas, reduciendo considerablemente el tiempo de carga y la cantidad de memoria física
en comparación a cargar el proceso completo.
Con este esquema, es necesario que el hardware proporcione soporte para distinguir entre
las páginas que se encuentran en memoria y las páginas que residen en disco. Puede usarse un
bit que indique si la página es “válida” o “inválida”. Si el bit se coloca a “válido” entonces
se dice que la página asociada será legal y además se encontrará en memoria. De otra forma
decimos que la página no es válida, esto es, o no se encuentra dentro del espacio de direcciones
del proceso o es legal pero se encuentra almacenada en disco y es necesario entonces subirla a
memoria.
Si una página está marcada como inválida pero no es accedida por el proceso no tendrá
entonces ninguna implicación. Por tanto, si el paginador carga exactamente las páginas que
serán ejecutadas por el proceso, éste se ejecutará exactamente igual que si se hubieran cargado
todas las páginas del mismo. En caso de que el proceso necesite acceder a una página que no
haya sido cargada, entonces el hardware al detectar que el bit se encuentra en “inválido” generará
una interrupción denominada interrupción de fallo de página. El sistema operativo entonces
mandará a traer al paginador para que lea de disco la página solicitada y sea puesta en memoria.
El procedimiento que sigue el sistema operativo es:
1. Se comprueba la tabla interna, que usualmente se encuentra en el bloque de control de

proceso para determinar si la referencia era un acceso de memoria válido o inválido.
2. Si la referencia es inválida, entonces se termina el proceso por intentar leer o escribir un

área que no le corresponde. Si era válida pero esa página todavía no ha sido cargada,
entonces deberá ser cargada de disco a memoria.
3. Se busca un marco libre, ya sea de la lista de marcos libres, y si ya no hay entonces se baja
a disco un marco de otro proceso que lleve tiempo de no ser accedido
4. Se hace una operación de lectura de disco para leer la página deseada en el marco recién
asignado.
5. Terminada la lectura de disco, se modifica la tabla interna que se mantiene con los datos
del proceso y la tabla de páginas para indicar que dicha página se encuentra ahora en
memoria.
6. Se reinicia la instrucción que fue interrumpida. El proceso podrá ahora acceder a la página
como si siempre hubiera permanecido en memoria.
en el caso extremo, se podría empezar a ejecutar un proceso sin ninguna página en memoria.
Cuando el sistema operativo hiciera que el apuntador de instrucciones apuntara a la primera ins-
trucción del proceso, se encontraría entonces en una página no residente en memoria, entonces
se generaría inmediatamente una interrupción de fallo de página, después de cargar dicha página
en memoria el proceso continuaría ejecutándose. Si llegara a requerir otra página nuevamente
se genera otra interrupción, este proceso seguiría hasta el momento en que el proceso se ejecute
sin fallos de páginas llegando a estabilizarse. A esto se le denomina paginación bajo demanda
pura esto es, nunca cargar una página en memoria hasta que sea requerida.
Es probable que haya programas que podrían acceder a varias páginas nuevas de memoria
con cada ejecución de una instrucción, y por supuesto generando también muchos fallos de pá-
ginas, lo que implicaría una grave degradación del sistema, la buena noticia es que los resultados
de los análisis de procesos indican que este comportamiento es bastante improbable, de manera
que pueden obtenerse prestaciones de desempeño bastante razonables.
El hardware que se necesita para dar soporte a la paginación bajo demanda es el siguiente:
Tabla de Páginas. Permite marcar una entrada como inválida mediante un bit válido-
inválido o mediante un valor especial de una serie de bits de protección.
Memoria secundaria. Aquí se almacenarán aquellas páginas que no están presentes en

memoria principal. Comúnmente es un disco duro de alta velocidad. Muchas veces se
le denomina como dispositivo de intercambio y la sección del disco utilizada para este
propósito se le denomina espacio de intercambio.
El sistema operativo debe de tener la capacidad de poder reiniciar cualquier instrucción

después de un fallo de página. Esto se logra guardando el contexto del proceso (el cual incluye
entre otras cosas el estado de los registros, el contador de programa y el registro de condiciones)
al momento en que se produce la interrupción de fallo de página. De esta manera es posible
reiniciar la instrucciónexactamente donde se quedó y con el mismo estado de registros. Después
de haber colocado la nueva página la instrucción se ejecutará sin ningún problema.
En esta estrategia de manejo de memoria podemos hacer uso de la figura 3.5 en donde el
disco almacena páginas que pueden intercambiarse directamente con los marcos de memoria
física.
La diferencia, como puede notarse, es que en la paginación fija no hacemos uso de la memo-
ria virtual, cuando se ejecuta un programa éste ocupa tantas páginas como sea necesario, y si ya
no hay memoria, el sistema operativo tendrá que bajar un proceso completo, o más bien todas
sus páginas, a disco y de ahí colocar el nuevo proceso en sus marcos de página correspondientes.
En contraste, cuando se manejan las páginas sobre demanda, cuando se ejecuta un nuevo
proceso, es posible que éste ni siquiera haya sido leído de disco, solamente ha sido creado su
bloque de control de proceso y cuando el planificador le asigne su tiempo de CPU entonces hasta
ese momento será leída una o más páginas para que comience su ejecución. Si necesita páginas
adicionales éstas se irán leyendo a medida que se vaya necesitando.
3.4.2. Segmentación
La estrategia de manejo de memoria por segmentación, recuerda las primeras formas de
asignación de memoria. El sistema operativo apartaba un conjunto de localidades de memoria,
por ejemplo, la parte baja y en ocasiones también la parte alta de la memoria física. El resto
se ocupaba para los programas. El orden en que se asignan los segmentos tiene que ver con
la forma lógica en que los programadores empezaron a dividir sus programas. En general, un
usuario programador se imagina la memoria como una secuencia muy grande de bytes, que se
encuentran secuencialmente. Con esta idea en mente decide tomar una cierta cantidad de ella
y acomodar ahí el código de su programa. De la misma forma, toma otro bloque de memoria
secuencial y coloca ahí sus datos. Con la pila sucede lo mismo, un bloque secuencial, en donde
el proceso colocará los retornos de las llamadas a función que fueron hechas por el programa
principal y otras funciones. A su vez, también se usará para colocar ahí los parámetros por
referencia o por valor que necesitará esa función.
Como el código, los datos, y la pila varían de programa en programa, estos segmentos pueden
adaptarse al tamaño real que ocuparán en memoria. Tanto el código como los datos empezarán a
referenciarse a partir del principio del segmento con un desplazamiento de cero. El compilador,
en este caso lo que hace es ir incrementando el número de bytes que ocupe la instrucción o el
dato, en su correspondiente segmento.
La segmentación, por tanto, es un esquema que soporta la organización lógica de memoria
del usuario programador. De esta forma, podemos definir que un espacio lógico de direcciones
será un colección de segmentos y cada segmento tendrá su propio nombre y una longitud de-
terminada. Las direcciones especifican tanto el nombre del segmento como el desplazamiento
dentro del segmento. De esta manera el usuario programador, especifica dos valores para cons-
truir una dirección completa: la dirección del segmento o su nombre y el desplazamiento dentro
de éste.
Los segmentos más comúnmente utilizados son los siguientes:
1. Un segmento de código
2. Un segmento de datos para las variables globales
3. El cúmulo de memoria para asignación dinámica.
4. Uno o varios segmentos de pila para retornos de funciones y parámetros locales.
5. Un segmento de código adicional para la biblioteca C estándar.
El compilador también puede crear otros segmentos para cargar bibliotecas adicionales. Adi-
cionalmente, es posible crear “segmentos dinámicos”, que permiten cargar módulos de bibliote-
cas en tiempo de ejecución, bajando a disco aquel segmento que no se ha ocupado y subiendo
uno nuevo, aunque esta alternativa puede consumir mucho más tiempo, debido al tamaño del
segmento, que un sistema de paginación sobre demanda.
3.4.2.1. Soporte de hardware
Ahora el usuario puede hacer referencia a un segmento y un desplazamiento para acceder

un byte determinado. la CPU debe de ser capaz de proporcionar un mecanismo que permita
convertir este par de direcciones un una sola de memoria física. Este mapeo se lleva a cabo
mediante una tabla de segmentos. Cada entrada de la tabla de segmentos tiene una dirección
base de segmento y un límite de segmento. La dirección base del segmento contiene la dirección
física inicial del lugar donde se encuentra el segmento en la memoria, mientras que el límite del
segmento específica la longitud de éste.
Figura 3.8: Organización de segmentación
Ahora, una dirección lógica estará formada por un número de segmento s y un desplaza-
miento d. El número de segmento se utiliza como índice para la tabla de segmentos. El despla-
zamiento d de la dirección lógica debe estar comprendido entre 0 y el límite del segmento; si no
es así, se producirá una interrupción del tipo segmentation fault o intento de acceder más allá
del segmento asignado al proceso. Cuando el desplazamiento está dentro del rango adecuado,
entonces se suma al valor señalado por el índice dentro de la tabla de segmentos, de esta forma
se genera la dirección física en donde se encuentra el byte o palabra solicitado.
En la figura 3.8 podemos observar la relación que existe entre el espacio lógico de direccio-
nes, la tabla de segmentos y las direcciones de memoria física.
Como ejemplo, consideremos la situación mostrada en la figura 3.8, en donde tenemos cua-
tro segmentos. En el segmento 0 tenemos almacenado el código de una biblioteca, un segmento
de datos (segmento 0), el segmento de código del programa principal (segmento 2) y un seg-
mento de pila (segmento 3). Los segmentos se almacenan en la memoria física de acuerdo a lo
establecido en la tabla de segmentos, en donde tenemos la dirección inicial o base y el tamaño
total del segmento. por ejemplo, para el segmento de código de la biblioteca (segmento 0) em-
pieza en la dirección 1000 con 500 bytes de longitud. De esta forma, si se hace una referencia
al byte 300 del segmento 0 tenemos entonces que su dirección en memoria física sería entonces
1000 + 300 = 1300. podemos calcular entonces de la misma forma otros desplazamientos para
los segmentos 1, 2 y 3.
3.4.3. Algoritmos de sustitución de páginas

Regresando al manejo de memoria virtual es evidente que en el manejo de páginas bajo
demanda, es necesario subir de disco aquellas páginas que no se hayan encontrado en memoria
física. Hay que recordar que el hardware produce una interrupción de fallo de página para indicar
al sistema operativo que debe de leerla del disco. El rendimiento, por tanto de la paginación baja
en relación con los fallos de página que se generen. Un fallo de página obligará al sistema
operativo a realizar los siguientes pasos:
1. Interrumpir al sistema operativo.
2. Guardar los registros de usuario y el bloque de control del proceso (su estado)
3. Determinar que la interrupción se debe a un fallo de página y no a un acceso no autorizado.
4. Comprobar que la referencia de página era legal.
5. Determinar la posición de la página en disco.
6. Ordenar la lectura desde el disco y colocarla en un marco libre.
Esperar en la cola correspondiente al disco a que termine la operación de lectura.

Realizar la transferencia de la página al marco libre
7. Mientras se espera el planificador puede asignar la CPU a otro proceso.
8. Recibir una interrupción indicando que la transferencia de disco se ha terminado.
9. Si se ejecutó el paso 7 entonces guardar los registros y el estado del proceso.
10. Determinar si la interrupción corresponde a la petición realizada por el proceso que causó
el fallo de página.
11. si es así entonces actualizar la tabla de páginas para indicar que la página ya está lista en
memoria.
12. Esperar a que se vuelva a asignar la CPU al proceso.
13. restaurar los registros de usuario, el estado del proceso y la nueva tabla de páginas y
reanudar la ejecución de la instrucción interrumpida.
De acuerdo a lo anterior tener varios fallos de página seguidos puede implicar una ralentiza-
ción severa del sistema. Cuando esto sucede, el sistema operativo debe de buscar un marco libre
en el paso 6. Si no encuentra ninguno, entonces estaremos en un caso de sobrepaginación. El
sistema operativo debe entonces buscar alguna estrategia para cumplir la solicitud del proceso.
Una de ellas podría ser indicar el problema al usuario y terminar su proceso, pero no sería lo
más adecuado, sin embargo, el papel de la memoria virtual es precisamente el de apoyar al siste-
ma operativo en estas situaciones. El sistema operativo tiene entonces la opción de elegir algún
proceso bajo algún criterio preestablecido y enviarlo al disco, liberando así todos sus marcos
de memoria y de esta manera cumplir con la solicitud de página del proceso demandante. Esta
solución reduce el nivel de multiprogramación del sistema.
Otra alternativa del sistema operativo es sustituir solamente una o algunas de las páginas para
no tener que bajar todo el proceso a disco, que visto de esa forma puede ser también ineficiente,
por que no sabemos cuantas páginas conforman todo el proceso.
3.4.3.1. Sustitución simple de páginas
En general la sustitución de páginas usa la siguiente estrategia. Si no hay ningún marco libre,
se localiza uno que no esté siendo actualmente utilizado y se libera. Se puede liberar un marco
de memoria escribiendo su contenido en el espacio de intercambio y modificando la tabla de
páginas para indicar que esa página ya no se encuentra en memoria. Ahora se puede utilizar el
marco liberado para almacenar la página que provocó el fallo de página en el proceso.
El algoritmo de sustitución de página quedaría entonces de la siguiente forma:
1. Buscar la ubicación de la página deseada en el área de intercambio en disco.
2. Localizar un marco libre:
Si hay un marco de memoria libre utilizarlo

Si no, utilizar un algoritmo de sustitución de páginas para seleccionar un marco
víctima.
Escribir el marco víctima en el área de intercambio en disco, actualizar las tablas de
páginas y marcos correspondientes.
3. Leer la página deseada y cargarla en el marco recién liberado y actualizar las tablas de
páginas y de marcos.
4. Esperar a que el proceso sea seleccionado para ejecución y reiniciarlo donde se quedó
antes del fallo de página.
Hay que observar que cuando no se encuentra un marco libre se hacen dos transferencias de
páginas una de escritura y otra de lectura de disco, duplicando por tanto, el tiempo de respuesta
en el servicio del fallo de página y se incrementa el tiempo efectivo de acceso.
Esta carga se puede reducir en un cierto porcentaje si se agrega un bit de modificación.
Cuando se hace uso de este esquema, el hardware se encarga de modificar este bit cuando haya
un acceso de escritura a un byte o palabra de la página. cuando el sistema operativo selecciona
una página para sustitución, verifica si ha sido modificada, si es así, entonces se escribe la página
a disco, pero si no ha sido modificada entonces simplemente lee la página que se necesita del
disco y la coloca en el marco seleccionado.
3.4.3.2. Sustitución de páginas First input First Output
Este algoritmo asocia con cada página el instante en que dicha página fue cargada en me-
moria. Cuando hace falta eliminar una página, se elige la página más antigua. No es necesario
anotar el tiempo real del momento en que se cargó la página. Éste se puede substituir con una
cola tipo FIFO para almacenar todas las páginas de memoria y sustituir la página situada al
principio de la cola. cuando se carga en memoria una página nueva, se inserta al final de la cola.
El rendimiento de este algoritmo no siempre es bueno aunque es fácil de entender y progra-
mar. Un problema de FIFO es que puede desafiar la intuición al hacer que aumente el número
de fallos de página cuando se asignan más páginas reales al programa. Este comportamiento se
conoce como anomalía de Belady. Por estos problemas FIFO no es la primera elección de los
diseñadores de sistemas operativos para sustitución de páginas.
3.4.3.3. Sustitución óptima de páginas
Un algoritmo que sustituya de forma óptima las páginas solicitadas por los procesos será
aquel que tenga el menor número de fallos de página de entre todos los algoritmos y que no esté
sujeto a la anomalía de Balady. A este algoritmo se le denomina OPT o MIN.
Este algoritmo existe y puede implementarse de la siguiente forma:
Sustituir aquella página que no vaya a usarse por un período largo de tiempo.
La utilización de esta sencilla regla garantiza la tasa de fallos de página más baja posible para
un número fijo de marcos de memoria.
Por desgracia, para implementar este algoritmo es necesario saber las solicitudes futuras de
páginas y su secuencia, lo cual en la realidad es muy difícil. Por lo general este algoritmo se usa
solamente como referencia para saber qué tan buena es otra técnica de sustitución de páginas.
3.4.3.4. Sustitución LRU
Este algoritmo asocia con cada página el instante correspondiente al último uso de dicha
página. Cuando hay que sustituir una página , este algoritmo selecciona la página que no haya
sido utilizada durante el período de tiempo más largo (Least-Recently-Used).
Este algoritmo es mejor que FIFO. Esta política se considera que es en general bastante
buena. El problema viene al momento de implementarla, ya que requiere bastante asistencia del
hardware. Para implementarla existen dos posibles formas:
Pila. Esta técnica consiste en mantener una pila de número de página. Cada vez que se
hace referencia a una página, se extrae esa página de la pila y se le coloca en la parte
superior. Así la página que ha sido recientemente utilizada quedará en el tope de la pila y
aquella de haya sido menos utilizada quedará en el fondo. Esta técnica resulta particular-
mente apropiada para las implementaciones de algoritmos de sustitución LRU realizadas
mediante software o microcódigo.
Contadores. Este es el caso de implementación más simple. Se asocia con cada entrada
en la tabla de páginas un campo de tiempo de uso y se añade a la CPU un reloj lógi-
co o contador. El reloj se incrementa con cada referencia a memoria. Cuando se realiza
una referencia a una página, se copia el contenido del registro de reloj en el campo de
tiempo de uso de la entrada de la tabla de páginas correspondiente a dicha página. De
esta manera siempre se tiene el “tiempo” de la última referencia a cada página y se podrá
entonces sustituir la página que tenga el valor temporal menor. Esta estrategia requiere
realizar una búsqueda en la tabla de páginas para localizar aquella que haya sido menos
recientemente utilizada. Debe tenerse en cuenta el desbordamiento del reloj y los tiempo
deben mantenerse apropiadamente cuando se modifiquen las tablas de páginas.
El algoritmo LRU pertenece a la clase mayor de los algoritmos de sustitución de tipo pila.
Un algoritmo pila se distingue por la propiedad de actuar mejor, cuando tenga más memoria real
disponible al contrario de lo que pasa con FIFO, no sufre de la anomalía de Belady.
3.4.3.5. Sustitución por contadores
Existen varias técnicas que llevan la cuenta del número de referencias que ha tenido una
página. En general, estas técnicas manejan los siguientes esquemas:
1. Algoritmo LFU. (Least frecuently used) o la menos frecuentemente utilizada. Esta téc-
nica sustituye la página que tenga el valor más pequeño de contador. La razón para esta
selección es que las páginas que más se han utilizado deben tener un valor grande de con-
tador de referencias. Sin embargo, puede surgir un problema cuando una página se usa con
mucha frecuencia cuando comienza un proceso e inicializa su estado y luego ya no se la
vuelve a utilizar. Después de haber sido usada muchas veces, tendrá un valor de contador
alto y permanecerá en memoria a pesar de que ya no es necesaria. Una forma de dismi-
nuir este problema es desplazando una posición a la derecha los contenidos del contador
a intervalos regulares, obteniendo así un contador del uso promedio con decrecimiento
exponencial.
2. Algoritmo MFU. (Must frequently used.) o la más frecuentemente utilizada. En esta téc-
nica se argumenta que la página que tenga el valor de contador más pequeño acaba proba-
blemente de ser cargada en memoria y todavía tiene que ser utilizada.
Como puede deducirse, ninguno de los dos algoritmos se usan comúnmente debido a su ele-
vado costo computacional y además tampoco son buenas aproximaciones al intercambio óptimo
esperado, comparado con el algoritmo de sustitución óptimo.
3.4.3.6. Algoritmos de búfer de páginas
Estos son procedimientos que permiten acelerar el tiempo de reinicio del proceso que solicita
la página. De esta manera, cuando se produce un fallo de página el algoritmo puede proporcionar
inmediatamente un marco libre de un conjunto disponible de ellos, así el proceso no tiene que
esperar a que se desocupe un marco para continuar con su ejecución. El algoritmo, como los
demás, escoge también un marco víctima, lo escribe en disco, y libera el marco poniéndolo
ahora en su conjunto de marcos libres, pero esto es hecho una vez que el proceso que causó el
fallo ha sido reiniciado.
Otra forma de implementar estas estrategias, es la de mantener una lista de páginas modifi-
cadas y cada vez que el dispositivo de paginación esté desocupado, se selecciona una de ellas,
se escribe a disco y se borra el bit de modificación. De este forma se incrementa la posibilidad
de encontrar una página limpia al momento de seleccionarla para ser sustituida, de manera que
no será necesario escribirla.
Otra forma de implementación podría ser manteniendo un conjunto compartido de marcos

libres, pero recordando que página estaba almacenada en cada marco. Puesto que el contenido
de un marco no se modifica después de escribirlo en el disco, la página antigua puede reutilizarse
directamente a partir del conjunto compartido de marcos libres en caso de que fuera necesario
y si dicho marco todavía no ha sido reutilizado. Bajo este esquema, no sería necesario ninguna
operación de E/S. Cuando se produce un fallo de página, primero de comprueba si la página
deseada se encuentra en el conjunto compartido de marcos libres. Si no está ahí, se debe entonces
seleccionar un marco libre y cargar la página deseada, pero si se encuentra entonces puede
reasignarse inmediatamente al proceso solicitante.
3.4.4. Aspectos de diseño para el sistema

Desde el punto de vista del administrador de memoria, la segmentación es básicamente una
versión de la memoria particionada que utiliza múltiples parejas base-límite. Como tal, la seg-
mentación permite la división del espacio de direcciones virtuales de un proceso en varios trozos,
de modo que cada uno pueda ser asignado en particiones diferentes de memoria física. De esta
manera se elimina la necesidad de asignar un área contigua de memoria para todo el espacio de
direcciones de un proceso y así se puede realizar una administración más eficiente de la memoria
física.
Las ventajas potenciales de la segmentación van más allá de la administración de memoria.
En seguida se indican algunas de ellas:
Eliminación de fragmentación interna.
Protección.
Compartición.
Crecimiento dinámico de los segmentos.
enlace y carga dinámicos.
Desarrollo modular de programas mediante segmentos de código, datos y pila.
LA desventajas de la segmentación son:
Tamaño variable de los segmentos.
Deben de usarse técnicas complejas de compactación de memoria.
Debe haber hardware dedicado para la traducción de direcciones.

Ningún segmento puede ser mayor a la memoria física.
En cuanto al administrador de memoria virtual, éste proporciona la ilusión de un espacio de

direcciones grande que casi elimina las consideraciones impuestas por la capacidad limitada de
la memoria física. De este modo, tanto los programas de sistema como los de usuario pueden
proporcionar la funcionalidad deseada sin preocuparse de la cantidad de memoria real instalada
en un sistema dado.
Desde el punto de vista del sistema operativo, la memoria virtual proporciona capacidad
para modificar la cantidad de memoria real utilizada por cualquier programa determinado, de
modo que pueda variar el número de procesos activos en el sistema. Además la utilización de
memoria puede ser más elevada en sistemas de memoria virtual ya que las partes no utilizadas
no necesitan ser cargadas en memoria principal. Cuando se utiliza paginación, la compactación
y fragmentación externas pueden ser reducidas o eliminadas.
La principal desventaja de la memoria virtual es la complejidad del hardware y el softwa-
re necesario para soportarla. Tanto la complejidad espacial como la complejidad temporal de
los sistemas operativos de memoria virtual supera a las de los sistemas de memoria real. Los
grandes espacios de direcciones virtuales y la administración de las tablas del mapa de archivos
contribuyen a elevar considerablemente la fragmentación de la misma y en ocasiones disminuye
en gran medida el desempeño del sistema
3.4.5. Liberación de páginas

La eficiencia del algoritmo de asignación de memoria depende principalmente de la veloci-
dad con la que pueda localizarse un marco de memoria libre, en caso de no encontrarlo entonces,
se debe incluir también la velocidad de los algoritmos utilizados para escoger un marco víctima
de modo que podamos reemplazarlo con el menor impacto posible al sistema. Como puede ob-
servarse en la sección 3.4.3, para encontrar una página que sea susceptible de ser eliminada del
sistema deben se seguirse los siguientes pasos:
Buscar un marco libre de página.
Si se encuentra entonces
• Localizar la página solicitada en disco

• Cargar la página en el marco libre
• Reiniciar el proceso.
Si no se encuentra el marco libre entonces

190 3.5. PROBLEMAS
• Localizar un marco víctima de acuerdo al algoritmo (LRU,LFU,MFU o búfer)

• Guardar en búfer o en disco la página víctima.
• Localizar en disco la página solicitada
• Leer de disco la página solicitada al marco liberado
• Reiniciar el proceso.
Como puede verse, cuando el sistema no tiene marcos libres se incrementa el tiempo de
respuesta para proporcionar un marco al proceso solicitante, puesto que se debe de escoger una
página para ser liberada y luego reasignada al proceso solicitante.
3.5. Problemas
3.1. Defina con sus propias palabras el funcionamiento de la memoria principal.
3.2. ¿Cómo se organiza la memoria principal?
3.3. ¿Qué función tiene el administrador de memoria?
3.4. ¿bajo qué forma se clasifica la memoria principal? Proponga otras alternativas de cla-
sificación y explique.
3.5. Describa las estrategias de administración de memoria.
3.6. Explique los tipos de asignación de memoria con particiones.
3.7. ¿A qué se refieren los términos fragmentación interna y fragmentación externa?
3.8. Explique cómo se implementa la asignación contigua.
3.9. Explique las estrategias más comunes para la selección de un bloque de memoria.
3.10. ¿Como se soluciona la fragmentación externa de memoria?
3.11. ¿Bajo qué situaciones no es posible llevar a cabo la compactación de memoria?
3.12. ¿Cuáles son las estrategias de administración de la memoria real?
3.13. Describa cómo se lleva a cabo la administración de memoria con mapas de bits.
3.14. Explique la estrategia de administración de memoria con listas ligadas.

3.15. ¿Qué ventajas y desventajas ofrecen ambas técnicas?
3.16. Haga una comparativa sobre ambas estrategias e indique de acuerdo a sus resultados
cuál es la mejor.
3.17. ¿Para qué sirve el espacio de intercambio? ¿Con qué otro nombre se le conoce?
3.18. ¿Por qué la mayoría de los sistemas actuales implementan la memoria virtual?
3.19. ¿Cuales son las dos estrategias para la organización de la memoria virtual? Descríbalas.
3.20. Explique las dos estrategias para implementar la paginación.
3.21. ¿Cuál es la distribución lógica de segmentos que usa un programador? Describa cada
uno de ellos.
3.22. Describa los algoritmos de sustitución de páginas.
3.23. ¿Cual considera la mejor opción? Fundamente su respuesta.
3.24. ¿Cuando debe liberarse la memoria?
3.25. ¿Es lo mismo liberar una página al sistema que mandarla a la memoria virtual? Expli-
que.

Los algoritmos principales de manejo de memoria se pueden encontrar en Tanenbaum[101]
en el capítulo 4 o en Milenkovic[94] capítulo 5 y 6. Silberchatz[95] proporciona una descripción
del manejo de memoria principal en el capítulo 8 y el manejo de memoria virtual en el capítulo
9.
En cuanto a investigaciones sobre el manejo de memoria la mayoría de éstas está enfocada
sobre el manejo de memoria virtual.
Aunque no es muy actual Nelson[76] describe el manejo de la memoria física en un sistema
operativo de red y en [77] proporciona una explicación sobre el manejo de memoria virtual en el
sistema operativo Sprite. Sandberg[91] habla sobre la implementación del sistema de archivos
de memoria virtual en un sistema operativo de red de Sun. Gingell[43] explica la arquitectura de
memoria virtual en SunOS.
Appel[5] ofrece una descripción sobre las primitivas de manejo de memoria virtual para los
programa de usuario.
Li y Hudak[64] hablan sobre cómo mantener la coherencia en los sistemas de memoria

virtual compartida. Gharachorloo[42] y su equipo hablan sobre la consistencia de memoria y
el orden de eventos en sistemas multiprocesadores escalables con memoria compartida. Otro
enfoque es el manejado por Satyanarayanan[92]en su artículo Lightweight Recoverable Virtual
Memory
Los sistemas transaccionales han permitido eliminar algunas debilidades de los sistemas
en cuanto a pérdida de datos se refiere debido principalmente a fallas eléctricas o falla en las
conexiones de red. Chen y Wang[29] hablan sobre cómo implementar un soporte de bloqueo de
rango de control fino para el manejo de memoria virtual transaccional. Chew y Silberschatz[30]
hablan sobre el paradigma de memoria virtual Recuperable-persisntente.
El manejo de direcciones virtuales de 64 bits es tratado por Chase[24]
Se han abordado también los problemas de manejo de caché, por ejemplo Deville[34] quien
explica un algoritmo de reemplazo para memoria caché de bajo costo basado en el uso.
Otro artículo interesante para los académicos es el de Ashton, Ayers y Smith[6] quienes
desarrollaron una herramienta llamada SunOS Minix para usarse como laboratorio de sistemas
operativos. Esta herramienta corre como un proceso en el sistema operativo SunOs y permite
analizar el funcionamiento básico de un sistema operativo.
Capítulo 4
Administración de Entrada/Salida
A sta ahora nos hemos dedicado a analizar el funcionamiento de los algoritmos que per-
H miten administrar la CPU, los procesos y la memoria, no obstante todo ello, es parte de
dos de las tareas que debe de realizar un sistema de computadoras: el procesamiento y las ope-
raciones de entrada salida. Hasta ahora se había dejado fuera esta importante tarea que va a
permitir al sistema interactuar con el mundo externo. Los mecanismos utilizados para lograr
esta interacción son precisamente los dispositivos de entrada salida.
El sistema operativo tiene la responsabilidad de administrar y controlar las operaciones de
entrada salida que se lleven a cabo sobre todos los dispositivos del sistema.
4.1. Dispositivos y manejadores de dispositivos

Toda computadora trae consigo una cantidad mínima necesaria de dispositivos de entrada sa-
lida. Como se vio en la sección 1.1.1.2 existen muchísimos dispositivos que pueden incorporarse
a la computadora.
Como es obvio, los diseñadores de un sistema operativo no podrían dedicarse a incluir todos
los controladores necesarios para cada uno de ellos. Por tanto, en realidad únicamente lo que
hacen es proporcionar un conjunto de directivas que los programadores de los fabricantes de los
dispositivos de entrada salida deben de respetar para que su controlador pueda ser reconocido
por el sistema operativo.
Estas directivas conforman el subsistema de entrada/salida del sistema operativo o más pre-
cisamente del kernel. Esto permite aislar la complejidad asociada con la administración de los
dispositivos de entrada salida.
En la actualidad se han visto dos tendencias fuertemente confrontadas.
1. Existe una creciente estandarización de las interfaces de software y hardware, lo que per-
193
194 4.1. DISPOSITIVOS Y MANEJADORES DE DISPOSITIVOS
mite incorporar versiones mejoradas de dispositivos dentro de las computadoras y por

ende, que sean reconocidas por los sistemas operativos actuales.
2. En contraposición, existen cada vez más dispositivos de entrada salida, algunos de éstos
son tan distintos a los anteriores que constituye un gran reto el incorporarlos a nuestros
sistemas de computadora incluyendo que los reconozcan nuestros sistemas operativos.
Este desafío se enfrenta haciendo que los fabricantes se adhieran a las especificaciones bási-
cas del hardware de entrada salida, como los puertos, buses y controladores de dispositivo. Éstos
últimos comúnmente son proporcionados por los mismos fabricantes, de este modo, es posible
integrar una amplia variedad de dispositivos de entrada salida y además permiten encapsular los
detalles de los diferentes tipos de dispositivos. El núcleo del sistema operativo se estructura de
tal forma que hace uso de módulos específicos de controladores de dispositivos como sea ne-
cesario y además presenta una interfaz común de acceso a los dispositivos, permitiendo así un
acceso uniforme a todos ellos.
En varias ocasiones, el sistema operativo incluirá también un módulo de autoconfiguración
de dispositivos y un gran conjunto de controladores para este fin, pero debe quedar claro que
no estarán incluidos en el paquete del sistema operativo como tal, soló serán un extra para
poder ayudar al usuario final a configurar más rápidamente su equipo. Esta tendencia se ve
más remarcada en sistemas operativos tales como windows y Linux, en donde para ganar más
usuarios, se ha facilitado muchísimo la instalación de controladores y programas.
4.1.1. Dispositivos de I/O

Los sistemas de computadora interactúan con una gran variedad de tipos de dispositivos. La
mayoría de esos dispositivos se pueden clasificar en las siguientes categorías generales:
1. Dispositivos de almacenamiento.
2. Dispositivos de transmisión.
3. Dispositivos de interfaz humana.
Los dispositivos de almacenamiento los analizamos con cierto detalle en la sección 1.1.1.2,
resaltando que en la figura 1.3, en la parte derecha tenemos a los dispositivos de almacenamiento
masivo más comunes. Estos son discos duros, unidades de CDROM, cintas magnéticas, unidades
de memoria flash o pendrive, entre otros.
Los dispositivos de transmisión son aquellos que van a permitir a nuestra computadora co-
municarse con otros dispositivos o computadoras. Entre ellos podemos citar a las tarjetas de red
CAPÍTULO 4. ADMINISTRACIÓN DE ENTRADA/SALIDA 195
o NIC (network Interface Computer) o interfaz de red de computadora los dispositivos de rayos
infrarrojos, o aquellos que usan el estándar bluetooth, entre otros.
Entre los dispositivos de interfaz humana tenemos por ejemplo, el ratón, el teclado, la tarjeta
de vídeo y monitor, las tarjetas de sonido y bocinas, por citar algunos.
Otros dispositivos son más especializados y va a depender mucho el área de aplicación, como
por ejemplo, en control industrial.
No obstante la tremenda variedad de tipos de dispositivos, para entender cómo se conectan
éstos mediante su software específico solamente se necesitan algunos conceptos básicos.
En general los dispositivos se comunican con la computadora a través de señales que envía
por un medio físico que puede ser un cable, ondas electromagnéticas, luz, rayos infrarrojos o
rayos láser.
Cada dispositivo tiene asignado un puerto o punto de conexión, tal como un puerto USB, o
el puerto paralelo. Si los dispositivos, utilizan un conjunto de hilo o alambres, como en el caso
del puerto paralelo se le denomina entonces bus. Estos tienen a su vez asignado un protocolo
que indica cómo, cuando y qué información debe de ser enviada o recibida.
Para lograr la comunicación, el dispositivo que desea conectarse debe se hacer primero una
traducción de bytes a bits y a señales eléctricas, un cero lógico equivale a 0 voltios y un 1
lógico equivale a cinco voltios. Luego estas señales eléctricas deberán a su vez ser traduci-
das nuevamente para adecuarlas al medio correspondiente, si es un cable pueden ser mandadas
directamente, pero en otro caso, deberán ser convertidas a pulsos de luz, radiofrecuencia o in-
frarrojos. Luego las señales que viajan a través de los medios de transmisión, deben de ser al
final traducidos nuevamente a pulsos eléctricos y enviados al hardware de la computadora. El
hardware de la computadora los recibirá y a su vez traducirá estos impulsos en 0’s y 1’s lógicos,
se empaquetarán en grupos de ocho bits y serán pasados al programa correspondiente para su
uso e interpretación.
A los dispositivos que hacen esta traducción se les llama controladores de dispositivos. Un
controlador de dispositivo en un conjunto de circuitos electrónicos que son capaces de realizar
la traducción de la que hablamos en el párrafo anterior. por lo común, también es posible que
haga la traducción de la información que viene de regreso (comunicación Full Dúplex). En la
sección 4.1.2 haremos una descripción más detallada sobre éstos.
En la figura 4.1 podemos ver una distribución común del bus principal de una tarjeta base
conocido como PCI.
Como ejemplo de un controlador sencillo, tenemos el del puerto serie. Está compuesto por
un chip al que se le llama UART (Universal Asynchronous Receiver-Transmitter) Transmisor-
Receptor Asíncrono Universal, que se encarga de las transmisiones vía puerto serial y que es
usado comúnmente para conectar un módem (modulador-demodulador) o una impresora serial.
196 4.1. DISPOSITIVOS Y MANEJADORES DE DISPOSITIVOS
Figura 4.1: Arquitectura de bus clásica en una PC
También es usado para conectar terminales seriales o incluso para configurar ruteadores de in-
ternet los cuales son sistemas operativos dedicados, de modo que pueda verse la configuración
en la pantalla de la computadora y sea posible enviarles comandos de configuración.
Como ejemplo de una controladora compleja podemos encontrar a la tarjeta de vídeo, la
cual es común que tenga un procesador dedicado, memoria dedicada (podemos encontrar desde
64Mbytes hasta 512Mbytes) y un conjunto de instrucciones relativamente grande para el manejo
eficiente de gráficos. Actualmente tienen un puerto dedicado denominado AGP (Accelerated
Graphics Port). Es posible que algunas tarjetas base no cuenten con este puerto, en ese caso
tendría que conseguirse una tarjeta controladora de vídeo tipo PCI.
4.1.2. manejadores de dispositivos

Un controlador de dispositivos es una colección de componentes electrónicos que tienen
la capacidad de controlar uno o más puertos, un bus o un dispositivo. Como ejemplo pusimos
a la UART, y la tarjeta de vídeo. La mayoría de los componentes de una computadora son
controladores, tenemos entonces el controlador de bus, el controlador de discos IDE, la tarjeta
controladora del bus SCSI y los controladores de discos SCSI, por citar algunos.
La tarjeta controladora SCSI se inserta en algún slot PCI y está compuesta por un procesador,
microcódigo y cierta cantidad de memoria para procesar los mensajes del protocolo SCSI. Los
discos duros tienen su tarjeta controladora integrada en uno de sus lados y es la que permite
la conexión con los puertos IDE o SCSI. Tiene también un procesador y microcódigo para
realizar algunas tareas como el mapeo de sectores erróneos, el almacenamiento en búfer y el
almacenamiento en caché.
La CPU se comunica con las tarjetas controladoras de varias formas. Es común que éstas
dispongan de un conjunto de registros, por ejemplo, pueden tener:
1. registros de entrada.
2. registros de salida.
3. registros de control.
4. registros de estado.
Al conjunto de registros enumerados arriba se les denomina puertos de entrada salida.

En la tabla 4.1 tenemos un listado de los puertos, con sus direcciones asociadas más comu-
nes.
Rango de direcciones de E/S (Hexadecimal) Dispositivo

000-00F Controlador de DMA
020-021 Controlador de interrupciones
040-043 Temporizador
200-20F Controlador de juegos
2F8-2FF Puerto Serie (2)
320-32F Controlador de disco duro
378-37F Puerto paralelo
3D0-3DF Controlador de vídeo
3F0-3F7 Controlador de Disco Flexible
3F8-3FF Puerto Serial (1)
Tabla 4.1: Puertos de E/S más comunes en una PC
La CPU colocará un valor en el registro de salida y luego colocará otro valor en el registro de
control. De esta forma le indica que realice la operación designada por el registro de control. En
el registro de estado el controlador indicará si hubo problemas cuando se realizó la operación, o
si está listo para recibir más datos, o alguna otra información relevante.
198 4.2. MECANISMOS Y FUNCIONES DE LOS MANEJADORES DE DISPOSITIVOS
Cuando es necesario procesar muchos datos, cientos o miles de bytes, la tarjeta controlado-
ra puede tener acceso directo a memoria. En este caso, los registros de entrada y salida están
mapeados a localidades de memoria, pero la CPU ahora transferirá toda la información en esa
área de memoria y luego colocará la operación que desea que se ejecute sobre eso datos en los
registros de control.
Para saber sobre el resultado de la operación pedida a la tarjeta controladora, la CPU leerá
los registros de estado. Muchas veces es necesario informarse primeramente sobre el estado
de un dispositivo antes de intentar que realice una operación. En estos casos, la CPU leerá
primeramente los registros de estado y si el dispositivo se encuentra listo procederá a colocar
la información en los registros de entrada/salida, colocar el número de orden en los registros de
control y nuevamente leerá los registros de estado para averiguar so la operación tuvo éxito o
no.
Como la CPU corre varios órdenes de velocidad más que el proceso de los datos, la CPU
después de colocar los datos y la instrucción en los registros correspondientes, regresará al-
gún tiempo después a verificar los registros de estado. La mayoría de las tarjetas controladores
interactúan con la CPU vía interrupciones de hardware y éste generará una interrupción para
indicarle a la CPU que ha sucedido algo relevante en el procesamiento de los datos. En general
estos eventos pueden ser:
1. La información terminó de procesarse correctamente.
2. Hubo un error de entrada/salida.
3. El dispositivo está listo para recibir más datos.
Algunos sistemas usan ambas técnicas, por ejemplo, un sistema de computadora personal
utiliza instrucciones de entrada salida para controlar algunos dispositivos que no manejan mu-
chos bytes, pero maneja algunos otros con mapeo de entrada salida a memoria.
4.2. Mecanismos y funciones de los manejadores de dispositi-

vos
La tarjeta controladora, aparte de contener el hardware y el microcódigo tiene también un
conjunto de programa denominados manejadores de dispositivos que comúnmente son escritos
por los fabricantes del controlador.
Estos controladores deben de seguir las pautas establecidas por el sistema operativo para que
puedan ser fácilmente acoplados al kernel y de esta manera ser utilizados por la CPU.
4.2.1. Objetivos de los manejadores de entrada/salida

El diseño e implementación de tarjetas controladoras de dispositivos, permiten en primer
lugar, solucionar algún tipo de problema a nivel hardware. por ejemplo, una tarjeta de red va a
permitir resolver problemas de compartición de recursos entre los usuarios. No obstante, tener
sólo el hardware del controlador, no implica que el sistema operativo pueda hacer uso de esta
tarjeta, a menos que el sistema operativo tenga a su disposición una base de datos de manejadores
de dispositivos de red. De otra forma, el fabricante es quien deberá proporcionar este manejador.
Los principales objetivos que persigue el software de entrada salida son:
1. Explotar completamente las capacidades proporcionadas por el hardware.
2. Hacer una interface sencilla para que pueda usarla el sistema operativo.
3. Proporcionar un conjunto completo de instrucciones de entrada/salida para el manejo del

dispositivo.
4. Independencia del Dispositivo.
5. Los programas pueden acceder a cualquier dispositivo de E/S sin especificarlo a priori.
6. Nomenclatura uniforme.
7. independiente de la máquina.
8. Manejo de errores.
9. Manejo tan cercano al hardware como sea posible.
Es lógico que todo usuario que compra una tarjeta controladora es para obtener de ella su
máxima capacidad y de esta manera hacer más rápido su trabajo, permitirle al usuario explotar
su hardware completamente a través del sistema operativo es uno de los primeros objetivos. El
fabricante, debe proporcionar confiabilidad y desempeño para poder competir por la preferencia
del usuario.
A su vez debe proporcionar la interfaz adecuada con el sistema operativo de modo que éste
pueda soportar completamente su dispositivo.
Debe proporcionar a los programadores una amplia gama de instrucciones de modo que pue-
dan extraer todas las capacidades del hardware. Incluso hay fabricantes de dispositivos, como
por ejemplo, los que fabrican las grabadoras de CDROM o DVD que incluyen junto con su ma-
nejador de dispositivo, programas de usuario final completamente funcionales o en su defecto,
están asociados con las compañías de producción de software de grabación e incluyen progra-
mas a prueba durante cierto tiempo o con algunas características deshabilitadas, en donde con
algunas facilidades o descuentos pueden habilitarlos para su completa funcionalidad.
Actualmente, incluso las compañías ensambladoras de PC desarrollan algunos programas de
usuario final de modo que sea mucho más sencillo para éste hacer uso de todas las capacidades
que incluyen en sus equipos sin que el usuario tenga que pagar costos adicionales por el softwa-
re. Aunque comúnmente, estos programas son para periféricos específicos como grabadoras de
CDROM, cámaras de vídeo impresoras y dispositivos digitalizadores y no cuentan con muchas
de las capacidades del software propietario expresamente diseñado para usuarios avanzados.
En cuanto a la independencia del dispositivo el sistema operativo debe proporcionar los
mecanismos adecuados para poder estandarizar en la medida de los posible las llamadas a los
dispositivos de entrada/salida. La independencia de máquina se refiere al hecho que las llamadas
al sistema deben de ser fáciles de portar y además debe de haber un manejo adecuado y también
estándar para los errores que puedan generarse durante una operación de entrada salida.
4.2.2. Manejadores de interrupciones

Existen dos maneras de interactuar con las tarjetas controladoras:
1. Sondeo.
2. Manejadores de interrupciones.
En la sección 4.1.2 hablamos acerca de cómo el sistema operativo puede establecer comuni-
cación con la tarjeta controladora y la manera mediante la cual hace uso de los registros de
entrada/salida o mapeo a memoria, los registros de control y de estado. Para darnos una idea
más completa acerca de este vamos a explicar un poco el proceso de control completo que lleva
a cabo el sistema operativo con un dispositivo, mediante las dos técnicas de sondeo e interrup-
ciones.
4.2.2.1. Sondeo
El protocolo completo de interacción entre la CPU y la tarjeta controladora puede parecer

complejo, pero básicamente si se entiende el concepto de negociación puede resultar mucho más
simple de entender. Vamos a explicar este concepto con un ejemplo. Supongamos que nuestra
tarjeta controladora tiene tiene en su registro de estado dos bits para coordinar la relación pro-
ductor consumidor entre la tarjeta controladora y la CPU. La controladora entonces va a indicar
su estado mediante el bit de ocupado cuando todavía se encuentra trabajando con los datos
proporcionados anteriormente o haciendo alguna rutina de supervisión. cuando termina esta ac-
tividad borrará este bit de modo que ahora indique que se encuentra desocupado de esta forma
está avisando que se encuentra lista para recibir más datos u otras órdenes. La CPU le indica a la
tarjeta controladora que quiere procesar información poniendo el bit preparado activo para indi-
carle que en el registro de control existe ya una orden disponible con los datos correspondientes
en los registros de entrada o en el área de memoria mapeada. El proceso completo lo podemos
ver como sigue:
1. La CPU lee repetidamente el bit de ocupado hasta dicho bit esté en cero (desocupado)
2. La CPU activa el bit de escritura en el registro de control y escribe un byte en el registro

de salida.
3. La CPU activa el bit de orden lista en el registro de control.
4. Cuando la tarjeta controladora observa que está activado el bit de orden lista en el registro
de control, activa el bit de ocupada
5. La tarjeta controladora lee el registro de control y ve la orden. En seguida lee el registro de

salida para obtener el dato y lleva a cabo la operación de entrada salida hacia el dispositivo.
6. Cuando ha terminado la operación la tarjeta controladora borra el orden lista, borra el bit
de error en el registro de estado para indicar que la operación de entrada salida ha tenido
éxito y borra también el bit de ocupado para indicar que ha finalizado y está lista para
recibir más órdenes.
Este ciclo se repite para cada byte. En el paso 1, la CPU se encuentra en un estado de
espera activa o sondeo: ejecuta un ciclo leyendo repetidamente el registro de estado hasta que
se desactive el bit de ocupado. Si la tarjeta controladora es de alta velocidad y el dispositivo
también, este método resulta razonablemente rápido, pero si la espera es larga, sería entonces
conveniente que la CPU conmutara a otra tarea. Más si hace esto no habrá forma de saber si la
tarjeta controladora ya terminó su operación de entrada salida. En algunos dispositivos la CPU
debe proporcionar un flujo continuo de datos hacia la controladora, de otra forma habría una
pérdida de datos. por ejemplo, cuando se graba un CDROM, si la unidad se queda sin datos, el
disco seguirá girando y dejará entonces un área sindatos haciendo el disco inutilizable. Incluso
aunque la mayoría de las grabadoras tienen búferes dedicados, si la CPU tarda más tiempo del
debido en enviar los datos puede correrse el riesgo de que el búfer también se vacíe.
Es común que una operación de sondeo no involucre más de cuatro operaciones para la CPU:
por ejemplo:
ciclo:
IN AL, Puerto
AND AL,0001000b
JNZ masdatos:
JMP ciclo
fin:
Como puede verse, la operación de sondeo resulta ser muy eficiente. Sin embargo, estas
operaciones se encuentran dentro de un ciclo, lo que puede hacerla en extremo ineficiente si es
que la tarjeta controladora no es tan rápida como la CPU. En este caso la CPU va a encontrarse en
muchas ocasiones que la tarjeta controladora aún no está lista para recibir más datos, mientras
que otras tareas que serían más útiles tendrían que esperar a que la CPU se desocupe para
continuar con su procesamiento normal.
En los casos en donde el dispositivo es demasiado lento, es más eficiente que la controladora
avise a la CPU cuando ya terminó de hacer su tarea en lugar de que ésta espere leyendo su
registro de estado. A este mecanismo se le conoce como interrupción y lo analizaremos en el
siguiente apartado.
4.2.2.2. Interrupciones
El mecanismo de interrupción funciona de la siguiente manera:
1. El hardware de la CPU tiene un pin llamado línea de solicitud de interrupción que la CPU
comprueba vía hardware después de ejecutar cada instrucción.
2. Cuando la CPU detecta que una tarjeta controladora ha activado una señal a través de esta
línea, la CPU guarda el estado actual y salta a la rutina de servicio de interrupción situada
en una dirección fija de la memoria.
3. La rutina de servicio de interrupción determina la causa de la interrupción.
4. Lleva a cabo el procesamiento necesario.
5. Realiza una restauración del estado.
6. Regresa a la tarea que estaba ejecutando en el mismo instante en que fue interrumpida.
En realidad, como observamos en la figura 4.1, existe un controlador de interrupciones que se

encarga de administrar a las diferentes interrupciones que pueden generar todos los dispositivos.
Esto es debido a que el procesador sólo tiene una línea de interrupción para atender a todos
ellos.
El mecanismo básico de interrupción permite a la CPU responder a un suceso asíncrono,
esto es cuando una tarjeta controladora ha hecho una solicitud de atención y pasa al controlador
de interrupciones quien será el encargado de avisar a la CPU. En caso de que lleguen más solici-
tudes por parte de otras tarjetas controladoras, el controlador de interrupciones las irá poniendo
en una cola para que sean servidas de acuerdo a como se hayan ido generando. En los sistemas
operativos actuales, no obstante, se requieren mecanismos más sofisticados de tratamiento de
interrupciones. A continuación encontramos una lista de estas necesidades.
1. En ocasiones es necesario diferir el tratamiento de una interrupción, por ejemplo, cuando

un proceso se encuentra en su zona crítica y no debe ser interrumpido hasta que la termine.
2. se necesita una manera de tratar eficientemente la interrupción generada sin necesidad de

buscar qué dispositivo fue el que la generó
3. Se necesita también un sistema de interrupciones multinivel, de modo que el sistema ope-

rativo pueda distinguir entre aquellas interrupciones que sean de alta o baja prioridad, y
así pueda responder con el grado de urgencia apropiado.
En los sistemas de computadora actuales, estas funcionalidades las proporciona la CPU y el

hardware de la tarjeta controladora de interrupciones.
La mayoría de los procesadores actuales cuenta con dos pines o líneas de interrupción:
Interrupciones no enmascarables. Son aquellas que están reservadas para sucesos que
se refieren al hardware de la computadora y que no pueden ser retrasadas.
Interrupciones enmascarables. Estas pueden ser desactivadas por la CPU antes de la

ejecución de secuencias críticas de código que no deben ser interrumpidas. Estas son las
que comúnmente utilizan las tarjetas controladoras para pedir la atención de la CPU.
El mecanismo de interrupción acepta una dirección, que es el número que selecciona una
rutina específica de servicio de interrupciones de entre un pequeño conjunto de rutinas dispo-
nibles. En muchas de las arquitecturas, esta dirección es simplemente un desplazamiento que
empieza a contar desde la parte baja de la memoria y que se denomina vector de interrupciones.
Este vector contiene las direcciones de memoria de las rutinas especializadas en el servicio
de interrupciones. El propósito de este mecanismo es reducir la necesidad de que una única rutina
de tratamiento de interrupciones tenga que analizar todas las posibles fuentes de interrupción
para determinar qué dispositivo la generó.
Número de Vector (Interrupción) Descripción

0 Error de división
1 Excepción de depuración
2 Interrupción nula
3 punto de ruptura de ejecución
4 Desbordamiento
5 Excepción de rango
6 Código de operación no válido
7 Dispositivo no disponible
8 Fallo doble
9 Desbordamiento de segmento en coprocesador
10 segmento de estado de tarea inválido
11 Segmento no presente
12 Fallo de pila
13 Error de protección general
14 Fallo de página
15 Reservada para intel
16 Error de coma flotante
17 Error de alineación de memoria
18 Comprobación de máquina
19-31 Reservada para Intel
32-255 Interrupciones enmascarables
Tabla 4.2: Vector de interrupciones para los procesadores i386
En la realidad existen más dispositivos que lugares en el vector de interrupciones. En ge-

neral, este vector no es mayor a 256 posiciones. Una forma común de resolver este problema
es mediante el uso de interrupciones encadenadas en la que cada elementos del vector de inte-
rrupciones apunta a la cabeza de una lista de rutinas de servicio de interrupción. De este modo,
cuando se genera una interrupción, se llama una a una de las rutinas de la lista correspondiente
hasta que se encuentre la rutina adecuada para el manejo del evento.
Otra forma de implementar esta lista, debido a que en ocasiones el sistema no sabe cuantas
rutinas existen, es permitir que los manejadores de dispositivo se encadenen de acuerdo a como
vayan siendo instalados en el sistema. El último, por regla general debe mandar a traer una rutina
de suceso no manejable, en caso de que ninguna las rutinas haya podido dar servicio al evento.
Estas estructuras presentan el compromiso entre el gasto asociado a disponer de una tabla de
interrupciones de gran tamaño y la poca eficiencia que se experimenta a la hora de proporcionar
servicio a las interrupciones con la otra opción que consiste en proporcionar una sola rutina de
servicio de interrupción.
En la tabla 4.2 vemos la asignación del número de interrupción con la del evento que lo ge-
nera. Dentro cada elemento del vector de interrupciones tenemos comúnmente un par de direc-
ciones de tipo CS:CP. Esto es, tenemos la dirección del segmento de código y su correspondiente
desplazamiento para el contador del programa dentro de ese segmento.
También podemos observar que las interrupciones en el rango de 0-31, son no enmascarables
y se utilizan para señalizar diversas condiciones de error. Las interrupciones que van de la 32 a la
255, son enmascarables, se utilizan para todas las interrupciones generadas por los dispositivos.
El mecanismo de interrupciones también implementa un sistema de niveles de prioridad de
interrupción. Este mecanismo permite a la CPU diferir el tratamiento de las interrupciones de ba-
ja prioridad sin enmascarar todas las interrupciones. También hace posible que una interrupción
de alta prioridad desaloje a otra interrupción de prioridad más baja.
Los sistemas operativos actuales interactúan con el controlador de interrupciones de varias
formas. En primer lugar, durante el arranque, el sistema operativo comprueba los buses hard-
ware pare determinar qué dispositivos existen e instalar las rutinas de servicio de interrupción
correspondientes dentro del vector de interrupciones. Durante las operaciones de entrada salida,
las diversos controladores de dispositivos generan interrupciones cuando están listas para llamar
la atención a la CPU. Estas interrupciones pueden indicar que ha terminado una operación de
entrada salida o que hay disponibles datos para ser leídos o que acaba de ocurrir algún error que
debe ser atendido.
El mecanismo de interrupciones también se utiliza, como puede verse en la tabla 4.2 para
manejar las excepciones, como la división por cero, el acceso no autorizado a localidades de
memoria protegidas o que están más allá de la memoria física y virtual. También existen algunas
interrupciones que son usadas por los depuradores, por ejemplo, la interrupción uno y la tres.
En resumen todas las interrupciones no enmascarables obligan a la CPU a ejecutar rutinas
que se consideran como urgentes, por la gravedad o importancia de la excepción.
4.2.3. Manejador de dispositivos

Hasta ahora, hemos hablado del hardware y de los mecanismos que puede usar el sistema
operativo para tratar directamente con un dispositivo, pero lo más común es que el fabricante del
mismo proporcione un conjunto de rutinas que deben de agregarse al sistema operativo mediante
módulos para que éste pueda manejar adecuadamente su dispositivo. A este conjunto de rutinas
se les denomina manejador de dispositivo. En realidad es el manejador de dispositivo el que
interactúa con el sistema operativo y la tarjeta controladora.
Figura 4.2: Estructura de Entrada/Salida de un kernel
En la figura 4.2 podemos ver cómo el sistema operativo provee solamente una interfaz que
se denomina subsistema de entrada salida del kernel mediante la cual se acoplan todos los
manejadores de dispositivo de manera que puedan interactuar ambos.
El tipo de interacción entre el manejador y el sistema operativo puede ser de dos tipos:
Entrada/Salida programada. También llamada PIO (programmed I/O). Bajo este esquema, el
manejador solicita a la CPU byte por byte y lo va procesando tal como van llegando. Como
puede verse, es computacionalmente hablando muy caro. La mayoría de los manejadores
evita esta sobrecarga y los fabricantes comúnmente agregan un procesador dedicado para
ejecutar esas tareas.
Acceso directo a memoria. El manejador de dispositivo tiene asignado un bloque de memoria

y la CPU le envía solamente la dirección en donde se requiere la información. El ma-
nejador hace la tarea, liberando a la CPU de ese trabajo. Para iniciar una transferencia
de bloque tipo DMA, la CPU escribe la dirección del bloque en los registros de entra-
da mediante el manejador de dispositivo. Le indica también el destino o en su defecto la
operación que se debe llevar a cabo sobre los datos y se dirige a realizar otras tareas.
Aunque en el párrafo anterior se haya hecho referencia a que el manejador de dispositivo

es el que realiza la transferencia, en la realidad, existe otro manejador denominado manejador
de DMA el cual ejecuta esta tarea mediante la tarjeta controladora de DMA que se encarga de
sincronizarse en el acceso directo a la memoria procurando lo menos posible intervenir con
la CPU. Esto es, este controlador es el que se encarga de hacer uso del bus de direcciones y
de datos para realizar la transferencia efectiva entre el manejador de dispositivo y la memoria
sin la intervención de la CPU. Mientras se esté realizando una transferencia entre la tarjeta
controladora y la memoria , la CPU no podrá realizar ningún acceso a memoria, aunque sí
puede acceder a su memoria caché a a la memoria secundaria. A esto se le conoce como robo
de ciclos puesto la CPU tiene que esperar a que se desocupe el bus para acceder a la memoria si
es que está ocupada.
Cuando se ha terminado la tarea el manejador de DMA envía una interrupción al procesador
para indicar que la tarea ha sido concluida.
4.3. Estructuras de datos para manejo de dispositivos

El siguiente nivel dentro de la administración de dispositivos de entrada/salida tenemos al
subsistema de E/S del kernel. Este es una interfaz común de la cual pueden hacer uso todos los
manejadores de dispositivos.
El kernel además proporciona servicios relacionados con la E/S tales como:
1. Planificación.
2. Almacenamiento en búfer.
3. Almacenamiento en caché.
4. Administración de colas.
5. Reserva de dispositivos.
6. Tratamiento de errores.
4.3.1. Planificación de Entrada/Salida

. Significa determinar un orden mediante el cual se debe de ejecutar las órdenes de entra-
da/salida. Muchas veces, el orden en el cual son solicitadas no es la mejor manera de ejecutarlas.
Bajo una buena planificación es posible elevar el desempeño de sistema, puesto que va a permitir
compartir el acceso a los dispositivos de forma equitativa entre los distintos procesos y puede
reducir el tiempo de espera promedio requerido para que la entrada/salida se complete.
208 4.3. ESTRUCTURAS DE DATOS PARA MANEJO DE DISPOSITIVOS
Los diseñadores de sistemas operativos implementan los mecanismos de planificación man-

teniendo una cola de espera de solicitudes para cada dispositivo. Cuando una aplicación ejecuta
una llamada al sistema de entrada/salida solicitando a su vez el bloqueo, la solicitud se coloca
en la cola correspondiente a dicho dispositivo. El planificador de entrada/salida reordena la cola
para mejorar la eficiencia global del sistema y el tiempo promedio de respuesta experimentado
por las aplicaciones.
El sistema operativo puede escoger en dar un servicio equitativo a todos los procesos que
demandan servicios de entrada/salida o pueden también privilegiar a ciertos procesos que tienen
mayor prioridad y que son sensibles a la pérdida de datos si no se atienden con la suficiente
rapidez.
Cuando el sistema operativo soporta mecanismos de entrada salida asíncrona, debe también
ser capaz de controlar múltiples solicitudes de entrada/salida que lleguen simultáneamente. Para
solucionar este problema, el sistema operativo hace uso de una cola de espera asociada a cada
dispositivo de entrada/salida. En esta estructura de datos el sistema operativo mantiene informa-
ción acerca del estado del dispositivo.
4.3.2. Almacenamiento en búfer

Un búfer es un área de memoria que permite almacenar datos temporalmente mientras se
están transfiriendo entre dos dispositivos o entre un dispositivo y un proceso o aplicación. El
almacenamiento en búfer se realiza por tres razones:
1. Permite adaptar las diferentes velocidades de los dispositivos o la aplicación.
2. Permite adaptar el tamaño de transferencia de datos que pueden tener dispositivos diferen-
tes. Esto es el tamaño de búfer interno puede variar de dispositivo a dispositivo. Entonces
con un búfer intermedio puede resolverse este problema.
3. Permite también mantener la integridad de los datos durante una transferencia de datos.
Esto suele pasar cuando una aplicación hace una llamada al sistema operativo para escribir
información de su búfer, el sistema operativo copia primero esos datos a otro búfer y libera
a la aplicación. Si la aplicación hace cambios en su búfer, éstos no se reflejarán en disco
puesto que fueron hechos después de la llamada de escritura.
4.3.3. Almacenamiento en caché.

Una caché es una región de memoria rápida que alberga copias de ciertos datos. El acceso
a la copia almacenada en la caché es más rápida que la que se hace a la memoria principal. No
debe confundirse el almacenamiento en búfer con el de la caché. Un búfer puede almacenar la

única copia existente de un elemento de datos, mientras que una caché, por definición, almacena
en un dispositivo más rápido una copia de un elemento de datos que existe en otro lugar.
4.3.4. Administración de colas

Una cola de dispositivo es un búfer que almacena la salida dirigida a un dispositivo, por
ejemplo, una impresora, que no pueda aceptar flujos de datos entrelazados. Aunque una impre-
sora solo puede dar servicio a un trabajo a la vez, es posible que varias aplicaciones quieran
hacer uso de la impresora en un mismo instante. por supuesto que si el sistema operativo permi-
tiera esa situación, los trabajos enviados se mezclarían siendo así inservibles. para resolver este
problema, el sistema operativo intercepta toda la salida dirigida a la impresora y va almacenan-
do cada trabajo en un archivo de disco separado. Cuando una aplicación termina de imprimir,
el sistema de administración de colas pone otro archivo temporal en la impresora. Esta admi-
nistración puede llevarse a cabo ya sea por un hilo del sistema operativo o por un demonio de
impresión. Cualquiera de estas técnicas permiten al usuario a al administrador ver el estado de
impresión de los trabajos o de las impresoras, así como agregar nuevos trabajos, suspenderlos si
hay un error o eliminarlos.
4.3.5. Tratamiento de errores

Un sistema operativo que utilice memoria protegida debe de prever los posibles errores de
hardware y de las aplicaciones, de modo que cada pequeño error no provoque un fallo completo
del sistema. Los dispositivos y las transferencias de entrada salida pueden fallar de muchas
maneras, debido a razones transitorias como por ejemplo, cuando una red local se sobrecarga y
no es capaz de comunicar adecuadamente dos computadoras o razones más graves como cuando
falla la tarjeta controladora de disco o hay un error en la memoria principal.
Cuando ocurre un error de entrada salida es normal que el sistema operativo reintente la
operación algunas veces para tratar de recuperarse del error, pero si el fallo es permanente, el
sistema operativo debe de buscar la forma recuperarse perdiendo la menor cantidad de datos
posible y evitando también que sean afectadas otras aplicaciones.
La forma en que UNIX o Linux indican que ha sucedido un error es mediante una función
llamada errno(), la cual devuelve cero si es que no ha habido error al efectuar una operación de
entrada salida y devuelve un valor distinto de cero en caso de haberlo. El número indica el error
y puede a su vez ser traducido a una cadena de caracteres, indicando el error en texto por otra
función llamada perror() que asocia directamente el número de error que regresaría la función
210 4.3. ESTRUCTURAS DE DATOS PARA MANEJO DE DISPOSITIVOS
errno() con su mensaje.
4.3.6. Espacio del usuario para software de I/O
Como es de esperarse, el sistema operativo debe de tener control absoluto sobre cualquier
intento de entrada salida que desee llevar a cabo el usuario. Esto es así debido a que es la única
forma de verificar si el usuario realmente tiene derecho a efectuar algún tipo de operación de
entrada salida. Como podemos ver, entonces la mayoría del software de entrada salida se va
a encontrar en el sistema operativo y éste proporcionará un conjunto de llamadas (llamadas
al sistema) que permitirá al usuario interactuar con los dispositivos de entrada salida bajo la
supervisión del kernel.
La biblioteca estándar stdio.h es un buen ejemplo de ello. Si el usuario desea leer un bloque
de datos de un archivo usará entonces la instrucción read(file-des,buffer, bytes-solicitados)
esta función quedará enlazada en el programa del usuario, pero el sistema operativo se encarga
primeramente de verificar que el usuario tenga los derechos pertinentes de lectura del archivo
solicitado antes de leer los datos de disco. Entonces, aunque el usuario tiene una amplia gama de
funciones que puede usar para llevar a cabo sus tareas, el sistema operativo verificará si es que
tiene los permisos correspondientes sobre el recurso que está solicitando para que pueda llevarse
a cabo la solicitud.
Hay que aclarar que el sistema operativo puede delegar algunas tareas a procesos especia-
lizados en algún dispositivo de entrada salida, por ejemplo, tenemos al servidor de impresión.
Un usuario envía su trabajo a una impresora que en realidad está representada por una cola de
impresión. La cola de impresión mantendrá el trabajo hasta que sea su turno de enviarlo real-
mente a la impresora. En este caso, el servidor de impresión es el único proceso que tiene acceso
directo a la impresora de modo que ningún usuario puede hacer uso directo de ésta a no ser que
sea por medio de ese servidor.
Otro ejemplo, es el servidor gráfico o el servidor X, este servidor es el que se encarga de

manejar la tarjeta gráfica. Es imperativo hacer uso de éste si se desea mandar algún tipo de
información gráfica. En este caso también el kernel delega las funciones necesarias de la tarjeta
de vídeo al servidor X de modo que sea el único que puede tener acceso directo a la misma. Si
alguien desea acceder a este recurso tiene que ser entonces por medio del servidor gráfico.
4.4. Operaciones de Entrada/Salida

4.4.1. Discos RAM
Un disco RAM o ramDisk (Random Access Memory Disk) es un área de memoria que se
configura como un disco físico Tiene las siguientes ventajas.
1. Es muy rápido en comparación con un disco tradicional, puesto que se accede a memoria
en lugar de un disco duro tradicional.
2. Puede formatearse.
3. Es transparente a las aplicaciones, puesto que no habrá diferencia en cuanto a las instruc-
ciones que se usarán para acceder a éste.
4. Se pueden tener tantos discos RAM como se deseen, restringiendo solamente a la cantidad
de memoria física con la que cuente el sistema y la que necesita el sistema operativo para
poder funcionar adecuadamente.
5. La memoria RAM ha ido bajando continuamente de precio.
Las desventajas de los discos RAM son:
1. Muy baja capacidad de almacenamiento.
2. Quita gran cantidad de memoria al sistema operativo, lo que puede ocasionar que baje el
desempeño del sistema, teniendo que hacer más intercambio con el disco físico.
3. La memoria RAM es volátil y en el momento que se quita la energía eléctrica los datos se
pierden.
De acuerdo con esas ventajas, podemos básicamente ejecutar cualquier servicio cuyos da-
tos puedan caber en el disco RAM. Por ejemplo, un servidor DNS, cuyos archivos son muy
pequeños o un sitio web que no exceda, por ejemplo, los 128Mbytes.
En caso de hacerlo, hay que recordar que antes de que pueda funcionar adecuadamente es
necesario copiar la información del disco normal al disco RAM. A partir de ese momento, las
consultas al servidor WEB serán mucho más rápidas, por que ya no se tendrá que hacer un
acceso al disco duro.
También sería posible poner una base de datos pequeña en un disco RAM, principalmente
aquellas en donde es predominante la lectura y con pocos o ningún acceso de tipo escritura. En
caso de que haya escrituras, se debe sincronizar la base de datos del disco RAM con la base de
212 4.4. OPERACIONES DE ENTRADA/SALIDA
Figura 4.3: Ubicación de un disco RAM en memoria
datos en disco duro, cada cierto tiempo, para poder reflejar los cambios en los datos cuando el
servidor se reinicie.
En la figura 4.3 muestra cómo se distribuye la memoria cuando se da de alta un disco RAM.
El disco RAM se divide en n bloques, según la cantidad de memoria que se haya asignado.
Cada bloque es del mismo tamaño del que es usado en un disco real. cuando el manejador
recibe un mensaje para leer o escribir un bloque, simplemente determina el lugar en la memoria
correspondiente al disco RAM y efectúa la operación. La forma de hacer un disco RAM en
Linux es la siguiente:
Crear el directorio donde se montará el ramdisk
Crear el sistema de archivos en disco (formatearlo)
Montar el ramdisk en el directorio creado.

Con las órdenes quedaría así: mkdir -p /media/ramdisk0 mkfs -t ext3 /dev/RAM0 mount
/dev/RAM0 /media/ramdisk0
A partir de este momento se puede usar como cualquier otra partición.
4.4.2. Discos
Los discos, hasta ahora, han sido el medio de almacenamiento secundario más usados. Un
disco duro, es un dispositivo que puede grabar y recuperar grandes cantidades de información en
tiempos relativamente rápidos en comparación con otros medios de almacenamiento secundario,
como por ejemplo, las unidades de CDROM o las cintas magnéticas.
Un disco duro está compuesto de varios elementos. Por ahora describiremos el funciona-
miento general de éste. En primer lugar, la información se almacena en unos finos platos o
discos, generalmente de aluminio, recubiertos por un material sensible a alteraciones magnéti-
cas. Estos discos, cuyo número varía según la capacidad de la unidad, se encuentran agrupados
uno sobre otro y atravesados por un eje, y giran a gran velocidad.
Cada disco posee dos diminutos cabezales de lectura/escritura, uno en cada cara. Estos ca-
bezales se encuentran flotando sobre la superficie del disco sin llegar a tocarlo, a una distancia
de unas 3 o 4 micropulgadas, siendo una distancia mucho menor que el diámetro de un cabello
humano. Por ello, es importante nunca abrir un disco duro (a menos que ya no funcione), por
que simple y sencillamente, al momento de abrirlo, le caerá polvo y este hará que las cabezas,
rayen la superficie de los datos, con el consecuente daño permanente del disco. Estos cabezales
generan señales eléctricas que alteran los campos magnéticos del disco, dando forma a la infor-
mación. (dependiendo de la dirección hacia donde estén orientadas las partículas, valdrán 0 o
valdrán 1).
La distancia entre el cabezal y el plato del disco determinan la densidad de almacenamiento
de éste, ya que cuanto más cerca estén el uno del otro, más pequeño es el punto magnético y así
podrá almacenar más información.
En la figura 4.4 podemos ver la distribución de sus elementos de hardware más sobresalien-
tes. En general, está compuesto por su tarjeta controladora, los platos o discos y el brazo que
sostiene las cabezas de lectura/escritura. Para poder mover todos estos elementos cuenta con
dos motores: el que hace girar los discos a alta velocidad y un motor de pasos que hace que se
posicione la cabeza de lectura escritura en un lugar radial predeterminado.
4.4.2.1. Hardware de discos
Una unidad de disco está compuesto por el controlador de disco y además contiene un paque-
te de discos, también denominado volumen. El paquete de discos está formado por un conjunto
Figura 4.4: Vista interna de un disco duro
de superficies cubiertas de una capa que puede magnetizarse o desmagnetizarse (discos) monta-
dos sobre un eje.
Cuando opera, el eje y los discos rotan a una alta velocidad, dependiendo de la tecnología,
actualmente encontramos velocidades que van desde las 5400 revoluciones por minuto (RPM)
y 7200.2 RPM en discos IDE y SATA hasta las 10,000 y 15000 RPM en discos con tecnología
SCSI . Los datos se graban sobre las pistas, que son circulares y que se encuentran sobre cada
superficie. Las pistas que se encuentran unas sobre otras forman cilindros.
Tenemos un conjunto de cabezas de lectura/escritura ubicadas al final de un brazo que se
mueven como un grupo, de tal forma que éstas pueden ser posicionadas sobre todas las pistas de
un mismo cluster. De este modo, toda la información de un cluster puede ser accedida sin tener
que mover el brazo, que es la operación más lenta.
Un cilindro por tanto, puede leerse completamente en un sólo giro de los platos del disco sin
tener que mover las cabezas de lectura/escritura.
Las pistas se dividen en porciones, que son las unidades más pequeñas de espacio que se
pueden acceder, y pueden ser sectores o bloques.
En la figura 4.5 podemos ver gráficamente cómo están definidas estas divisiones lógicas de
disco.
sectores. Son divisiones físicas y, por tanto, de tamaño fijo. Los sectores van numerados, de
modo que sectores consecutivos tienen números consecutivos. Es común que un sector
sea accedido de una sola vez por una cabeza lectora/escritora.
Cilindros. Un cilindro está compuesto por todos los clusters que se encuentran en la misma
pista y que pueden accederse sin mover las cabezas de lectura/escritura, pero los platos
Figura 4.5: Divisiones lógicas de un disco
dando una vuelta completa.
Clusters. Un cluster es una cantidad fija de sectores contiguos, Por lo común se de-
nomina cluster a aquellos sectores que pueden ser accedidos por todas las cabezas
lectoras/escritoras en una sola operación en la posición en que se encuentran y cons-
tituye la unidad de espacio más pequeña que se puede asignar a un archivo. Una vez
se localiza un cluster, no hay que mover las cabezas para leer todos sus sectores.
Extent. Un extent es un trozo de archivo formado por varios clusters contiguos. Me-
diante ellos se pretende enfatizar más la contigüidad física de los sectores. Lo ideal
(en acceso secuencial) es tener un solo extent. Cuantos más haya, más desperdiga-
do estará el archivo y, por lo tanto, más tiempo se dedicará a mover las cabezas de
lectura/escritura.
Bloques. Son divisiones lógicas y, por lo tanto, su tamaño es variable. Este tamaño puede ser
distinto para cada aplicación, y se puede fijar como un múltiplo del tamaño de registro,
por lo que no hay problemas de fragmentación interna. Los bloques contienen datos e
información sobre los datos: tamaño en bytes y, en ocasiones, una clave indicando, por
ejemplo, el valor de algún campo clave del último registro del bloque. Además, hay in-
formación invisible al programador al principio de cada bloque, más cantidad que con los
sectores.
Cuando las pistas se encuentran divididas en sectores hay problemas de fragmentación in-
terna debido a que todos los sectores son del mismo tamaño: si en un sector no cabe un múltiplo
del número de registros, hay huecos.
Al principio de cada sector hay información invisible al programador en donde figura la
dirección del sector, la dirección de la pista en la que se encuentra y su condición (en buen
estado o defectuoso).
Comparando sectores y bloques, estos últimos ofrecen mayor flexibilidad: se ahorra tiempo
y se consigue mayor eficiencia, ya que el programador determina cómo se van a organizar los
datos en disco. Los bloques son superiores a los sectores cuando se desea que la localización
física de los archivos corresponda con su organización lógica. Sin embargo, el programador y/o
el sistema operativo deben hacer trabajo extra para determinar la organización de los datos.
La dirección de un registro en disco, normalmente necesita información sobre el número de
cilindro o el número de cluster, la superficie y el sector o bloque.
Costo del acceso a disco En general, existen tres factores que afectan directamente a la veloci-
dad con que los datos se transfieren entre disco y memoria principal. Cada uno de estos factores
consume un tiempo y conlleva una operación física.
Refiérase a la sección 1.1.1.2 para ver algunas tasas de transferencia comunes en los discos
duros.
Tiempo de búsqueda (seek). Es el tiempo necesario para mover el brazo con las cabezas de
lectura/escritura desde su posición actual hasta el cilindro direccionado. El brazo puede
estar sobre el cilindro deseado, tener que ir al siguiente cilindro o al otro extremo del
disco; por lo tanto, dependiendo de la distancia a recorrer, será más o menos caro. En un
sistema multiusuario este tiempo es más notable ya que cada usuario estará accediendo
a un archivo distinto y lo más probable es que en cada acceso de cada usuario haya que
emplear un tiempo de búsqueda que será, por término medio, el tiempo de recorrer un
tercio del número de cilindros.
Tiempo de rotación (latencia). El disco debe girar hasta que la cabeza esté situada sobre el
sector a leer o escribir. El tiempo medio es el tiempo requerido para dar media vuelta.
Tiempo de transferencia. Es el tiempo empleado en leer o escribir los datos. Este tiempo es
función del número de bytes transferidos (número de bytes transferidos / número de bytes
por pista ∗ tiempo de dar una vuelta).
Hasta ahora hemos analizado, de forma general la estructura física de un disco duro. El sis-
tema operativo debe de establecer ciertas divisiones que agrupan a varios bloques, clusters o
cilindros en unidades más grandes denominadas particiones y además debe de incluir la infor-
mación necesaria para poder manejar un disco.
De acuerdo a lo anterior un disco será dividido lógicamente en los siguientes espacios:
Sector de Arranque. Llamado también Master Boot Record (MBR) por sus siglas en inglés
o registro de arranque maestro. Es en este lugar donde el BIOS buscará un cargador de
sistema operativo.
Particiones. Las particiones son conjuntos de bloques, clusters o cilindros que serán manejados
como una unidad. Deben definirse en el momento de la instalación del sistema operativo
o con un programa especializado (comúnmente se llama fdisk). Una partición también
puede marcarse como arrancable. Esto indicará al cargador que está en el Master Boot
Record que proporcione las diferentes opciones al usuario para que pueda cargar otros
sistemas operativos. No todos los cargadores reconocen o dan estas opciones al usuario.
Existen dos tipos de particiones:
Particiones primarias. Son aquellas que pueden marcarse como arrancables y no

pueden tener particiones lógicas.
Particiones extendidas. Son aquellas que pueden contener una o más particiones
lógicas. Las particiones lógicas no pueden ser arrancables.
Un disco solamente puede soportar cierto número de particiones primarias. Si se necesitan

más particiones que las soportadas entonces deben de crearse particiones extendidas. El
sistema operativo verá cada partición como si fuera una unidad de disco independiente.
Es recomendable siempre hacer al menos dos particiones: una para el sistema operativo y
otra para los datos. En caso de que llegara a suceder un fallo en alguna partición, ésta no
afectará a las demás. También es más fácil respaldar particiones de menor tamaño que un
disco duro completo con una sola partición.
Espacio no particionado. En ocasiones, cuando se desea instalar más de un sistema operativo,

solamente se divide el disco en las particiones necesarias y asignarles su espacio corres-
pondiente. Se puede entonces dejar espacio libre que no podrá ser reconocido por otro
sistema operativo, hasta que el usuario no haga el proceso de particionado.
4.4.2.2. Software para discos
En la sección anterior hablamos acerca de la estructura general del disco duro. En este apar-
tado nos concentraremos en el software que se debe de utilizar para poder tener funcionando un
disco duro.
Lo primero que se debe hacer al comprar un disco duro, es instalarlo dentro de nuestro
sistema de computadora. De acuerdo al tipo de disco duro, podemos tener tres, como se comentó
en la sección 1.1.1.2 Discos IDE, SATA y SCSI. Cada uno de ellos trae sus propios conectores
y es inconfundible la forma de conectarlos.
Después de haber instalado el disco duro, el siguiente paso es decidir el número de particio-
nes que vamos a necesitar. Por lo común hay que pensar primero si se van a tener dos sistemas
operativos. Como dijimos, cada uno debe de tener al menos una partición para el sistema ope-
rativo y otra para los datos. En caso de instalar alguna versión de windows con dos particiones
será suficiente. Si vamos a tener dos sistemas operativos, entonces hay que crear al menos cua-
tro particiones. Los sistemas basados en UNIX, como Solaris o Linux necesitarán al menos las
siguientes:
/ La partición Raíz. Aquí es donde se guardará el núcleo y los archivos de dispositivos, las
órdenes del sistema y los de usuario correspondientes al sistema operativo (/sbin y /bin) y
los archivos de configuración del sistema.
swap Esta es la partición de intercambio para la memoria virtual.
/var En esta partición se guardan los datos variables o que van cambiando continuamente, como
los archivos de logs o avisos del sistema y de otros servicios.
/usr Aquí se guardan las aplicaciones del usuario.
/home Aquí se guarda la información de los usuarios del sistema.
/tmp En esta partición se guardan datos temporales, como por ejemplo, visualizar un archivo,
pero sin descargarlo al espacio de usuario. En esta área,los archivos aquí guardados per-
manecerán poco tiempo que va desde un día hasta una semana. Por tanto no es correcto
usarla para guardar archivos importantes.
El programa que se usa para llevar a cabo el particionado de disco se llama fdisk. En el
entorno gráfico de windows tiene una herramienta que se llama administrador de discos. Tanto
en unix como en linux se llama fdisk. Es recomendable saber primero los nombres de los discos
un sistema UNIX/Linux. Esto se consigue con la opción fdisk -l. En el siguiente listado vemos
una salida típica de la ejecución de este comando.
debian:/home/nalonzo# fdisk -l
Disco /dev/hda: 160.0 GB, 160041885696 bytes

255 cabezas, 63 sectores/pista, 19457 cilindros
Unidades = cilindros de 16065 * 512 = 8225280 bytes
Disposit. Inicio Comienzo Fin Bloques Id Sistema

/dev/hda1 * 1 9561 76798701 7 HPFS/NTFS
/dev/hda2 9562 19457 79489620 c W95 FAT32(LBA)
Disco /dev/sda: 250.0 GB, 250059350016 bytes

255 cabezas, 63 sectores/pista, 30401 cilindros
Unidades = cilindros de 16065 * 512 = 8225280 bytes
Disposit. Inicio Comienzo Fin Bloques Id Sistema

/dev/sda1 1 9727 78132096 7 HPFS/NTFS
/dev/sda2 9728 19454 78132127+ c W95 FAT32(LBA)
/dev/sda3 * 19455 19488 273105 83 Linux
/dev/sda4 19489 30401 87658672+ 5 Extendida
/dev/sda5 19489 19738 2008093+ 82 Linux swap
/dev/sda6 19739 20237 4008186 83 Linux
/dev/sda7 20238 20362 1004031 83 Linux
/dev/sda8 20363 21981 13004586 83 Linux
/dev/sda9 21982 30401 67633618+83 Linux
debian:/home/nalonzo#
La información que indica es la siguiente:
Nombre del disco.
Capacidad en Gb y en bytes.
Total de cabezas, sectores por pista y cilindros.
Total de unidades.
Descripción de cada una de las particiones indicando:
1. Nombre del dispositivo

2. Bloque de inicio
3. Bloque de fin
4. Total de bloques
5. Tipo de partición
6. Tipo de formato de la unidad
Como puede observarse, en el listado tenemos dos discos duros, uno que se llama hda de 160
Gb, que tiene dos particiones /dev/hda1 con formato del tipo 7 NTFS y /dev/hda2 formateada
con FAT32 modo LBA y otro que se llama sda de 250 Gb y que tiene nueve particiones tres
particiones primarias y seis extendidas. La primera partición tiene formato NTFS y la segunda
FAT32 LBA. La tercera partición corresponde a la partición raíz de linux. La partición extendida
tiene cinco particiones: la partición de swap o intercambio y cuatro de tipo linux. En este caso
formateadas como ext3.
Obviamente si el disco es nuevo solamente aparecerán los datos del disco sin ninguna par-
tición. por lo tanto es necesario ejecutar el comando fdisk /dev/nombredisco en donde nom-
bredisoco podría ser hda o sda en nuestro caso
En el siguiente listado observamos cual es el menú que despliega este comando.
debian:/home/nalonzo# fdisk /dev/hda
El número de cilindros para este disco está establecido

en 19457. No hay nada malo en ello, pero es mayor que
1024, y en algunos casos podría causar problemas con:
1) software que funciona en el inicio (p.ej. versiones
antiguas de LILO)
2) software de arranque o particionamiento de otros
sistemas operativos (p.ej. FDISK de DOS, FDISK de
OS/2)
Orden (m para obtener ayuda): m

Orden Acción
a Conmuta el indicador de iniciable
b Modifica la etiqueta de disco bsd
c Conmuta el indicador de compatibilidad con DOS
d Suprime una partición

l Lista los tipos de particiones conocidos
m Imprime este menú
n Añade una nueva partición
o Crea una nueva tabla de particiones DOS vacía
p Imprime la tabla de particiones
q Sale sin guardar los cambios
s Crea una nueva etiqueta de disco Sun
t Cambia el identificador de sistema de una partición
u Cambia las unidades de visualización/entrada
v Verifica la tabla de particiones
w Escribe la tabla en el disco y sale
x Funciones adicionales (sólo para usuarios avanzados)
Orden (m para obtener ayuda):
en donde tenemos las opciones necesarias para definir nuestras particiones desde borrarlas,
crear nuevas, definir su tipo y guardar los cambios a disco.
Hay que tener en cuenta que si ejecutamos esta operación sobre un disco que contenga
información, al momento de guardar los cambios hechos a las particiones todos los datos se
perderán, por eso debemos estar conscientes de qué es lo que realmente queremos hacer, puesto
que va a ser muy difícil recuperar los datos una vez hecho el reparticionado del disco.
Ya que se ha hecho el particionado adecuado, ahora se procede a formatear cada partición.
Esto se hace con la orden mkfs. En el siguiente listado vemos un fragmento de la ayuda de esta
orden.
DESCRIPTION
mkfs is used to build a Linux file system on a device,
usually a hard disk partition. filesys is either the
device name (e.g. /dev/hda1, /dev/sdb2) or the mount
point (e.g. /, /usr, /home) for the file system.
Blocks is the number of blocks to be used for the
file system.
The exit code returned by mkfs is 0 on success and 1

on failure.
In actuality, mkfs is simply a front-end for the

various file system builders (mkfs.fstype) available
under Linux. The file system-specific builder is

searched for in a number of directories like
perhaps /sbin, /sbin/fs, /sbin/fs.d, /etc/fs, /etc
(the precise list is defined at compile time but at
least contains /sbin and /sbin/fs), and finally in the
directories listed in the PATH enviroment variable.
Please see the file system-specific builder manual
pages for further details.
OPTIONS
-V Produce verbose output, including all file
system-specific commands that are executed.
Specifying this option more than once inhibits
execution of any file system-specific commands.
This is really only useful for testing.
-t fstype
Specifies the type of file system to be built.
If not specified, the default file system type
(currently ext2) is used.
fs-options
File system-specific options to be passed to the
real file system builder. Although not guaranteed,
the following options are supported by most file
system builders.
-c Check the device for bad blocks before building

the file system.
-l filename
Read the bad blocks list from filename
-v Produce verbose output.
BUGS
All generic options must precede and not be combined
with file system-specific options. Some file system-
specific programs do not support the -v (verbose)

option, nor return meaningful exit codes. Also, some
file system-specific programs do not automatically
detect the device size and require the blocks
parameter to be specified.
AUTHORS
David Engel (david@ods.com)
Fred N. van Kempen (waltje@uwalt.nl.mugnet.org)
Ron Sommeling (sommel@sci.kun.nl)
The manual page was shamelessly adapted from Remy
Card’s version for the ext2 file system.
SEE ALSO
fs(5), badblocks(8), fsck(8), mkdosfs(8), mke2fs(8),
mkfs.bfs(8), mkfs.ext2(8), mkfs.ext3(8), mkfs.minix(8),
mkfs.msdos(8), mkfs.vfat(8), mkfs.xfs(8), mkfs.xiafs(8)
Version 1.9
Esta es una orden que permite formatear una partición con el tipo especificado. por ejemplo
mkfs -t ext3 /dev/hda1 formateará hda1 con un sistema de archivos ext3. Después de este paso,
el sistema operativo estará listo para poder guardar información en esa partición.
En un entorno windows, en el ambiente gráfico, aparecerá la unidad después de que ésta
ha sido definida como partición. En el ícono “Mi PC” damos click con el botón derecho para
obtener el menú secundario y se selecciona la opción “Formatear” la unidad. Si se desea hacerlo
desde la línea de comandos se usará la orden format y nombre de la unidad, por ejemplo, for-
mat d:. Despúes de haber formateado la unidad, ahora podemos hacer uso de ella para guardar
archivos.
Algoritmos de planificación de acceso al disco. El tiempo para leer o escribir un bloque de

disco se determina principalmente por tres factores:
1. El tiempo de localización. Este es el tiempo que tarda el brazo del disco en ubicarse en
el cilindro correspondiente.
2. Retardo rotatorio. Es el tiempo en que tarda en girar el disco para ubicarse en el bloque
correspondiente en el cilindro dado.
3. Tiempo de transferencia. Es el tiempo que tarda la circuitería en leer los datos del cabezal
y transmitirlos a la CPU.
Para la mayoría de los discos, la operación que más se lleva tiempo es la del posicionamiento
del brazo junto con el cabezal en el cilindro correspondiente.
En base a lo anterior, se puede mejorar el desempeño del sistema planificando adecuadamen-
te el acceso al disco. Existen las siguientes estrategias que pueden implementarse:
FCFS. First Coming First Served. La primera en llegar, la primera en ser atendida. El brazo
atenderá las solicitudes como van llegando, lo que implica que en ocasiones tendrá que
recorrer el disco de inicio a fin.
SSF. Shortest Served First Atender primero a la solicitud más cercana. Las solicitudes se guar-
dan en una lista y ésta se ordena de acuerdo a la posición actual del brazo de modo que
éste atenderá aquella solicitud que se encuentre más cerca haciendo entonces el movi-
miento más corto posible entre dos peticiones. aunque a primera vista el algoritmo parece
eficiente tiene le problema de que el brazo puede quedarse a mitad de disco generando a
veces largos tiempos de espera, en las siguientes solicitudes.
Algoritmo del elevador Consiste en ir atendiendo todas las solicitudes generadas en una direc-
ción. Cuando termine empezará a servir las solicitudes en la dirección contraria.
4.4.3. Relojes
Los relojes son el medio por el cual funciona la CPU. Básicamente todo sistema de compu-
tadora cuenta con un cristal de cuarzo que vibra a determinada frecuencia. Incluso, cuando se
compra un procesador, lo primero que se hace es saber a qué velocidad de reloj trabajará éste.
Actualmente se cuentan con procesadores capaces de trabajar a velocidades que varían desde
los 800 MegaHertz hasta los 4 GigaHertz o más. Un Hertz está definido como el tiempo que
transcurre durante un ciclo completo, donde un ciclo se define como un pico y un valle. En la
figura 4.6 podemos ver la onda cuadra generada por el reloj, después de haber sido amplificada
por un circuito electrónico para ese fin.
4.4.3.1. Hardware de relojes
En los sistemas de computadora actuales tenemos un reloj. Como dijimos, éste está basado
en ticks de reloj o pulsos de reloj. Un pulso se define como un Hertz y se generan mediante
cristales de cuarzo, el cual al ser cortado y sometido a cierta presión empezará a vibrar a una
Figura 4.6: Onda típica de un ciclo de reloj
frecuencia determinada que es proporcional a la presión a la que es sometido, sin romperlo. En

general un reloj de cuarzo tendrá los siguientes componentes:
1. El oscilador de cristal de cuarzo.
2. Un amplificador de señal.
3. Un Contador.
El oscilador de cristal tiene una amplitud muy pequeña, pero su frecuencia de vibración es
muy exacta, la señal del cristal de cuarzo es enviada a un amplificador, el cual devolverá una
señal ya útil para el sistema de computadora, comúnmente entre cero y cinco voltios. Los con-
tadores permiten disminuir la frecuencia de la señal, de tal forma que pueda ser utilizada para
diversos fines. Uno de ellos, por ejemplo, es llevar la cuenta del tiempo transcurrido Por ejemplo,
si tenemos un contador de decenas, éste generará un pulso cada vez que cuente diez ciclos de re-
loj, por lo tanto, hemos dividido la frecuencia de reloj por un factor de diez, así para contabilizar
los segundos es necesario calcular a cuantos ticks equivale y activar un contador que mida esa
proporción. En la realidad se tienen contadores que proporcionan tiempos de microsegundos y
milisegundos para cumplir con estas tareas.
Para implementar un reloj que lleve la hora del día se puede al usuario que introduzca la hora
actual,entonces el sistema calcula el número de pulsos que han transcurrido a partir de las 12
A.M. del 1 de enero de 1970, como lo hacen actualmente los sistemas basados en UNIX/Linux.
para evitar que la hora se pierda cuando el sistema se desconecta, esta información queda guar-
dada por la BIOS utilizando un registro que se alimenta por una baria interna.
4.4.3.2. Software reloj
Como hemos visto el reloj hardware lo que hace es proporcionar ticks de reloj muy precisos.
Estos ticks pueden usarse para generar interrupciones dirigidas a la CPU, de modo que éste pue-
da llevar a cabo tareas cada cierto tiempo. Estas tareas son llevadas a cabo por el manejador de
reloj. Las tareas que debe de llevar a cabo el manejador de reloj son comúnmente las siguientes:
1. Actualizar la hora del día.
2. Ayudar al planificador de procesos proporcionando una interrupción cada cierto intervalo

de tiempo asignado a un proceso, de modo que el sistema operativo pueda obtener el
control de la CPU.
3. El procesador necesita los ciclos de reloj para poder ejecutar sus instrucciones.
4. Hacen uso de él utilerías tales como cron y crontab para tareas repetitivas del adminis-
trador tales como respaldos y de los usuarios.
5. Obtención de estadísticas a altas horas de la noche cuando el uso del sistema es menor y
obtención de tiempos de ejecución de algunos procesos para ver su eficiencia.
4.4.3.3. Manejador del reloj
La implementación del manejador de reloj puede llevarse a cabo de tal forma que contenga
las siguientes rutinas básicas:
1. TIME orden
2. DATE
3. DATE [MMDDhhmm[[CC]YY][.ss]] la nueva fecha y hora)
4. TIMES
En Linux, se tiene la función time orden. La orden time order ejecuta el programa orden
con los argumentos suministrados. Cuando termina la orden, time escribe un mensaje en la salida
estándar devolviendo las estadísticas temporales sobre la ejecución de este programa.
Estas estadísticas están compuestas por:
1. El tiempo real transcurrido entre la llamada y la finalización de orden.
2. El tiempo de usuario del procesador.
3. El tiempo de sistema del procesador.
Para establecer la nueva fecha y hora Linux hace uso de la función date si no se dan pará-
metros entonces regresa la fecha y hora actual, en otro caso, establecerá la fecha indicada por
los parámetros de acuerdo a un formato preestablecido. La versión función de modo que pueda
ser llamada desde un programa C es times. y permite saber el tiempo de ejecución en ticks de
reloj de algún conjunto de instrucciones o procesos.
Para consultar el reloj linux proporciona otra instrucción denominada hwclock que permite
manipular directamente el reloj de hardware.
4.4.4. Terminales
Todo sistema de computadora cuenta al menos con dos dispositivos de entrada salida: un
teclado y una pantalla o monitor, siendo los medios más comúnmente usados por el usuario
para comunicarse con ésta. Aunque, físicamente, podemos decir que se encuentran separados,
en la mayoría de las ocasiones es necesario que el usuario observe en la pantalla lo que está
escribiendo, (incluso cuando teclea su contraseña, aparecen asteriscos en la pantalla), de modo
que aunque físicamente separados, ambos trabajan en estrecha relación. En las grandes compu-
tadoras, pueden existir decenas o incluso miles de usuarios conectados a la misma, mediante
un teclado y una pantalla a ambos se les ha llamado históricamente terminales, aunque en la
actualidad es también posible que una computadora personal esté siendo usada para conectarse
al servidor universitario, por ejemplo. Existen diferentes tipos de terminales. Las más comunes
son:
1. Terminal autónoma con interfase RS-232 en serie para usarse con mainframes.
2. Computadoras personales con una interfaz gráfica de usuario.
3. Terminales de red, como las usadas por los servidores netra de Sun.
4.4.4.1. Hardware de terminales
La mayoría de las terminales históricamente hablando, caen dentro de la norma RS-232. A

continuación se hace una descripción detallada de éstas.
4.4.4.2. Terminales que se ciñen a la norma RS-232
Las terminales RS-232 son dispositivos que contienen un teclado y un medio de despliegue,
tal como una pantalla y que se comunican mediante el uso de una interfaz en serie, esto significa
que solamente pueden transferir un bit en cada momento. Estas terminales emplean un conec-
tor de 25 pines1 . Obviamente se tienen dos tipos denominados DB25 macho y DB25 hembra,
comúnmente el conector hembra se encuentra en la terminal y el conector macho en el cable,
aunque también pueden existir cables con conectores macho-macho y macho-hembra.
En la figura 4.7, tenemos una imagen de los conectores de este tipo.
Figura 4.7: Vista de los conectores DB25
De estos 25 pines o conexiones, una se usa para transmitir los datos, otra para recibir los
datos y una tercera es tierra común. Las otras 22 conexiones son para funciones de control, y
muchas de ellas no se utilizan. De ahí que exista una versión simplificada de conectores, deno-
minados DB9, incluso, por ser tan pocos las conexiones utilizadas que es posible usar también
para conexiones serie, conectores RJ-45.
En la figura 4.8 tenemos las asignaciones de conexiones para el DB25. Observe que el pin
2 se usa para transmitir datos y que el pin 3 se usa para recibir los datos. El pin 7 es el que se
conecta a tierra o la masa. Los pines de control son el 4, 5, 6, 20 y 22.
En la figura 4.9 las correspondientes para el DB9. Observe que el pin 2 corresponde a datos
recibidos, el 3 a datos enviados el 5 corresponde a la masa o tierra y los restantes corresponden
a las líneas de control.
Una vez que hemos descrito los conectores, pasaremos ahora a describir el hardware que se
utiliza para la transmisión de datos. Como ya sabemos, en nuestro sistema de computadora existe
un puerto denominado com1 hasta com4 este nombre es el se le da en entornos windows. En
entornos basados en UNIX/Linux se les denomina tty1 hasta ttyn, no obstante, a nivel hardware
ambos están basados en un hardware denominado UART descrito al principio de esta sección y
que ahora profundizaremos un poco más. Para que la CPU pueda comunicarse con la terminal,
es necesario que ésta cuente entonces también con su UART. Ya que este requerimiento está
1
Un pin es una pequeña aguja que puede insertarse en otra entrada
Figura 4.8: Asignación de conexiones en el DB25
Figura 4.9: Asignación de pines en el DB9
satisfecho, ambas deben de configurarse bajo los siguientes parámetros de modo que pueda
haber una comunicación fiable. A esto se le conoce como configurar o sincronizar la transmisión.
Las frecuencias de transmisión van desde los 300, 1200, 2400, 4800, 9600 e incluso actualmente
pueden llegar a alcanzar velocidades de 54000 bps (bits por segundo) y más. En la tabla 4.3
podemos encontrar una lista de velocidades en las que se puede configurar la UART.
Esto significa que se pueden transferir bits a esa velocidad. Por ejemplo, si se configura la
UART para transferir a 2400 bps entonces, suponiendo que un caracter se codifique con 8 bits
estaría entonces transmitiendo aproximadamente 300 caracteres por segundo, se dice aproxima-
damente por que se ocupan algunos bits de control como los bits de paro, y el bit de paridad.
Debido a que las computadoras y las terminales trabajan con caracteres completos, es nece-
sario que la UART traduzca la secuencia de bits en caracteres para que éstos puedan ser usados.
Es común que las computadoras, tengan ya integrados los puertos correspondientes para el
manejo de terminales. Además, actualmente, es un poco complicado encontrar terminales tal
y como se describen aquí. Lo más normal es que encontremos computadoras de baja potencia
Tasa de Baudios MCR Bit 7=1 Tasa de Baudios MCR Bit 7=0
600 2400
1200 4800
2400 9600
4800 19.2k
9600 38.4k
19.2k 76.8k
38.4k 153.6k
57.6k 230.4k
115.2k 460.8k
Tabla 4.3: Velocidades de transmisión de una UART actual
haciendo la función de terminales.

En general, se puede decir que una terminal consta solamente de un teclado, un monitor y
una tarjeta de puertos serie que cuente con el estándar RS-232.
Figura 4.10: Una configuración típica de terminales
En la figura 4.10 podemos ver los elementos básicos de un sistema orientado a terminales.
Observe que incluso, en hardware avanzado puede contarse con un dispositivo apuntador, como
por ejemplo, el ratón.
Las terminales ofrecen una manera adecuada y de bajo costo para acceder a un sistema de
computadora.
Uniendo todos los elementos, podemos decir entonces, que la CPU, envía uno o más caracte-
res al manejador de terminal. Este separa los bits del caracter y los envía por la línea serie. En el
otro lado, la terminal, recibe los bits, los vuelve a empaquetar en los caracteres correspondientes
y se encarga de visualizarlos en pantalla o en la impresora de papel. Cuando un usuario hace uso
del teclado, el manejador de la terminal, toma los caracteres, los divide en los bits correspon-
dientes y los envía a la CPU a través de la línea serie. De esta forma , el usuario puede enviar
instrucciones a la CPU, para que ésta ejecute ciertos programas o tareas.
Tipos de terminales Los primeros sistemas UNIX R no tenían consolas. En su lugar la gente
se conectaba y ejecutaba sus aplicaciones a través de terminales conectadas a los puertos serie
de la computadora. Es muy parecido a la manera en la que actualmente se usa un modem y un
programa de terminal para marcar hacia un sistema remoto para hacer trabajo en modo texto.
Las PC’s actuales tienen consolas con gráficos de alta calidad, pero la habilidad para esta-
blecer una sesión en un puerto serie todavía existe en casi cualquier sistema operativo UNIX al
día de hoy. Utilizando una terminal conectada a un puerto serie libre, se puede acceder y co-
rrer cualquier aplicación en modo texto que podría correr normalmente en la consola o en una
ventana xterm en el sistema X Window.
Para el usuario empresarial, se pueden conectar muchas terminales a un sistema y ponerlas
en los escritorios de sus trabajadores. De esta forma se puede convertir una computadora de un
solo usuario, en un poderoso sistema de usuarios múltiples.
En general, existen tres categorías de terminales:
1. Terminales tontas.
2. PCs como terminales.
3. Terminales X
Terminales tontas. Son piezas de hardware especializadas que se pueden conectar a compu-
tadoras a través de puertos serie. Se llaman “tontas” porque sólo tienen poder computacional
suficiente para desplegar, enviar y recibir texto. No puede ejecutar ningún programa en ellas. Es
la computadora a la cual se conectan la que tiene todo el poder para correr editores de texto,
compiladores, correo electrónico, juegos, y demás.
Existen cientos de tipos de terminales tontas hechas por muchos fabricantes, incluyendo VT-
100 de Digital Equipment Corporation y WY-75 de Wyse. Algunas terminales mejoradas pueden
incluso desplegar gráficos, pero solo algunas aplicaciones de software pueden tomar ventaja de
estas funciones avanzadas.
Las terminales tontas son populares en ambientes de trabajo donde los trabajadores no nece-
sitan acceso a aplicaciones gráficas como las que provee el sistema X Window.
PC’s como terminales. Si una terminal tonta sólo tiene la habilidad para desplegar, enviar
y recibir texto, entonces ciertamente cualquier computadora personal puede actuar como una
terminal tonta. Todo lo que necesita es un cable que DB25 o DB9 como se describió en la
sección 4.4.4.1 y software de emulación de terminal para correr en la computadora.
Terminales X. Las terminales X son el tipo más sofisticado de terminal disponible. En lugar
de conectar a un puerto serie, usualmente se conectan a una red como Ethernet. En lugar de
ser relegadas a aplicaciones de modo texto pueden desplegar aplicaciones, de modo que pueden
hacer uso de otros dispositivos tal como el ratón o una pantalla táctil para lograr una mayor
interacción con el usuario.
Existen diferentes formas de conectar este tipo de terminales al servidor, una de las más
comunes es usar una computadora de bajo costo a un servidor de altas prestaciones o en su
defecto, utilizar estaciones de trabajo con el mismo fin.
Terminales en memoria Las terminales en memoria no se conectan vía los puertos serie, si
no que forman parte integral del sistema. Es común encontrar esta configuración en las compu-
tadoras personales, puesto que no es necesario que se conecte más de un usuario al sistema al
mismo tiempo. Aunque en la actualidad, la tendencia está cambiando muy rápidamente hacia
los sistemas multiusuario caseros. También estas terminales están más asociadas directamente
con las tarjetas de vídeo las cuales pueden tener su propia memoria RAM o pueden estar com-
partiendo la memoria principal con el sistema. La CPU, puede entonces escribir directamente
en la memoria RAM asociada a la tarjeta de vídeo de modo que el controlador de vídeo pueda
entonces extraer estos bytes de esa parte de la memoria y realizar su tarea de despliegue en el
monitor. Esto lo hace en un tiempo cercano a 16 centésimos de segundo.
La tarjeta de vídeo, es un componente electrónico para generar una señal de vídeo que se
manda a una pantalla de vídeo por medio de un cable. La tarjeta de vídeo se encuentra normal-
mente en la placa de sistema de la computadora o en un bus de expansión. La tarjeta de vídeo
reúne toda la información que debe visualizarse en pantalla y actúa como interfaz entre el pro-
cesador y el monitor; la información es enviada a éste por la placa luego de haberla recibido
a través del sistema de buses. Una tarjeta gráfica se compone, básicamente, de un controlador
de vídeo, de la memoria de pantalla o RAM vídeo, y el generador de caracteres. Actualmente
también poseen un acelerador de gráficos. El controlador de vídeo va leyendo cada cierto tiem-
po la información almacenada en la RAM vídeo y la transfiere al monitor en forma de señal de
vídeo; el número de veces por segundo que el contenido de la RAM vídeo es leído y transmitido
al monitor en forma de señal de vídeo se conoce como frecuencia de refresco de la pantalla.
Entonces, la frecuencia depende en gran medida de la calidad de la placa de vídeo.
Existen diferentes tipos de tarjetas de vídeo:
Adaptador de Pantalla Monocromo (APM). Las primeras computadoras personales sólo vi-
sualizaban textos. El APM contaba con 4KB de memoria de vídeo RAM que le permitía
mostrar 25 líneas de 80 caracteres cada una con una resolución de 14x9 puntos por carác-
ter.
Tarjeta gráfica Hércules. Con ésta tarjeta se podía visualizar gráficos y textos simultáneamen-
te. En modo texto, soportaba una resolución de 80x25 puntos. En tanto que en los gráficos
lo hacía con 720x350 puntos, dicha tarjeta servía sólo para gráficos de un solo color. La
tarjeta Hércules tenía una capacidad total de 64k de memoria vídeo RAM. Poseía una
frecuencia de refresco de la pantalla de 50HZ.
Color Graphics Adapter (CGA). La tarjeta CGA utiliza el mismo chip que la Hércules y apor-
ta resoluciones y colores distintos. Los tres colores primarios se combinan digitalmente
formando un máximo de ocho colores distintos. La resolución varía considerablemente
según el modo de gráficos que se esté utilizando:
160 X 100 pixeles con 16 colores.

Tarjeta EGA. Enchanced Graphics Adapter (EGA). Se trata de una tarjeta gráfica superior a
la CGA. En el modo texto ofrece una resolución de 14x18 puntos y en el modo gráfico
dos resoluciones diferentes de 640x200 y 640x350 a 4 bits, lo que da como resultado una
paleta de 16 colores, siempre y cuando la tarjeta esté equipada con 256KB de memoria de
vídeo RAM.
Tarjeta VGA. Esta tarjeta ofrece una paleta de 256 colores, dando como resultado imágenes
de colores mucho más vivos. Las primeras VGA contaban con 256KB de memoria y solo
podían alcanzar una resolución de 320x200 puntos con la cantidad de colores menciona-
dos anteriormente. Primero la cantidad de memoria vídeo RAM se amplió a 512KB, y
más tarde a 1024KB, gracias a esta mejora es posible conseguir una resolución de, por
ejemplo, 1024x768 pixeles con 8 bits de color. En el modo texto la VGA tiene una resolu-
ción de 720x400 pixeles, además posee un refresco de pantalla de 60HZ, y con 16 colores
soporta hasta 640X480 puntos.
Tarjeta SVGA. La tarjeta SVGA (Super Vídeo Graphics Adapter) contiene conjuntos de chips
de uso especial, y más memoria, lo que incrementa la cantidad de colores y la resolución.
Acelerador gráfico. La primera solución que se encontró para aumentar la velocidad de pro-
ceso de los gráficos consistió en proveer a la tarjeta gráfica de un dispositivo electrónico
especial llamado acelerador gráfico. El acelerador gráfico se encarga de realizar un con-
junto de funciones relacionadas con la presentación de gráficos en la pantalla, que de otro
modo, tendría que realizar el procesador. De esta manera, le quita tareas a éste, y así se
puede dedicar casi exclusivamente al proceso de datos. La velocidad con que se ejecutan
las aplicaciones basadas en Windows para el manejo de gráficos se incrementa muy no-
tablemente, llegando al punto (con algunas placas) de no necesitar optimizar la CPU. El
estándar hoy día está dado por los aceleradores gráficos de 64 bits. También, aunque no
tan comunes, hay aceleradores gráficos de 128 bits.
Coprocesador gráfico. Para obtener una mayor velocidad se instalaron en las tarjetas de vídeo
otros circuitos especializados en el proceso de órdenes gráficas, llamados coprocesadores
gráficos. Se especializan en la ejecución de una serie de instrucciones de generación de
gráficos. En muchas ocasiones el coprocesador se encarga de la gestión del ratón (mouse)
y de las operaciones tales como las ampliaciones de pantalla.
Aceleradores gráficos 3D. Los gráficos en tres dimensiones son una representación gráfica de
un objeto o escena usando tres ejes de referencia, X, Y, Z, que indican el ancho, el alto
y la profundidad de ese gráfico. Para manejar un gráfico tridimensional, éste se divide en
una serie de puntos o vértices, en forma de coordenadas, que se almacenan en la memoria
RAM. Para que ese objeto pueda ser dibujado en un monitor de tan sólo dos dimensiones
(ancho y alto), debe pasar por un proceso denominado renderización.
La renderización se encarga de modelar los pixeles (puntos). Para llevar a cabo esta tarea,
se agrupan los vértices de tres en tres, hasta transformar el objeto en un conjunto de trián-
gulos. Estos procesos son llevados a cabo entre el microprocesador y el acelerador gráfico.
Normalmente, el microprocesador se encarga del procesamiento geométrico, mientras que
el acelerador gráfico del renderizado.
En pocas palabras, el microprocesador genera el objeto, y el acelerador gráfico lo “dibuja”.

El gran problema que enfrenta el microprocesador es que al construir los objetos 3D a base
de polígonos, cuanto más curvados e irregulares se tornan los bordes del objeto, mayor es
la cantidad de polígonos que se necesitan para aproximarse a su contorno. El problema
es aún más complejo si además el objeto necesita moverse, con lo cual hay que generarlo
muchas veces en un lapso de pocos segundos.
El teclado El teclado es uno de los elementos más usados en la interacción con la compu-
tadora. Mientras e ha habido mucho avances en los dispositivos de interfaz humana, hasta el
momento sigue ejerciendo su hegemonía en la mayoría de los sistemas de computadora.
Un teclado típico consta de una matriz de contactos, hechos de una capa delgada de carbono
conductor y que cuando se presiona una tecla, cierra un circuito dado dentro de la matriz. El
microcontrolador del teclado detecta la tecla que fue presionada y genera el código correspon-
diente de acuerdo a ala posición en la matriz. Al liberarse la tecla se genera otro código. Así el
controlador del teclado puede saber cuando fue presionada y liberada la tecla correspondiente.
Los códigos generados, se denominan códigos de barrido o “scan code”.
Existen diferentes tipos de teclado. Los más comunes son los siguientes:
1. Tipo XT de 83 teclas. Ya no se usan.
2. Tipo AT de 101/102 teclas
3. Tipo AT de 104 teclas “diseñado para Windows”
4. Tipo ergonómico. Un teclado abierto que proporciona mayor comodidad a las muñecas
los teclados tienen diversas maneras de conectarse con la tarjeta madre las más comunes son:
Conector DIN. (Deutsches Institut für Normung) Conector “grande” de cinco pines
Conector mini DIN. Se conoce también como conector PS/2, debido a que las computadoras
de IBM modelo PS/2 fueron las primeras en introducir este conector.
Conector USB. Existen teclados que usan el Bus Serial Universal para conectarse a la tarjeta
madre.
Los primeros teclados, XT de 83 teclas; AT de 84, y algunos extendidos de 101/102 teclas,

utilizan un conector DIN de 5 pines con el macho del lado del teclado y la hembra del lado de
la tarjeta madre. Salvo en algunos modelos de IBM el cable está sólidamente unido al teclado.
Nota: El conector en la tarjeta madre es extremadamente delicado, por lo que hay que tener
cuidado al conectar el cable del teclado a la computadora, ya que un exceso de presión puede
expulsar de la tarjeta madre el conector hembra, a la que está unida por unos pines soldados de
poca resistencia mecánica.
La introducción del PS/2 de IBM inauguró la moda de utilizar conectores mini DIN para
teclados y ratones. La tendencia actual es utilizar conectores USB para ambos dispositivos de
entrada. Más recientemente se está extendiendo la moda de dispositivos inalámbricos (“Wire-
less”). Esto no significa que tales modelos no utilicen el conector de teclado; lo que en realidad
desaparece es el cable entre el dispositivo que se conecta al conector del PC y el propio te-
clado. La tendencia comenzó con los de enlace infrarrojo, pero actualmente casi todos son de
radio-frecuencia.
En caso de que los conectores con que cuenta la tarjeta base no coincida con el del teclado,
es posible conseguir adaptadores entre los diferentes tipos para hacer posible la conversión.
Una vez que ha sido detectada la pulsación de la tecla,se generan los códigos de barrido
correspondientes y se envían mediante una línea serie hacia la placa base de la computadora.
Aquí la BIOS del teclado interpreta los códigos de barrido y los compara con la tabla para asociar
el código ASCII correspondiente. Después de esto genera una interrupción por hardware para
darle a conocer al procesador la existencia de la tecla presionada. A continuación se describe en
un detalle mayor estos sucesos.
Cuando se pulsa una tecla, el chip del teclado genera un código de exploración de un byte,
que en este caso se llama código de acción (“Make code”). Cuando posteriormente la tecla es
liberada, se genera un nuevo código (“Break code”), cuyo valor es el de pulsación incrementado
en 128. Por ejemplo, cuando se pulsa la letra “A” se genera un código de exploración 30 (1Eh),
y de 30 + 128 = 158 (9Eh) cuando se libera
Cuando el código de exploración es depositado en el puerto A (060h) del controlador de
dispositivos, cada pulsación/retroceso registra dos códigos, enseguida este controlador devuelve
rápidamente una señal de reconocimiento ACK al chip del teclado, por el puerto B (061h), para
indicarle que el caracter ha sido guardado.
Además de lo anterior, cuando el PIO recibe un código de exploración, genera una petición
de interrupción poniendo en tensión baja la línea IRQ1 del bus de datos (que está reservada al
teclado). Cuando la interrupción es atendida y el procesador está listo para recibir el caracter, el
controlador de interrupciones contesta con la interrupción número 9 (de teclado) y enmascara
las siguientes peticiones de interrupción que pudieran producirse en la línea IRQ1 hasta que la
actual haya sido atendida.
El valor 9 es la posición de la rutina que atiende el servicio del teclado en el vector de
interrupciones. Esta rutina sabe que tiene que leer el puerto de teclado (60h) para ver qué código
de exploración hay en el búfer de la interfaz de teclado. A continuación transforma este número
en un código de 2 bytes, conocidos como keycodes o bytecodes, que son pasados al búfer del
teclado hasta que los lea algún programa que los necesite.
Las reglas de formación de estos dos keycodes se establecen como sigue:
1. Si se presiona una tecla del teclado estándar, el byte auxiliar (de la izquierda, de mayor
peso) contiene el propio código de exploración, mientras que el byte principal (de menor
peso) contiene el código ASCII del carácter de la tecla (1 a 255). Para la determinación se
tienen en cuenta los “Bytes de estado”.
2. Cuando se pulsa una tecla especial, como es el caso de las teclas de función (F1/F12) o
Shift; las teclas de movimiento de cursor, como Home o End, y las del teclado numéri-
co independiente, el byte principal contiene un cero y el auxiliar contiene el código de
exploración.
Los “Break code” se descartan, a excepción de los que corresponden a teclas de conmutación
permanentes y no permanentes, que tiene influencia en los bytes de estado.
El búfer del teclado es un área de 32 bytes de RAM en las direcciones 41Eh-43Dh (memoria
de datos de la ROM BIOS). Puesto que se generan 2 byte-codes por cada código de exploración,
es posible almacenar un máximo de 16 teclas, aunque sólo se aprovechan 15. La posición 16
contiene información especial que, como veremos enseguida, es necesaria para el esquema de
funcionamiento.
El búfer es una cola circular (FIFO) y es maneja de acuerdo a los valores de dos apuntado-
res; el de inicio, almacenado en las direcciones 41Ah-41Bh, señala la dirección de inicio, y el
apuntador de cola, almacenado en las direcciones 41Ch-41Dh, señala la dirección del final. El
apuntador de inicio señala siempre la posición del primer caracter del búfer (en cualquiera de
las 15 posiciones posibles). En el momento inicial, cuando el búfer está vacío, el apuntador de
cola apunta al mismo sitio que el de inicio. Cuando se van añadiendo códigos, el apuntador de la
cola va señalando posiciones sucesivas (de dirección creciente), hasta que se alcanza la posición
superior, comenzado entonces por la dirección inferior del búfer. Cuando se alcanza la posición
de inicio, el búfer está lleno y se rechazan los caracteres siguientes (algunos sistemas señalan
esta situación mediante un pitido en el altavoz del equipo).
4.4.4.3. Manejadores
De acuerdo a lo visto anteriormente tendremos básicamente dos manejadores de dispositivos:

1. Los manejadores de teclado
2. Los manejadores de vídeo.
Manejadores de teclado. La primera tarea que debe de realizar el manejador de teclado con-
siste básicamente en recibir los caracteres que envía el teclado. Como es de suponerse, el sistema
operativo implementa las rutinas necesarias del manejo de caracteres haciendo uso del vector de
interrupciones, puesto que como vimos, cada vez que se presiona y libera una tecla se produce
una interrupción hardware. La otra tarea que debe de realizar es la de pasar los caracteres a la
aplicación que los necesite.
Existen básicamente dos maneras de leer caracteres por un programa, la primera es la lectura
caracter por caracter y la segunda es la de leer una línea completa de caracteres. Cuando se
hacen lecturas caracter por caracter, la aplicación tiene la oportunidad de interpretar incluso los
caracteres de control como el retroceso o nueva línea, pero depende de ésta darle la oportunidad
al usuario de corregir una entrada. Se hace la lectura por línea completa, se dice que el usuario
ha terminado de editar la línea en el momento en que presiona la tecla entrar. Antes de que esto
suceda, tiene la oportunidad de usar las teclas de retroceso, borrar un caracter hacia atrás o borrar
el caracter actual (tecla Del). Cuando la línea está lista puede entonces presionar la tecla entrar.
Cuando se usa el método de caracter por caracter, se hace uso de un búfer pequeño que puede
ir desde los diez hasta los veinte caracteres. Algunos sistemas permiten añadir nuevos búferes
a medida que aumenta la cantidad de caracteres introducidos por el usuario pero que no son
todavía usados por la aplicación. Otros, no obstante restringen la entrada a una cierta cantidad.
Cuando ésta se excede, entonces cada vez que se envía un nuevo caracter el sistema envía al
altavoz un pitido para indicarle al usuario que el búfer ya no acepta más caracteres y a partir de
ese momento éstos serán ignorados.
Con el método basado en líneas, es importante saber el tamaño máximo permitido de la línea
y que por lo común va de los ochenta hasta los 255 caracteres. obviamente, esto no quiere decir
que el usuario deba forzosamente llenar todo este espacio, como se dijo, se indica el final de una
línea cuando el usuario presiona entrar.
Para manejar las entradas de caracteres, existen dos métodos:
1. Reserva de búferes.
2. Búferes por terminal.
En el primer método, cada terminal está asociada con una estructura de datos que contiene
comúnmente un apuntador a la cadena de búferes, correspondiente a las entradas recibidas de
esa terminal. A medida que se teclean más caracteres, se obtiene más búferes y se ligan a la
cadena. Cuando los caracteres se pasan a un programa de aplicación, los búferes se desocupan
y vuelven a la reserva central.
El otro método consiste en manejar los búferes dentro de la estructura de datos asociada
directamente con la terminal, sin usar una reserva central. Este método hace más sencillo el
controlador y se ocupa mucho en las computadoras personales que manejan un solo teclado.
Aunque el teclado y la pantalla son dispositivos independientes, es normal que el usuario ob-
serve inmediatamente en la pantalla lo que ha escrito. Esto limita severamente las capacidades
de la mayoría de los editores de texto. Algunas terminales muestran automáticamente vía hard-
ware lo que acaba de escribirse. En la mayoría de las terminales actuales, en general el mostrar
el caracter escrito depende completamente del software, permitiendo de esta manera mayor fle-
xibilidad al programa de aplicación, con la desventaja de que si estamos hablando de terminales
remotas, el mostrar los caracteres escritos sea una tarea lenta, pudiendo llegar a molestar a los
usuarios. Ese efecto es más pronunciado en redes de bajo ancho de banda como cuando se usa
un módem, por ejemplo.
Existen diversas conbinaciones de caracteres que se usan para control. por ejemplo, en la
tabla de Códigos ASCII las primeras representaciones de caracteres indican al terminal las ac-
ciones que deben de llevarse a cabo en la pantalla. El caracter de control más usado, puede ser,
por ejemplo, el retorno de carro (10h) o trece en decimal, que le indica a la pantalla que coloque
el cursor al principio de la línea. También en algunos sistemas se usa en combinación con el
caracter de nueva línea o salto de línea cuya función es bajar el cursos a la siguiente línea. En
los sistemas basados en Unix, solamente se utiliza el salto de línea, llevando implícito el retorno
de carro. En los sistemas basados en windows deben de usarse los dos (el retorno de carro y la
nueva línea).
Manejadores de vídeo
Terminales basadas en caracteres. En general las computadoras envían caracteres a la termi-

nal donde ésta los muestra. Por lo general, en la terminal se escribe un bloque de caracteres, por
ejemplo una o más líneas, con una sola llamada de sistema. El método se usa en las terminales
basadas en RS-232 es asociar búferes de salida a cada terminal. Estos pueden tomarse de la mis-
ma reserva de búferes de los que son usados también en los búferes de entrada o también pueden
ser de uso exclusivo para cada terminal. Cuando un programa escribe en la terminal, las salidas
se copian primero en el búfer. Las salidas de eco también se copian allí. Después de copiar todas
las salidas al búfer, se envía a la salida el primer caracter y el controlador pasa al estado dormido.
Cuando llega la interrupción desde la terminal que indica que el caracter ya ha sido escrito, se
envía el siguiente y así sucesivamente hasta que todas las salidas han sido mostradas.
Muchos programas, principalmente los editores de texto necesitan mayor flexibilidad para
insertar y eliminar texto en cualquier parte de la pantalla. Para ello existen diferentes órdenes que
permiten mover el cursor en diferentes posiciones, marcar texto o desmarcarlo, insertar o borrar
caracteres o bloques de caracteres. Comúnmente estas órdenes están representadas también por
caracteres normales, pero esta precedidas por el caracter ESC (código ASCII 27 decimal). A
estas combinaciones se les conoce como secuencias de escape. Esta también es una técnica muy
utilizada para órdenes de impresión complejas, como remarcado, tipos de letra y otros.
Cuando el uso de terminales era muy extendido había nula estandarización y cada una de
ellas tenía sus propias secuencias de escape. Esto hacía casi imposible que el software escrito
para cierto tipo de terminal se usara en otra. Una solución que introdujo la Universidad de
Berkeley en su sistema operativo Berkeley UNIX, fue introducir una base de datos de terminales
denominada termcap. Este paquete de software definía un conjunto de acciones básicas, como
colocar el cursor en una posición determinada, el programa de aplicación se encargaba de usar
estas secuencias de escape y el sistema operativo se encargaba de hacer la traducción de la base
de datos de termcap a las propias secuencias de escape de la terminal, de modo que aquella
terminal que tuviera registradas sus secuencias de escape en la base de datos termcap podía ser
fácilmente usada o en su defecto emulada, facilitando así la migración de muchos programas a
diferentes tipos de terminales.
Figura 4.11: Una sesión típica de terminal
Fue entonces una necesidad urgente estandarizar las secuencias de escape, de esta forma se
desarrolló el estándar ANSI. En la figura 4.11 vemos una sesión de terminal típica.
Interfaces gráficas de usuario. El método de terminales orientadas a caracteres dominó du-

rante mucho tiempo, no obstante en la actualidad, la mayoría de computadoras tanto personales
como empresariales usan una interfaz gráfica de usuario o GUI Graphical User Interface
Para simplificar el uso de las computadoras a cualquier tipo de usuarios y no sólo para
los expertos, es una práctica habitual utilizar íconos visuales por medio de la llamada interfaz
gráfica de usuario de modo que el usuario pueda interactuar de manera más fácil e intuitiva con
la computadora. Neal Stephenson afirmaba: “en el principio fue la línea de comandos...” La línea
de comandos siempre ha permitido un mayor control sobre la computadora, incluyendo a veces

la manipulación de gráficos. En la actualidad es la cultura de la interfaz “amigable” y vistosa que
permite que un simple click de ratón sobre algún ícono que aparece en la pantalla, sustituya a la
tediosa tarea de escribir tal vez una instrucción muy grande para que la computadora interprete
que debe realizar alguna orden.
En 1981 aparecieron las primeros computadoras personales, las llamadas Pc’s, pero hasta
1993 no se generalizaron las interfaces gráficas de usuario. El escritorio del sistema operativo
Windows de Microsoft y su sistema de ventanas sobre la pantalla se ha estandarizado y uni-
versalizado, pero fueron las computadoras Macintosh de la compañía Apple los primeros que
introdujeron las interfaces gráficas, ideadas básicamente por Douglas Engelbart y su grupo de in-
vestigación en el Stanford Research Institute. De ahí la copiaron investigadores de Xerox PARC
y de éstos Steve Jobs quien sacó a la venta una computadora llamada Apple Lisa que no tuvo
mucho éxito, de ahí vino la Macintosh que tuvo un sonado éxito. La Macintosh fue la inspira-
ción para microsoft Windows y otros sistemas basados en GUI como KDE, Gnome y CDE de
Solaris de SUN, por citar algunos.
Toda GUI tiene los siguientes elementos básicos:
Ventanas. Son la parte principal de un entorno gráfico y son bloques donde puede ejecutarse
una aplicación y proporcionan espacio donde se acomodan los demás elementos.
Íconos. Son pequeños dibujos que intentan dar una descripción gráfica de la función que reali-
zan.
Menús. Son conjuntos de órdenes organizadas por jerarquías de funciones relacionadas y que
pueden accederse mediante el apuntador o ratón.
Apuntadores. Son dispositivos que permiten seleccionar un elemento. El más común es el ra-
tón, pero también se puede hacer uso de una pantalla táctil o como en las computadoras
portátiles, un área sensible al tacto y al calor del dedo para poder mover el apuntador de
la pantalla.
La manera de implementar la GUI depende del enfoque del diseñador del sistema operativo.
por ejemplo, Windows de Microsoft prefiere integrarlo al kernel mismo, para darle una mayor
velocidad de respuesta al usuario. Los sistemas basados en UNIX/Linux, por el contrario, dele-
gan la tarea a aplicaciones a nivel de usuario, dejándolo por tanto, fuera del kernel del sistema
operativo, pero subordinado a éste. El enfoque más común en este tipo de sistemas es el de
cliente servidor.
En la sección 4.4.4.2 hicimos una descripción detallada sobre el funcionamiento de los
monitores. En esta sección profundizaremos un poco más en cómo es que se implementa el
sistema gráfico. Especificamente hablaremos acerca del sistema que es usado en los sistemas
UNIX/Linux el sistema X, que es la base de las GUI’s en estos sistemas.
El manejo de ventanas. Enseguida haremos una descripción general de cómo se manejan las
ventanas en cualquier ambiente gráfico.
El principal elemento de la pantalla es un área rectangular que define una ventana. El tamaño
y la posición de la ventana están definidos de manera única por sus coordenadas (en píxeles) de
sus dos esquinas diagonalmente opuestas, empezando por la esquina superior izquierda. Una
ventana puede contener diferentes widgets los cuales pueden ser:
Un menú. Que proporciona diferentes opciones al usuario, junto con teclas de acceso rápido o
abreviaciones de teclas.
Una barra de título. Indica el nombre de la ventana. Si es la principal, entonces será el nombre
de la aplicación.
Barras de desplazamiento. Pueden ser de dos tipos: barras de desplazamiento horizontal y

barras de desplazamiento vertical, que permiten mostrar otros elementos que podrían no
caber en el espacio limitado de la pantalla.
Barras de herramientas. Son íconos que representan gráficamente las funciones que puede
realizar un usuario al hacer click en ellos.
Otros elementos internos. Como íconos, entradas de texto, botones de selección, editores de
texto y otros.
La programación de aplicaciones en entornos gráficos cambia radicalmente de aquellas

orientadas a caracter. Como el usuario puede mover, redimensionar, o cerrar las ventanas, és-
tas deben de tener la capacidad de volverse a dibujar, tan pronto como se reciba una orden.
a esta nueva de programar se le conoce como programación orientada a eventos, que es una
extensión de la programación orientada a objetos.
Un evento es una acción generada por el teclado, el ratón a algún otro dispositivo de interfaz
humana. El sistema operativo sabe cuales son las ventanas que se encuentran visibles en ese
momento y debe de decidir entonces a cual de ellas tendrá que enviarle el evento que acaba de
suceder. Lo más común es que el evento sea despachado a aquella ventana que tiene el foco2
activado. Cuando el usuario selecciona otra ventana, entonces ahora el foco estará en la ventana
seleccionada. todas las aplicaciones deben de estar pendientes y lo más común es que entren
2
Es la ventana que está activa o donde se ha hecho un click con el ratón
en un ciclo infinito esperando que el sistema operativo les envíe los eventos generados por el
ratón o el teclado para que puedan realizar sus funciones. Dentro de cada función la primera
estructura de control que se maneja es una de opción múltiple. en C se le llama switch, de modo
que puedan distinguirse todas aquellas acciones que es capaz de reconocer la aplicación.
Los eventos, como se puede ver, son la manera mediante la cual se comunican los elementos
de las aplicaciones y también es posible mediante éstos la comunicación inter aplicaciones de
modo que puedan pasarse datos de una aplicación a otra.
El sistema X. A mediados de los ochenta, ya era común encontrar computadoras en muchas

partes, incluyendo los usos domésticos. Era común también conectarse desde terminales o desde
éstas a centros de cómputo de mayor capacidad vía módem usando intérpretes de comandos, los
problemas con los que se enfrentaban era que no podía soportar gráficos.
En esta situación el MIT decidió crear un sistema gráfico que actualmente es el más usado
en los sistemas UNIX/Linux llamado el X Window system.
El objetivo era crear un sistema capaz de usar imágenes en la pantalla y debía de interactuar
con el usuario con un apuntador como el ratón, el teclado además de ser útil y fácil de usar para
aquellos usuarios que desearan proporcionar soporte gráfico a sus aplicaciones.
Bob Scheifler y Jim Gettys empezaron por sentar las bases sobre las que comenzaron el
desarrollo del sistema. Acertadamente, decidieron seguir un esquema modelo cliente-servidor.
El esquema cliente-servidor permite que el cliente o el programa de aplicación genere el
gráfico y que el servidor sea el que realmente lo presenta al usuario. Esto permite que puedan
ejecutarse, de forma totalmente transparente, otros programas en alguna computadora de la red.
Esta idea es al principio rara y confusa. Al empezar a trabajar con X se piensa que el servidor
es quien da los gráficos, no quien los visualiza. Es gracias a esta separación entre programa y
sistema gráfico que podemos ejecutar programas muy complejos en grandes máquinas, como las
de los centros de cálculo, sin tener que cargarlas también con la representación de las imágenes.
El servidor X es entonces una capa por encima del teclado, ratón y pantalla que puede usar
el programador. Este no tiene por qué preocuparse por el tipo de tarjeta gráfica de un cliente, si
la resolución es la adecuada u otros detalles. Además no se pierde el control sobre su aplicación
gracias a las funciones para control de eventos. En su diseño mínimo, X no contiene funcio-
nes para hacer botones, ventanas, menús o interfaz alguna; su única función es proporcionar
la capa ya mencionada. Los manejadores de ventana, como KDE o GNOME, o los escritorios
son los procesos de usuario que se encargan de estas funciones. Muchas empresas, como SUN
Microsystems y Apple, usan X o una variante similar por debajo de su sistema gráfico.
X oculta además, la red, haciéndola invisible. Así se puede programar fácilmente un cliente
para X sin tener la más mínima noción de programar para redes o ser, acaso, consciente de que el
programa puede no estar ejecutándose en la misma máquina que el servidor. El mecanismo para
conseguir esto es la variable de entorno DISPLAY. Es común, aún hoy en día, tener que decirle a
una máquina que el terminal gráfico está en otra computadora mediante “set DISPLAY=IP:0.0”.
Este es el mecanismo que manejan actualmente la mayoría de los servidores de terminales que
usan computadoras relativamente antiguas, pero que son capaces de correr solamente el Sistema
X Window, con su teclado, ratón y monitor, permitiendo de esta forma ejecutar aplicaciones que
fácilmente rebasarían la capacidad de estas computadoras, siendo entonces imposible ejecutarlas
localmente.
Windows. Como se comentó, Windows implementa el entorno gráfico casi completamente en

el kernel lo que le permite dar una respuesta mucho más rápida al usuario. El corazón del sistema
gráfico de windows es su API Win32 que es reconocida por todas las versiones de Windows de
32 bits. El software de salida para otras GUI’s es comparable de forma general, pero cambian
en los detalles.
Para dibujar la pantalla se maneja un paquete que consiste en cientos de procedimientos
agrupados para formar la interfaz gráfica de dispositivo o GDI Graphics Device Interface, la
cual puede manejar texto y todo tipo de gráficos. Está diseñada de manera tal que es indepen-
diente de la plataforma y el dispositivo. Para que un programa pueda dibujar en una ventana,
primero tiene que obtener un contexto de dispositivo, que es básicamente una estructura de
datos que mantiene las propiedades de la ventana o del widget, esta información incluye, el tipo
de letra, el color del texto, el color del fondo, entre otros. La mayoría de las llamadas a la GDI
utilizan el contacto del dispositivo, ya sea para dibujar, consultar o modificar las propiedades.
Los procedimientos utilizados en la GDI, son comúnmente gráficos vectoriales. Se utilizan
para colocar figuras geométricas y texto en la pantalla. Es fácil ajustar su escala a pantallas que
sean más grandes o más pequeñas y también son relativamente independientes del dispositivo.
Es posible colocar en un archivo un conjunto de llamadas a procedimientos de GDI que describa
la manera de dibujar un objeto completo. A este tipo de archivo se le conoce como metaarchivos
de Windows y se utilizan en forma amplia para transferir dibujos de un programa windows a
otro. Estos archivos tienen la extensión .wmf o Windows Meta File.
Para el manejo de gráficos que no es posible manejar vectorialmente se utilizan técnicas de
escaneo que permiten pasar una imagen a computadora. Esta técnica comúnmente coloca una
rejilla de n X m cuadros, luego de cada uno se obtiene el valor promedio para el color, rojo,
verde y azul. Este es el valor de ese píxel. A medida que los cuadros de la rejilla sean más
pequeños mayor será la resolución. La resolución es básicamente medida en millones de píxeles
o megapixeles. A estos archivos escaneados se les denomina mapas de bits.
4.5. Problemas
4.1. ¿Qué es el hardware de computadora?
4.2. ¿Cuál considera que sea la función principal de la computadora?
4.3. Si un procesador no tiene periféricos, ¿Cual sería su utilidad?
4.4. ¿Cómo se llama el módulo de sistema operativo que maneja a los dispositivos de entra-
da/salida?
4.5. ¿Cuáles son las tendencias actuales sobre los dispositivos de entrada/salida?
4.6. ¿Cómo se estructura el núcleo para poder soportar tantos dispositivos como sea posible?
4.7. ¿Como instala dispositivos de entrada/salida en Windows y Linux?
4.8. Investigue cuál es la forma de instalación de algún dispositivo en Solaris y en MacOs.
4.9. ¿En qué categorías se pueden clasificar los dispostivos? Explique cada una de ellas y
escriba dos ejemplos de cada una de éstas.
4.10. Defina con sus palabras lo siguiente: puerto, bus y protocolo.
4.11. Defina qué es un manejador de dispositivo.
4.12. Defina qué es una tarjeta controladora o controlador de dispositivo.
4.13. ¿Qué significa UART?, ¿Para qué se usa?
4.14. Explique de forma general los registros más comunes que puede tener una tarjeta con-
troladora de dispositivo.
4.15. Describa el funcionamiento general de una tarjeta controladora.
4.16. Mencione cinco direcciones y el controlador asociado a ellas.
4.17. ¿Qué es una interrupción?
4.18. Describa el proceso que lleva a cabo la CPU cuando recibe una interrupción.
4.19. Mencione tres eventos que podrían generar una interrupción.
4.20. Explique los objetivos que persigue el software de entrada/salida.

246 4.5. PROBLEMAS
4.21. Explique las dos formas que existen para interactuar con las tarjetas controladoras.
4.22. Explique el concepto de negociación.
4.23. Explique el concepto de interrupción.
4.24. ¿Qué ventajas y desventajas ofrecen las técnicas anteriores?
4.25. ¿En qué casos usaría negociación y en cuáles interrupciones? Fundamente sus respues-
tas.
4.26. ¿Cuantas líneas de interrupción posee un procesador y cuales son?
4.27. ¿Cómo se llama el módulo que atiende las interrupciones?
4.28. ¿En qué lugar se guardan las direcciones de las rutinas de manejo de interrupción?, ¿De
qué tamaño es?
4.29. ¿Cómo se resuelve el problema que conlleva el tener un vector de interrupciones rela-
tivamente pequeño?
4.30. Mencione dos tipos de interrupciones no enmascarables.
4.31. Explique el concepto de PIO.
4.32. Explique el concepto de DMA.
4.33. ¿Qué servicios proporciona el kernel que se relacionan con la entrada/salida?
4.34. Explique con sus palabras la planificación de entrada/salida.
4.35. ¿Cómo se implementa la planificación de entrada/salida?
4.36. Explique cómo se hace uso del almacenamiento en búfer.
4.37. ¿Para qué se hace uso de almacenamiento caché en el manejo de dispositivos?
4.38. ¿Qué es una cola de dispositivo?
4.39. ¿Cómo implementan el tratamiento de errores los sistemas basados en UNIX/Linux?
4.40. ¿Qué es un disco RAM?
4.41. ¿Qué ventajas ofrece un disco RAM?, ¿Qué desventajas tiene?

4.42. ¿Cuáles son los elementos principales de un disco duro?
4.43. ¿Qué factores determinan la densidad de almacenamiento de un disco duro?
4.44. ¿A qué se le llama volumen de disco?
4.45. Liste las características más importantes de un disco duro que son dadas por los fabri-
cantes.
4.46. Explique las divisiones lógicas más comunes de un disco duro.
4.47. Explique qué es el costo del acceso al disco.
4.48. ¿Qué es el tiempo de búsqueda?
4.49. ¿Qué es el tiempo de rotación?, y ¿El tiempo de transferencia?
4.50. ¿Qué se guarda en el Master Boot Record?
4.51. ¿Para que sirve una partición?
4.52. Explique los tipos de particiones que existen.
4.53. ¿Qué es una unidad lógica?
4.54. ¿En qué ocasiones debe dejarse un espacio no particionado?
4.55. Liste las particiones que necesita un sistema basado en UNIX/Linux y explique para
qué sirven.
4.56. ¿Para que sirve la orden fdisk?
4.57. ¿En que directorio se guardan los archivos de dispositivos?
4.58. ¿Qué orden se usa en un sistema UNIX/Linux para crear un sistema de archivos?
4.59. ¿Qué orden usa para crrear un sistema de archivos en Windows?
4.60. ¿Cuales son los factores que determinan el tiempo para leer o escribir un bloque de
disco?
4.61. Explique las estrategias para planificar el acceso al disco.
4.62. ¿Qué es un reloj de computadora?

248 4.5. PROBLEMAS
4.63. ¿Cómo se genera la señal de reloj en un sistema de computadora?
4.64. ¿Qué componentes en general tiene un reloj de cuarzo?
4.65. ¿Qué tareas debe llevar a cabo el software de reloj?
4.66. ¿Qué operaciones debe tener implementado el manejador de reloj?
4.67. Explique para qué sirve la orden time orden.
4.68. Defina con sus palabras el concepto de terminal.
4.69. ¿Cómo están clasificadas las terminales? Explique cada categoría.
4.70. ¿Cuales son los tipos más comunes de terminales? Explique cada una de ellas.
4.71. ¿Para qué sirve una terminal en memoria?
4.72. Describa las tarjetas gráficas más comunes.
4.73. ¿Qué es la renderización?
4.74. ¿Qué función tiene el teclado?
4.75. ¿A qué se refiere el concepto de scan code?
4.76. Describa los tipos de teclado que existen en la actualidad.
4.77. Describa los conectores típicos usados para conectar un teclado.
4.78. Explique cómo se genera el código de acción “make code”.
4.79. ¿Cómo se le llama a la acción de liberar una tecla?
4.80. ¿Cuál es la regla de formación de los keycodes?
4.81. ¿Cómo se implementa el búfer del teclado?
4.82. Describa el funcionamiento de los manejadores de teclado.
4.83. Describa el funcionamiento de los manejadores de video.
4.84. ¿Para que sirve ell paquete termcap?
4.85. Describa el funcionamiento de las interfaces gráficas de usuario.

4.86. Describa los elementos usados en las interfaces gráficas.
4.87. ¿Qué es un Widget?
4.88. Describa el sistema X Window.
4.89. Describa el sistema Windows.

El manejo de los dispositivos de entrada salida está delegado en su mayor parte a los fabri-
cantes de los mismos. El sistema operativo ofrece una interfaz única que debe ser usada por los
mismos para su correcta inclusión en el kernel. Milenkovic[94] proporciona una buena explica-
ción de los principios de entrada salida en el capítulo 9 y Silberschatz[95] define los sistemas
de entrada salida en el capítulo 13. Tanenbaum[101] hace una descripción muy detallada de los
dispositivos de entrada salida incluyendo los discos, relojes, terminales y las interfaces gráficas
de usuario.
Pratt[81] describe una arquitectura de entrada salida segura para el usuario.
Otro enfoque propuesto muchas veces es la de ejecutar los controladores de dispositivos a
nivel de usuario. Leslie[61, 63] y su equipos sugieren que este enfoque puede mejorar la robustez
de un sistema operativo. Chubb[75, 80] también propone este enfoque para un sistema Linux.
Leslie y Heiser[62] aseveran que la mayoría de los dispositivos son inseguros.
Goel y Duchamp[44] explican cómo se llevaron a cabo la emulación de algunos manejadores
de dispositivos de Linux en Mach.
Barned y Richards[12] discuten las actividades de estandarización y tecnología que se llevan
a cabo en el proyecto UDI Uniform Driver Interface y en el proyecto INCITS (InterNational
Committee for Information Technology Standards) Technical Committee R1, Real-time Compu-
ting Systems.
Ross[87] describe en su tesis doctoral la planificación reactiva para el manejo de los sistemas
de entrada salida paralelos. Hayter[46] describe una arquitectura de estación de trabajo con
soporte multimedia.
Barham[11] describe una arquitectura para el manejo de dispositivos en un sistema operativo
de multi servicios.
Capítulo 5
Sistemas de archivos
A computadora fue creada básicamente para el procesamiento de información, es mucho

L más útil cuando se tienen que procesar miles o millones de datos y como sabemos, la me-
moria principal es limitada. Existen algunas aplicaciones para las cuales el almacenamiento en
memoria es suficiente puesto que la información que entregan puede visualizarse directamente
en pantalla y después de ello, ésta puede perderse, pero hay otras como los bases de datos, que
deben manejar cantidades enormes de datos y además mantener también en algún lugar los re-
sultados obtenidos. En cuyo caso, la memoria principal es muy poca y su volatilidad un gran
problema, puesto que no puede permitirse la pérdida de información. La mayoría de los maneja-
dores de bases de datos deben de mantener su información por meses, incluso años. Es posible
también que deba tener registros históricos que no deben de perderse nunca.
Otro problema importante es que este manejador de bases de datos tenga la oportunidad de
proporcionar información a más de un usuario a la vez, permitiendo así que puedan acceder a
diferentes datos al mismo tiempo o a un mismo dato de forma secuencial garantizando de esta
forma la integridad de la bases de datos.
La forma de resolver estos problemas es diseñando los procesos de modo tal que éstos sean
completamente independientes de los datos y viceversa, haciendo que las llamadas del sistema
permitan una homogeneidad total para el acceso a los datos. Así, definiremos los requisitos
mínimos necesarios para almacenar la información a largo plazo:
Almacenar grandes cantidades de información. Este punto es usualmente cubierto utilizan-

do discos duros o cintas magnéticas de gran capacidad. Como se vio en la sección 1.1.1.2
existen actualmente discos duros que pueden llegar al Terabyte o más aún en discos que
son usados para atender a miles de usuarios. En caso de que se necesite más espacio los
discos físicos pueden agruparse en unidades lógicas de modo que el usuario los vean como
uno solo.
251
252 5.1. CONCEPTO
Los procesos deben poder guardar información para cuando la requieran. El sistema ope-
rativo debe proporcionar los mecanismos adecuados para que un proceso pueda guardar
su información a discos o cintas y también los medios para que pueda recuperar esa infor-
mación en otro momento.
Acceso concurrente a la información. El sistema operativo debe permitir que dos o más pro-
cesos accedan simultáneamente a la información contenida en disco. Por ejemplo, en caso
de accesos de sólo lectura y en accesos de escritura debe serializar los procesos para ga-
rantizar la integridad de la información.
5.1. Concepto
La estructura de datos que utiliza el sistema operativo para lograr sus objetivos se le llama
archivo. De este modo, cuando un proceso requiere guardar información, le solicita al sistema
operativo la creación de un archivo, hace las operaciones necesarias sobre él y al final, el proceso
solicita el cierre del archivo. Desde este momento, el archivo ha quedado guardado y el proceso
podrá acceder a éste en el momento en que lo desee, no importando si el proceso muere y luego
es corrido nuevamente.
El sistema operativo debe de ser capaz de manejar todos los archivos que le sean solicitados
por diferentes procesos. A la estructura de datos que usa el sistema operativo para este propósito,
se le denomina sistema de archivos. Esta estructura permite mantener información importante
acerca de los archivos como por ejemplo:
nombre del archivo. Es el que le asigna el usuario para poder acceder a éste.
El propietario del archivo. Es la persona que ha creado el archivo y que puede indicar qué
operaciones pueden realizarse en él.
Los grupos u otras personas que pueden acceder al archivo. El propietario indica a qué per-
sonas o grupos de ellas puede dar acceso de lectura, escritura o ambas.
Ubicación en disco. Indica en qué lugar del disco se encuentra almacenada la información.
Tipo. En algunos sistemas operativos es importante el tipo, por que permite cargar la aplicación
asociada con el archivo de modo que pueda ser interpretado correctamente.
Fecha y hora. Indican cuando se creó el archivo y a qué hora, algunos sistemas de archivos
indican simplemente la fecha y la hora de la última modificación.
CAPÍTULO 5. SISTEMAS DE ARCHIVOS 253
El sistema operativo maneja una abstracción de datos denominada archivo que permite ocul-
tar al usuario todos los detalles relativos al almacenamiento de la información. De esta forma,
lo único que tiene que saber el usuario es la manera de crear un archivo, abrirlo si ya está crea-
do, leer o escribir en éste y cerrarlo para liberar las estructuras proporcionadas por el sistema
operativo.
Un archivo es una colección de datos relacionados, el usuario le asigna un nombre y el
archivo puede entonces crearse, escribir en él, leer bytes o registros sobreescribir en algunas
posiciones y cerrar el archivo para asegurarse de que toda la información se ha vaciado de los
búferes intermedios al disco o cinta. Para un usuario normal, los archivos son la única forma que
tiene para guardar alguna información a disco, no importa que solamente necesite guardar uno
o dos registros o incluso sólo algunos caracteres. Será necesario hacerlo mediante un archivo.
La información de los archivos es almacenada en la estructura de directorios que el sistema
operativo guarda también en el almacenamiento secundario. Una entrada de directorio típica es-
tá compuesta del nombre del archivo y de un identificador de usuario que es único en todo el
sistema. El identificador a su vez, permite localizar los otros atributos del archivo. En muchos
sistemas de archivos es normal que cada entrada de archivo necesite al menos un kilobyte de
almacenamiento. En sistemas donde se tienen muchos archivos, podría ser un problema de ren-
dimiento el tener la estructura de directorios en disco, por lo que en sistemas de tipo servidor, es
común que el sistema operativo coloque buena parte de la estructura de directorios en memoria
para mejorar la eficiencia del sistema. Esto implica que si en algún momento se tiene una caída
de la alimentación de la energía eléctrica, esta estructura de directorios en memoria se pierda
sin haberla podido reflejar en disco, lo que implica un daño severo a la estructura de directorios
de disco. Si estas caídas de alimentación eléctrica persisten, puede llegar el momento en que
el sistema de archivos quede inutilizado. De ahí la importancia de proporcionar un sistema de
respaldo de energía eléctrica a estos servidores de modo que el sistema operativo pueda apa-
garse correctamente, permitiendo una sincronización adecuada de la estructura de directorios
contenida en memoria con la contenida en disco.
5.1.1. Operaciones con los archivos

El sistema operativo se encarga de proporcionar un conjunto de llamadas al sistema que
constituyen todas las operaciones que pueden realizarse sobre un archivo. Las llamadas que
proporciona el sistema operativo son para crear, escribir, leer, reposicionar, borrar, y truncar
archivos. En seguida damos una descripción más detallada sobre estas operaciones.
Creación. Cuando se crea un archivo, el usuario proporciona el nombre, el sistema ope-

rativo creará una entrada de directorio y le asignará los permisos por defecto si es que el
254 5.1. CONCEPTO
usuario no los proporcionó.
Escritura. Para escribir datos en un archivo, debe de abrirse en modo escritura proporcio-
nando el nombre del archivo en el que se desea escribir y elegir el tipo de transferencia
que se efectuará, seleccionando la llamada al sistema correspondiente, que puede ser mo-
do caracter o modo bloque. Con esta información, el sistema operativo busca el nombre
dentro de su estructura de directorios y lleva un apuntador en el lugar en que debe de rea-
lizarse la siguiente escritura. Si se añade más información, el apuntador se actualiza en el
lugar correspondiente.
Lectura. Para leer de un archivo, éste debe abrirse en modo lectura, especificando el nom-
bre del archivo que se desea leer. Después de hace una llamada al sistema que puede ser
usando una llamada de lectura de bloque o de caracter, especificando la variable apun-
tador que proporcione la dirección en memoria en donde debe guardarse la información
leída. El sistema operativo lleva también un apuntador de archivo que indica la posición
siguiente que debe ser leída.
Reposicionamiento. Permite reubicar los apuntadores de lectura o escritura dentro de un

archivo. Esta operación se conoce también como seek o búsqueda dentro del archivo.
Borrado. Para eliminar un archivo, el usuario proporciona el nombre y entonces el sistema

operativo recorre su estructura de directorios, si lo encuentra, entonces se libera todo el
espacio ocupado por el archivo y la entrada se elimina de la estructura de directorios.
Truncado. En ocasiones es necesario borrar el contenido de un archivo, pero sin cambiar

su nombre ni sus atributos, excepto por supuesto el tamaño del archivo, o en se defecto
sólo es necesario borrar parte de éste. En lugar de borrar y crear nuevamente el archivo
esta operación permite eliminar parte o toda la información que contiene el archivo, es-
to dependerá de la posición del apuntador de archivo. Si éste se encuentra al principio,
borrará todo el contenido, si está en medio solo truncará a partir de esa posición.
Estas son las operaciones básicas. En un sistema operativo real, habrá muchas más llamadas
a función como por ejemplo, aquellas que se utilizan para obtener los atributos de un archivo, y
las llamadas al sistema para el manejo de errores de entrada salida del sistema, entre otras.
5.1.2. Jerarquía de datos

Básicamente todos los tipos de datos que encontramos en un lenguaje de programación son
susceptibles de ser almacenados en disco. Para ello, el sistema operativo solamente proporcio-
nará dos maneras de acceso a un archivo:
1. Acceso por caracter o byte por byte.
2. Acceso por bloque o lectura de muchos caracteres o bytes al mismo tiempo.
Mediante estas dos formas de acceso, el usuario tendrá que traducir todos los datos que vaya
a manejar a bytes o bloques, de manera que pueda guardar su información a disco. El usuario,
por la tanto, es el responsable de interpretar correctamente el tipo de dato que está guardado en
el archivo. En general, los tipos de datos que puede manejar un lenguaje de programación son
los siguientes:
char. Representa un byte o un caracter. Un byte es un número que desde 0 hasta 28 o que puede
representar un número entre ±27 .
int. Un número entero está representado por una palabra. Las palabras varían de acuerdo a la
arquitectura de la computadora que se esté usando y puede ir desde los 16, 32, hasta los
64 bits. De acuerdo a esto varía la cantidad que puede guardar una palabra. Por ejemplo,
si tenemos una palabra de 16 bits entonces podremos guardar enteros positivos que van
desde 0 hasta 216 . Si queremos representar número negativos y positivos. El rango sería
de ±215 .
float. El tamaño que usa en bytes es 4 el valor máximo es 1037 y el mínimo es 10−37 .
long. Usa también 4 bytes y sus valores van desde 2,147,483,647 con signo (4294967295 cuan-
do es unsigned) y el mínimo es -2,147,483,648 (0 cuando es unsigned).
long long. Su Tamaño en bytes es 8. El valor máximo es:

9,223,372,036,854,775,807 (18,446,744,073,709,551,616 cuando es unsigned).
Su valor mínimo es 9,223,372,036,854,775,808 (0 cuando es unsigned).
short. Tiene solamente 2 bytes y su valor máximo es 32767 (65,535 cuando es unsigned). Su
valor mínimo es -32768 (0 cuando es unsigned).
double. Ocupa 8 bytes, su exponente máximo es 10308 y su exponente mínimo es 10−308 .
void. Es un tipo especial en donde se le exige al usuario conocer el número de bytes que ocupa
su datos y al momento de usarlo debe de indicar cómo quiere que se trate esa cantidad de
bytes.
256 5.2. NOCIÓN DE ARCHIVO REAL Y VIRTUAL
Después de los tipos de datos básicos, el siguiente nivel son los arreglos y matrices de datos
simples. Estos pueden almacenarse como bloques de bytes a disco o pueden guardarse byte a
byte, debiendo entonces ser nuevamente interpretados de acuerdo a las necesidades del usuario.
El siguiente nivel en los lenguajes de programación son las estructuras. Una estructura es
un conjunto de variables de datos de distintos tipos pero agrupados bajo un sólo nombre y que
pueden entonces ser manejados como tal.
El último nivel son los objetos, que agrupan a un conjunto de variables de datos de distintos
tipos junto con las operaciones que pueden realizarse en ellas. En realidad, cuando se guarda
un objeto a disco, solamente se guardan los datos contenidos en éste el código es tomado del
programa objeto. A diferencia de una estructura, con un objeto es posible mandar a guardar a
otros objetos que estén dentro de éste y si estos subobjetos están definidos por otros objetos,
entonces es posible a su vez guardar también sus contenidos. De esta forma se pueden guardar
varios niveles de objetos con una sola llamada al objeto principal, permitiendo así recuperar
exactamente el estado del objeto en el momento en que fue guardado. Este comportamiento sería
muy difícil de conseguir con estructuras ordinarias. El único requisito para poder hacer esto es
permitir primeramente a los subobjetos que guarden su información correspondiente y luego el
objeto principal deberá guardar la suya. Al momento de leer la información, el objeto principal
deberá leer sus datos y enseguida indicar a sus subobjetos que hagan lo propio, siguiendo el
mismo orden.
Es común que todos los arreglos, las matrices, las estructuras y los objetos se guarden como
bloques, puesto que sería más ineficiente guardarlos byte a byte.
Algunos lenguajes de programación como Pascal imponen al usuario que en la creación del
archivo se indique el tipo de dato que va a ser guardado en el archivo. En otros como en C el
usuario es el responsable de interpretar los bytes que escribe y lee de disco.
Los archivos, a nivel programación se consideran también tipos de datos, y es claro para el
programador que debe primeramente declarar variables de tipo archivo para poder hacer uso de
ellas. Estas variables tendrán diferentes nombres dependiendo del lenguaje de programación.
Por ejemplo, en C tenemos solamente variables del tipo FILE. En C++ se cuenta también con
flujos o streams. Ambos enfoques están orientados a byte o bloque. Depende del programador
el significado que vaya a darles a la secuencia de bytes que lee o escribe.
5.2. Noción de archivo real y virtual

Cuando un proceso crea un archivo, le asigna un nombre, realiza un conjunto de operaciones
sobre éste y cuando el proceso termina, debe cerrar el archivo correspondiente. Después que ha
terminado el proceso, el archivo persiste almacenado en disco y otros procesos pueden hacer uso
del archivo usando su nombre como referencia. A los datos almacenados en el disco se le llama
archivo real y al nombre asignado al archivo se le conoce como archivo virtual.
Las reglas que se usan para nombrar archivos tiene que ver más en cómo facilitarles a los
usuarios la tarea de recordar los contenidos que en hacer un uso más eficiente del espacio de
almacenamiento de las entradas de directorios. Por lo tanto, la evolución de la manera en que se
nombran los archivos ha seguido esta línea.
En los primeros sistemas personales, era común nombrar a los archivos hasta con ocho letras
para el nombre un punto y tres letras para la extensión. No permitían el uso de caracteres espe-
ciales. En la medida en que se hicieron evidentes las desventajas, se fue haciendo más versátil
la forma de nombrar archivos. Actualmente, la mayoría de los sistemas soportan sistemas de
archivos que pueden almacenar hasta 255 caracteres como nombre de un archivo y es posible
que el usuario haga uso de prácticamente cualquier caracter para incluirlo dentro de un archivo,
ya sean caracteres alfanuméricos o caracteres especiales.
En los sistemas personales basados en MS-DOS era común que el sistema operativo no hicie-
ra distinción entre las letras mayúsculas y minúsculas. En los sistemas basados en UNIX/Linux
y en los sistemas de archivos NTFS de Windows 2000 en adelante todos ellos hacen distinción
entre mayúsculas y minúsculas. Esta nueva forma permite más variedad cuando se nombran
archivos y a su vez permiten crear contraseñas más fuertes, siendo más difícil decodificarlas.
Muchos sistemas de archivos manejan nombres de archivos en dos partes, separadas con
un punto. La parte que va después del punto se llama extensión y es usada para determinar
la aplicación que debe ser lanzada cuando se haga referencia a ese archivo. En los sistemas
UNIX/Linux, los archivos pueden tener dos o más extensiones. Esto indica que el archivo ha
sido procesado por más de una aplicación. Por ejemplo un archivo que se llame respaldo.tar.gz
indica que el archivo fue generado por el archivador tar y luego fue comprimido por gzip. Por
lo tanto, debe primero descomprimirse y luego desarchivarse para poder hacer uso del archivo.
En los sistemas operativos orientados a usuario es común que las extensiones estén asociadas
a ciertas aplicaciones. En la tabla 5.1 damos un listado de las asociaciones más comunes.
Como se comentó, en los sistemas tipos UNIX/Linux es responsabilidad del usuario y de
las aplicaciones asignar un significado a una extensión específica. el sistema operativo no tiene
cuidado de cómo usarlas. En realidad quien lleva a cabo estas asociaciones es el front-end gráfico
o la interfaz gráfica. Por ejemplo, KDE, GNOME o CDE.
En un sistema operativo basado en Windows, éste lleva un registro de las extensiones y el
programa correspondiente asociado con la misma. Si existe más de una aplicación que puede
manejar esa extensión, el sistema operativo podrá mostrar mediante una ventana secundaria
qué aplicaciones están disponibles para el archivo. Pero por omisión utilizará un sólo programa
archivo.bat Archivo de órdenes de comandos

archivo.c Programa fuente de un programa en C
archivo.html Archivo de internet de marcado de hipertexto
archivo.mp3 Archivo de música comprimido con MPEG capa 3
archivo.jpg Archivo de imagen fija codificada con JPEG
archivo.o Archivo objeto de salida aún no ligado
archivo.ps Archivo postcript
archivo.tex Archivo fuente para el programa TEX
archivo.zip Archivo comprimido
archivo.txt Archivo de texto
archivo.tar Archivo que contiene más archivos y/directorios
archivo.ogg Archivo de música comprimido en formato libre
Tabla 5.1: Extensiones más comunes
asociado.
5.2.1. Tipos de archivos

Varios sistemas operativos hacen la distinción entre los archivos de usuario y los archivos
del sistema. Es común que a los archivos de usuario de les denomine archivos normales y a
ciertos archivos del sistema se les denomine archivos especiales. Por ejemplo En los sistemas
UNIX/Linux y Windows tenemos directorios y archivos normales. UNIX/Linux manejan ade-
más archivos especiales orientados a caracteres y archivos orientados a bloques. Un archivo
normal mantiene información específica de los usuarios, como imágenes, texto y música.
Los directorios son archivos de sistema especiales que mantienen listas de archivos o di-
rectorios de modo que pueda construirse la estructura de directorios y forma parte esencial del
sistema de archivos.
Los archivos especiales de caracteres se usan para modelar dispositivos serie como el teclado
y las impresoras. Los archivos de bloque se usan para representar a los discos duros formando
parte del manejo de dispositivos de entrada salida y serán tratados en su oportunidad en la
sección 5.6.
Los archivos normales se pueden dividir básicamente en dos tipos:
1. Archivos de texto.
2. Archivos binarios.
5.2.2. Archivos de texto
Los archivos de texto regularmente son archivos ASCII. Estos consisten en una o más líneas
de texto terminadas con un caracter de retorno de carro. En otros se usa el caracter de salto de
línea y los sistemas basados en MS-DOS usan ambos. Una ventaja de este tipo de archivo es
que puede verse e imprimirse tal como está teniendo un tipo de letra determinado, del mismo
modo en que se ve puede imprimirse. Este tipo de archivos no soporta gráficos ni tampoco
formateos complejos. Es lo más cercano a lo que podríamos realizar con una máquina de escribir
mecánica. Otra ventaja importante es su velocidad de manejo y su tamaño. También es posible
usar una gran cantidad de editores de texto y además poder hacerlo en diferentes plataformas,
con algunos cambios mínimos, que la mayoría de las veces, las aplicaciones de intercambio
de archivos como ftp hacen automáticamente. El manejo de archivos de texto facilita mucho la
comunicación entre aplicaciones siendo también posible enviar la salida de un programa hacia
la entrada de otro mediante el uso de tuberías, que significa básicamente la redirección de las
salidas a otros programas o dispositivos, siendo una forma estándar de comunicación entre las
utilerías proporcionadas por los sistemas operativos y entre varios programas de aplicación.
Los lenguajes de programación usan comúnmente archivos de texto que se denominan pro-
gramas fuente. El compilador toma estos archivos y genera un archivo objeto que posterior-
mente se enlaza con un conjunto de librerías para finalmente obtener el código binario listo para
ejecutarse. Algunos editores como LATEX (orientado a estructura) toman también un conjunto
de órdenes de formateo en texto plano y producen un documento perfectamente legible de alta
calidad. Hay que notar que las órdenes van insertadas en el propio documento de texto al igual
que en otros editores de formateo como openoffice writer (con un enfoque denominado “Lo que
tú ves es lo que obtienes”) pero su salida real se verá solamente bajo el propio editor de texto o
cuando esté impreso el trabajo.
Al igual que sucede con un archivo de código fuente de un lenguaje de programación, el
resultado o código binario no se verá hasta que se haya pasado el archivo fuente por la fase de
compilación.
Otro ejemplo de uso de archivos tipo texto son las páginas web. El lenguaje denominado
html (Hiper Text Meta Language) permite a los diseñadores Web colocar órdenes de tipo texto
para distribuir todo tipo de información dentro de una página WEB. El archivo no necesita pasar
por ningún proceso de compilación. El resultado se verá a través del navegador de internet el
cual interpretará adecuadamente las órdenes y mostrará el resultado al usuario final. Si vemos
estos archivos en un editor de texto normal, podremos ver las órdenes que utilizó el diseñador.
Las imágenes estarán indicadas por un enlace a la ubicación de la misma y además seremos
capaces de ver la mayoría del texto plano de la página, tal como sucedería en un archivo de
LATEX.
Es común también que la mayoría de los sistemas operativos basados en UNIX/Linux usen
archivos de texto para mantener los archivos de configuración del sistema. De esta forma es
relativamente sencillo agregar o eliminar parámetros de configuración del sistema.
Los sistemas basados en Windows, también usan archivos de configuración basados en texto,
como en el archivo de configuración Windows.ini, pero también usa otro formato que debe ser
previamente procesado para poder ser legible tal como el registro de Windows.
5.2.3. Archivos binarios

Los archivos binarios, simplemente significa que no son archivos ASCII, por lo tanto, no
pueden verse directamente en pantalla o en una impresora y es necesario alguna aplicación para
poder ver el contenido real. En caso de que llegaran a visualizarse o imprimirse con aplicaciones
que manejan archivos de texto solamente se verán caracteres sin coherencia e incluso basura.
Esto es debido a que incluyen caracteres de control que no son imprimibles. Dentro de este tipo
de archivos tenemos los de imágenes, los archivos portables tipo PDF y los archivos ejecutables
entre otros.
Los archivos ejecutables se caracterizan en windows por dos extensiones muy comunes: los
archivos con extensión .com y los archivos con extensión .exe. Aunque también se manejan otros
tipos como los .bat que son archivos de órdenes y los archivos de librerías dinámicas con .dll.
A diferencia de windows los sistemas basados en UNIX/Linux no necesitan extensión para
que el sistema operativo los identifique como ejecutables. Lo primero que hace el sistema ope-
rativo es analizar sus permisos y si éstos incluyen el permiso de ejecución entonces procederá
a ejecutarlo. Así, si se desea implementar un archivo de órdenes (equivalente a un .bat en win-
dows) solamente se escribe un comando por línea dentro del archivo, se guarda y se agrega el
permiso de ejecución al mismo.
En cuanto a los archivos de código binario, se hace todavía una verificación más: se deter-
mina si el archivo empieza con el denominado número mágico. Todos los archivos binarios
ejecutables empiezan con esta marca. Esto se hace para evitar algún problema intentando ejecu-
tar instrucciones aleatorias que se podrían mal interpretar si se pretende ejecutar un archivo de
texto por ejemplo. Si el archivo no contiene este número entonces el sistema tratará de ejecu-
tarlo como un archivo por lotes e intentará obtener la primera línea del archivo. Por norma, en
UNIX/Linux los archivos por lotes deben identificar en la primera línea el intérprete que debe
ser utilizado para su ejecución. Aún así, si no encuentra esta línea, la tomará entonces como
una orden del shell por defecto y si no se encuentra dentro del repertorio de instrucciones del
intérprete, éste indicará un error de orden inválida.
5.2.4. Interfase con el usuario

Cuando se habla de computación personal, lo que se busca es facilidad de manejo. Lo pri-
mero que aprende a manejar cualquier usuario es la creación de nuevas carpetas, creación de
archivos y ejecución de aplicaciones. Con estas bases, el usuario empezará entonces a introducir
datos dentro de los archivos organizarlos y enviar algunos archivos a impresión. ya sea mediante
órdenes del sistema operativo o indirectamente a través de aplicaciones.
El sistema de archivos puede, por tanto, dividirse en dos secciones bien diferenciadas:
1. Los archivos.
2. Las carpetas o directorios.
Los archivos son el elemento básico que guarda la información o el código ejecutable de las
aplicaciones.
La estructura de directorios organiza a los archivos de acuerdo a la solicitud de los usuarios
siendo común que cada aplicación cree sus propios directorios.
Es costumbre también que los sistemas operativos manejen una estructura de directorios
preestablecida para organizar todos los archivos pertenecientes al mismo y sugieran a su vez
otra estructura para el manejo de usuarios.
5.3. Componentes de un sistema de archivos

Un sistema de administración de archivos es un conjunto de librerías del sistema operativo
que proporciona a los usuarios y aplicaciones los servicios relativos al empleo de archivos. El
sistema operativo actúa como interface entre los usuarios y el hardware de almacenamiento
(discos, duros, memorias USB, cintas y otros más).
Los componentes de un sistema de archivos típico de acuerdo a Stallings [96] son:
1. Controladores de dispositivos. Es el nivel más bajo. Se comunica directamente con los

periféricos. Es responsable de comenzar las operaciones de E/S en in dispositivo y proce-
sar la finalización de E/S.
2. Sistema de archivos básico. Se le conoce también comonivel de E/S física constituye la

interfaz primaria con el entorno exterior. Este nivel trata con bloques de datos queda son
intercambiados con los sistemas de almacenamiento. Se ocupa de ubicar dichos bloques en
el dispositivo de almacenamiento secundario e intermedio que se encuentra en la memoria
principal, también conocido como buffer. Este nivel no toma en cuenta ni el contenido
262 5.3. COMPONENTES DE UN SISTEMA DE ARCHIVOS
ni la estructura de los archivos implicados. El sistema de archivos básico forma parte del
sistema operativo.
3. Supervisor básico de E/S. Se encarga de comenzar y finalizar todo tipo de entrada/salida

relacionada con archivos. Este nivel mantiene estructuras de control que se encargan de
las entradas y salidas con los dispositivos, la planificación y el estado de las operacio-
nes realizadas sobre los archivos. Panifica los accesos a los medios de almacenamiento
para optimizar su rendimiento. En este nivel se asignan los buffer de E/S y se reserva la
memoria secundaria.
4. La entrada/Salida lógica. Es la parte del sistema de archivos que permite a los usuarios y
aplicaciones acceder a los sistemas de archivos. Esto se explica más a detalle en la sección
5.3.1 de llamadas al sistema.
En la figura 5.1 se puede ver la interacción entre sus diversos componentes.
Figura 5.1: Componentes y funciones del Sistema de archivos
5.3.1. Llamadas al sistema (systemcalls)

Después de haber analizado la teoría general del sistema de archivos, vamos ahora a dar una
introducción sobre la forma en que están implementadas las instrucciones de manejo de archivos
del sistema.
5.3.2. Interfaz de la biblioteca estándar

Esta biblioteca contiene las funciones que se utilizan para el manejo de archivos. Tienen
un parámetro de tipo apuntador hacia una estructura FILE. Tanto FILE como las definiciones
prototipo se encuentran en el archivo de cabecera <stdio.h>. Las funciones que vamos a analizar
para el manejo de archivos son fopen, fread, fwrite y fclose.
5.3.2.1. Fopen
Su declaración es:
#include <stdio.h>
FILE *fopen (const char *file_name, const char type);
Si todo funciona correctamente fopen abre el archivo cuyo nombre está apuntado por fi-
le_name y le asocia un flujo que no es más que una estructura de tipo file. Si la llamada falla
fopen devuelve un apuntador NULL y errno tendrá el código de error producido.
Type es una cadena que le indica a fopen el modo de acceso al archivo. Entre otros, puede
tomar los siguientes valores:
“r” Abrir para leer.
“w” Abrir para escribir.
“a” Abrir para escribir al final del archivo o crar un archivo, si no existe para escribir en
él.
“r+” Abrir para actualizar el archivo (leer y escribir).
“w+” Abrir el archivo para leer y escribir, pero truncando primero su tamaño a 0 bytes. Si
el archivo no existe, se crea para leer y escribir en él.
5.3.2.2. Fread
Permite leer datos de un archivo a través de su flujo asociado. Su declaración es:

#include <stdio.h>
size_t fread (char *ptr, size_t size, size_t nitems, FILE *stream);
Fread copia en el arreglo apuntado por ptr nitems bloques de datos procedentes del archivo
apuntado por stream. Cada bloque, o ítem, de datos leído tiene un tamaño de size bytes.
Fread termina su lectura cuando encuentra el final del archivo, se da una condición de error
o ha leído el total de bloques que se le pide. Si la lectura se realiza correctamente, fread devuelve
el total de bloques leídos. Si el valor devuelto es 0 significa que se ha encontrado el final del
archivo.
5.3.2.3. Fwrite
Fwrite permite escribir datos en un archivo a través de su flujo asociado. Su declaración es:
#include <stdio.h>
size_t fwrite (const char *ptr, size_t size, size_t nitems, FILE *stream); Fwrite copia
en el archivo apuntado por stream nitems bloques, cada uno de tamaño de size bytes. Los
bloques a escribir se encuentran en la zona de memoria apuntada por ptr.
Si la llamada se ejecuta correctamente, devuelve el total de bloques escritos. Si se da una
condición de error, el número devuelto por fwrite será distinto del número de bloques que se le
pasó como parámetro.
5.3.2.4. Fclose
Fclose cierra un archivo que ha sido abierto con fopen. Su declaración es la siguiente:
#include <stdio.h>
int fclose (FILE *stream);
Fclose hace que toda la memoria intermedia de datos asociada a stream sea escrita en el
disco, que el espacio de memoria reservado para las memorias intermedias sea liberado y que el
flujo sea cerrado.
La operación de cerrado se realiza de forma automática sobre todos los archivos abiertos
cuando llamamos a la función exit. Fclose devuelve 0 si la llamada se ha ejecutado correcta-
mente y EOF (Final de archivo) en caso de que se produzca un error.
5.3.2.5. Entrada/salida de caracteres con la biblioteca estándar
En la biblioteca estándar existen dos funciones para leer y escribir caracteres (bytes) sobre
un archivo asociado a un flujo. Estas funciones son fgetc y fputc que se declaran así:
#include <stdio.h>
int fgetc (FILE *stream); /* Lectura de caracteres */
int fputc (int c, FILE *stream) /*Escritura de caracteres*/
Fgetc devuelve el caracter siguiente al último leído del archivo asociado al stream. Aunque
fgetc va a leer los datos del archivo, devuelve un entero, con lo que se consiguen dos objetivos:
el primero es que el byte leído se devuelve como un caracter sin signo, y el segundo, que cuando
se detecta el final del archivo se puede devolver EOF(-1) sin que haya lugar a confundirlo con
un dato válido.
En fputc, c es el byte que se va a escribir en el archivo. Cuando se produce un error, fputc
devuelve EOF. Si la escritura se produce correctamente, fputc devuelve el valor escrito.
Estas dos funciones tienen dos macros equivalentes: getc y putc, que se sirven de la memoria
intermedia asociada al flujo y de las funciones __fillbuf y __flsbuf para agilizar el proceso de
lectura/escritura.
Las funciones getchar y putchar, que actúan sobre la entrada estándar y la salida estándar,
pueden codificarse como macros a partir de getc y putc de la siguiente forma:
#define getchar() getc (stdin)
#define putchar(c) putc ((c), stdout)
5.3.3. Tipos de interfaz

En la sección anterior se detallaron solamente algunas de las llamadas al sistema referentes
al manejo de archivos a nivel programación. La mayoría de los sistemas operativos cuenta con
al menos los siguientes tipos de interfaz:
1. Interfaz de usuario modo consola.
2. Interfaz de usuario modo gráfico.
3. Interfaz para el programador.
5.3.4. Interfaz de usuario modo consola

La interfaz de usuario se asocia comúnmente al manejo de archivos vía consola o vía interfaz
gráfica.
En muchos sistemas basados en UNIX/Linux, es normal hacer solamente una traducción de
las llamadas gráficas a las llamadas de consola. De esta forma, el programador dedicado a los
comandos de consola puede mejorar las capacidades de éstos sin preocuparse por la interfaz
gráfica. Los programadores de front-ends o interfaces gráficas en cambio, se dedican a propor-
cionar una interfaz gráfica agradable sin preocuparse por los detalles internos de las órdenes de
líneas de comandos y solamente interactúan con ellos vía parámetros.
Órdenes de consola o terminal. Se tienen muchas órdenes para interactuar con la computado-
ra a nivel consola. Esta interfaz permite tener un mayor control tanto sobre el sistema operativo
como sobre el hardware. El problema es que la línea de aprendizaje es larga y la complejidad ma-
yor. En general, para que un usuario haga uso de la consola o terminal de realizar los siguientes
pasos:
1. Entrar al sistema o inicio de sesión. Existen muchos programas que permiten conectarse
con la computadora y que dependen directamente de sistema operativo que se utilice. En
general, si estamos frente a una computadora local, ésta debe de arrancarse. Cuando el
sistema operativo termine de cargar, se presentará una pantalla de bienvenida y a su vez
indicará que introduzcamos un nombre de usuario y una contraseña. Si es administrador
del sistema dio de alta nuestro usuario entonces entraremos al sistema y podemos hacer
uso de el.
Si deseamos entrar a una computadora remota vía terminal, el proceso, no varía mucho,
se arranca la terminal, ésta contactará con el servidor remoto y nuevamente solocitará el
nombre de usuario y contraseña. Si es válida entonces iniciaremos una sesión y podremos
trabajar.
El último caso, es cuando necesitamos conectarnos desde una computadora a un servidor.
Es necesario contar con un programa que permita hacer la conexión. Tenemos el más co-
mún llamado telnet que permite iniciar una sesión bajo una terminal virtual. El problema
de esta orden es que envía el nombre de usuario sin incriptar, y es muy sencillo que otros
usuarios puedan ver la contraseña vía un sniffer que se usa para analizar los paquetes de
red y ver su contenido. Existe otro protocolo llamado ssh o shell seguro permite enviar
toda la información incriptada al servidor y recibirla de la misma forma.
Existen otros programas que permiten hacer estas funciones de diferente forma. Por ejem-
plo, si deseamos solamente enviar archivos y no abrir una sesión de trabajo, se puede
hacer uso de la orden ftp. Otra vez, con este protocolo la información viaja sin incriptar.
Su contraparte incriptada es la orden sftp o protocolo de transferencia de archivos segura.
2. Trabajar en la sesión. Incluye la ejecución de programas, edición de textos, cálculos

matemáticos impresión de documentos, tareas de administración y todas las relacionadas
con el uso de la computadora.
En la actualidad existen demasiadas órdenes que pueden usarse vía consola. A continua-
ción tenemos un listado de las más comunes y la función que realizan.
cd <directorio>. Cambia directorio, sirve para ir a un directorio concreto del sis-

tema. Por ejemplo cd /home hace que vayamos al directorio donde se guardan los
directorios personales de cada usuario del sistema. La orden cd sin parámetros hace
que vayamos a nuestro directorio personal.
mkdir <nombre directorio>. Crear un directorio vacío, su uso es muy simple, so-
lamente hay que añadir el nombre del nuevo directorio detrás del comando. Por
ejemplo mkdir prueba.
rm <dir>. Permite borrar el directorio llamado <dir>. Si el directorio no está vacío
no se borra. Si se desea borrarlo con todo y su contenido se usa entonces rm -R
<dir>.
ls o dir. lista el contenido de un directorio.
df -h. Se usa para ver la cantidad de espacio libre en el disco.
fuser -m <dispositivo>. Muestra todos los usuarios o procesos que están usando
el <dispositivo>. Si se usa la opción -mk permite “matar” los procesos que están
usándolo de mod que pueda desmontarse.
sudo <comando>. Permite ejecutar una orden con permisos de administrador. Cuan-
do necesitamos algún comando con más privilegios que los que tenemos como usua-
rio usamos entonces la orden sudo.
history. Muestra el historial de órdenes que se han ejecutado últimamente. Podemos
volver a ejecutar una orden del historial escribiendo !<numero de la historia>.
top. Muestra los procesos que se están ejecutando, carga del procesador, memoria
libre y ocupada. Esta información se actualiza constantemente.
ps -aux. La orden ps muestra los procesos activos en nuestra máquina, con la opción
-aux muestra información detallada de cada uno de ellos, como el propietario y el
uso de cpu por parte del proceso.
kill <pid>. Permite eliminar (matar) un proceso del sistema, es necesario conocer el
número del proceso que se desea terminar. Podemos obtener este pid de otras órdenes
como ps por ejemplo.
xkill. Igual que el comando kill pero de forma gráfica, si tienes una ventana que se ha
quedado colgada, ejecuta xkill y selecciona la ventana con el cursor que te aparecerá.
La ventana y el proceso que la creó morirán.
man <orden>. Quizás uno de las más importantes comandos del sistema, muestra
la ayuda detallada de la orden dada en <orden>.
3. Salir de la sesión. Después de trabajar en la computadora es conveniente terminar la

sesión de modo que no pueda hacer uso de ella otra persona. Al hacer esto nos aseguramos
que otros usuarios tengan que entrar con su nombre y contraseña. Se debe evitar en la
medida de lo posible prestar estos nombres y contraseñas a otros, debido a que pueden
hacer tareas a nuestro nombre que sean dañinas u ofensivas a terceros y por lo tanto,
podemos tener problemas al ser los representantes directos de la cuenta.
5.3.5. Interfaz de usuario modo gráfico

Actualmente la mayoría de los sistemas operativos comerciales hacen uso de una interfaz
gráfica intuitiva de modo que sea relativamente de usar para los usuarios nuevos. Muchas de las
tareas que pueden hacer a nivel consola también se pueden hacer en modo gráfico. El costo del
ambiente gráfico es mucho mayor, tanto en el consumo de energía eléctrica como en ciclos de
CPU, pero dado el aumento de capacidades de los sistemas actuales y la reducción de precios,
es común contar con estas interfaces en nuestras computadoras.
Al igual que con una sesión de consola, es necesario primeramente autenticarse. El siste-
ma operativo solicitará el nombre de usuario y contraseña y si éstas coinciden entonces éste
empezará a cargar nuestra sesión gráfica.
En los sistemas basados en Windows, el medio ambiente gráfico está integrado al sistema
operativo, lo que permite una respuesta más rápida. En los sistemas basados en UNIX/Linux, es
un programa separado del sistema operativo, lo que permite mayor versatilidad a cambio de un
desempeño un poco menor.
En la figura 5.2 se puede ver cómo el uso de íconos favorece un rápido aprendizaje a nivel
intuitivo acerca de las tareas que puede llevar a cabo una aplicación.
Esta facilidad de uso también tiene un costo: el entorno gráfico en muchas ocasiones no
puede cubrir todas las facilidades que proporciona la consola. Por tanto, para aquellas personas
que pretendan ser administradores de centros de cómputo, es muy importante que tengan un
dominio completo de la interfaz gráfica y también conocimientos profundos sobre el uso de las
órdenes de consola.
Para los usuarios normales no es estrictamente necesario tener un conocimiento completo
sobre el uso de las órdenes de consola, pero se recomienda que al menos tengan el conocimien-
to básico necesario como para que puedan crear/eliminar directorios y copiar archivos desde la
consola para casos de emergencia en donde el entorno gráfico por alguna situación falló y es ne-
cesario recuperar cierta información. Se recomienda en segundo término, familiarizarse también
con el manejo de particiones, formateo de discos y respaldo de datos.
5.3.5.1. Interfaz para el programador
El sistema operativo proporciona diferentes librerías que pueden ser usadas por los compi-
ladores y éstas a su vez por los programadores, de manera que éstos puedan llevar a cabo sus
Figura 5.2: Sesión gráfica de KDE
tareas de programación de sistemas o de aplicaciones.

Muchas librerías se usan para la escritura de programas que trabajan a nivel de líneas de
órdenes, interfaces de texto o librerías para que hagan uso de interfaces gráficas. Estas libre-
rías existen a niveles muy bajos de programación. Algunos fabricantes o grupos de personas
se encargan de establecer diferentes niveles de complejidad o subrutinas que agrupan muchas
instrucciones de bajo nivel proporcionadas por el sistema operativo de modo que se facilita la
escritura de programas de aplicación complejos.
Como ejemplo, en todos los sistemas UNIX/Linux tenemos un directorio llamado /usr. En
este directorio tenemos los directorios /include y /lib.
En el directorio /include existen todos los archivos de cabecera que proporciona los nombres
de las funciones correspondientes a las llamadas del sistema y algunas más como rutinas de
manejo de estructuras de datos básicas como pilas, colas, arreglos dinámicos entro otras. Aunque
cada día se agregan nuevas funcionalidades y rutinas de más alto nivel que se incorporan a estas
librerías.
En el directorio /lib tenemos el código objeto correspondiente a las cabeceras definidas en el
directorio /include. Con estos dos directorios es suficiente para programar aplicaciones a nivel
270 5.4. ORGANIZACIÓN LÓGICA Y FÍSICA
consola.
Existen otros directorios que contienen las cabeceras y las librerías para el desarrollo de
aplicaciones gráficas que se encuentran también en /include y en /lib. Hay que recordar, sin
embargo, que muchas de éstas deben ser instaladas vía terceras partes y que en sí no forman
parte del sistema operativo.
5.3.6. Lenguaje de comunicación y pipelines o conductos

En la sección 5.3.4 vimos una lista de órdenes pertenecientes al modo consola.
En un sistema basado en Windows a la consola se le conoce como símbolo del sistema. En
todas las versiones ha sido el mismo y en general ha decaído su uso a tal grado que en vez de
aumentar funcionalidades las nuevas versiones de Windows disminuyen este tipo de órdenes
a las mínimas necesarias. Aunque aún con esas limitaciones algunas aplicaciones de líneas de
órdenes tienen también un muy buen control sobre hardware específico, por ejemplo las órdenes
para el manejo de la tarjeta de red y las conexiones de redes.
En los sistemas UNIX/Linux existen muchos intérpretes de órdenes llamados shells que
discutiremos en la siguiente sección.
5.4. Organización lógica y física
5.4.1. Organización lógica

La organización lógica de un sistema de archivos desde un punto de vista de implementación
son las siguientes como está descrita por Stallings [96]: En la figura 5.3 se pueden observar los
componentes se un sistema de archivos típico.
1. Pilas. Los datos se recogen en el orden en que llegan. Cada registro consta de una ráfaga
de datos. Su finalidad es acumular una masa de datos y guardarla.
2. Archivos secuenciales. En esta estructua se emplea un formato fijo para los registros, son
de la misma longitud y constan del mismo número de campos de tamaño fijo con un orden
determinado. Se necesita almacenar los valores de cada campo; el nombre del campo y
la longitud de cada uno son atributos de la estructura del archivo. Cada registro tiene un
campo clave que lo identifica (generalmente es el primero de cada registro). Los registros
se almacenan en secuencia por la clave. Se utilizan normalmente en aplicaciones de pro-
cesos por lotes, ya que es la única organización de archivos que se puede guardar tanto en
Figura 5.3: Componentes típicos de un sistema de archivos
cintas como en discos. Para las aplicaciones interactivas que incluyen peticiones o actua-
lizaciones de registros individuales, los archivos secuenciales no son óptimos. El acceso
requiere una búsqueda secuencial de correspondencias con la clave. Si el archivo entero
o gran parte de él pueden traerse a la memoria principal de una sola vez, se podrán apli-
car técnicas de búsquedas más eficientes. Al acceder un registro de un archivo secuencial
grande, se produce un procesamiento extra y un retardo considerable.
3. Archivos secuenciales indexados. Los registros se organizan en una secuencia basada en

un campo clave presentando dos características, un índice del archivo para soportar los
accesos aleatorios y un archivo de desbordamiento. El índice proporciona una capacidad
de búsqueda para llagar rápidamente al registro deseado y el archivo de desbordamiento
es similar al archivo de registros usado en un archivo secuencial, pero está integrado de
forma que los archivos de desbordamiento se ubiquen siguiendo un puntero desde su regis-
tro predecesor. La estructura más simple tiene como índice un archivo secuencial simple,
cada registro del archivo índice tiene dos campos, un campo clave igual al del archivo
principal y un puntero al archivo principal. Para encontrar un campo especifico se busca
en el índice hasta encontrar el valor mayor de la clave que es iguale o precede al valor
deseado de la clave, la búsqueda continua en el archivo principal a partir de la posición
que indique el puntero. Cada registro del archivo principal tiene un campo adicional que
es un puntero al archivo de desbordamiento. Cuando se inserta un nuevo registro al archi-
vo, también se añade al archivo de desbordamiento. El registro del archivo principal que
272 5.4. ORGANIZACIÓN LÓGICA Y FÍSICA
precede inmediatamente al nuevo registro según la secuencia lógica se actualiza con un

puntero del registro nuevo en el archivo de desbordamiento, si el registro inmediatamente
anterior está también en el archivo de desbordamiento se actualizará el puntero en el regis-
tro. Para procesar secuencialmente un archivo completo los registros del archivo principal
se procesarán en secuencia hasta encontrar un puntero al archivo de desbordamiento, el
acceso continua en el archivo de desbordamiento hasta que encuentra un puntero nulo,
entonces renueva el acceso donde se abandonó en el archivo principal.
4. Archivos indexados. A los registros se accede solo a través de sus índices. No hay res-
ticción en la ubicación de los registros, al menos un índice contiene un puntero a cada
registro y pueden emplearse registros de longitud variable. Se suelen utilizar dos tipos de
índices, uno exhaustivo que contiene una entrada para cada registro del archivo principal
y se organiza como un archivo secuencial para facilitar la búsqueda, el otro índice es par-
cial que contiene entrada a los registros donde esté el campo de interés. Con registro de
longitud variable, algunos registros no contendrán todos los campos y cuando se añade un
registro al archivo principal, todos los archivos de índices deben actualizarse.
5. Archivos directos o de dispersión. Explotan la capacidad de los discos para acceder

directamente a cualquier bloque de dirección conocida. Se requiere un campo clave en
cada registro. Los archivos directos son muy usados donde se necesita un acceso muy
rápido, donde se usan registros de longitud fija y donde siempre se accede a los registros
de una vez.
Desde el punto de vista del usuario la organización lógica de la mayoría de los sistemas
de archivos actual es a través de jerarquías y se les denominan carpetas, directorios o catálogos.
Cada directorio puede contener a su vez, más carpetas o archivos. Estas carpetas pueden contener
todavía más archivos y carpetas, y así sucesivamente. La cantidad de carpetas y archivos que
puede contener el sistema está limitado a la capacidad del medio de almacenamiento y a la
capacidad de direccionamiento del sistema operativo La estructura jerárquica permite mantener
organizados lógicamente los archivos y las carpetas.
5.4.2. Organización física

Los sistemas de archivos se guardan comúnmente en discos, aunque también ahora es posible
en una memoria flash portátil. En la sección 4.4.2 hicimos un resumen acerca de la organización
lógica de un disco y de cómo prepararlo para poder almacenar un sistema de archivos en él.
Ahora pasaremos a las técnicas que existen para lograr este objetivo. Recordando un poco, un
disco se puede dividir en los siguientes bloques básicos:
Figura 5.4: Vista de usuario del sistema de archivos
El registro Maestro de Arranque (MBR). Master Boot Record sirve para arrancar la compu-
tadora.
Tabla de particiones. Viene al final del MBR y contiene la dirección inicial y final de cada
partición. Una de las particiones de la tabla está marcada como activa.
Varias particiones primarias y lógicas. Pueden contener diferentes sistemas operativos o da-
tos.
Cuando el usuario enciende la computadora, después de realizar la verificación del hardware

buscará los dispositivos de arranque de acuerdo a la prioridad establecida en el BIOS. Una vez
que ha detectado que existe una unidad de arranque válida, leerá el MBR de esta unidad y lo
ejecutará. El programa alamacenado en el MBR, localiza la partición activa y lee entonces el pri-
mer bloque llamado bloque de arranque para enseguida, ejecutarlo. El programa del bloque de
arranque carga el sistema operativo contenido en esa partición. Por cuestiones de uniformidad,
cada partición comienza con un bloque de arranque aunque no tenga un sistema operativo.
bloque de arranque Superbloque Admon. de espacio libre Nodos-i Dir. raíz Archivos y directorios
Figura 5.5: Organización del sistema de archivos en UNIX/Linux
Estas son las convenciones que la mayoría de sistemas operativos siguen. Después de ello, la
organización del sistema de archivos difiere. Por ejemplo, en los sistemas UNIX/Linux, existen
los elementos mostrados en la figura 5.5. Observe la presencia del superbloque. Aquí se guarda
274 5.5. MECANISMOS DE ACCESO A LOS ARCHIVOS
información referente al tipo de archivos que existe en la partición, el número de bloques que
hay en el sistema de archivos y otros datos. Como esta información es muy importante varios
sistemas mantienen una copia de seguridad en diferentes bloques de la partición.
También hay un área reservada para administrar el espacio libre, el conjunto de nodos-i
almacenados en una estructura que permite conocer todo lo relativo al archivo. Existe una de
ellas por cada archivo, el directorio raíz que viene a ser la estructura más alta dentro de esa
partición y después los archivos y directorios que puede contener la partición.
5.5. Mecanismos de acceso a los archivos

Actualmente la mayoría de los sistemas operativos proporcionan una visión jerárquica de
directorios que contienen archivos y se sugiere que el usuario haga también un análisis ade-
cuado acerca de cómo almacenar sus archivos en carpetas de modo que éstos se encuentren
relacionados por medio de una o más características.
El sistema operativo mapeará los archivos lógicos vistos por el usuario a archivos físicos
almacenados en un disco duro, un CD-ROM o una memoria USB, haciendo transparente al
usuario el almacenamiento de sus archivos en cualquiera de estos y otros dispositivos, incluso,
en la mayoría de los sistemas actuales se permite el acceso remoto a directorios o archivos como
si estuvieran guardando información localmente. Desde el momento en que el usuario se conecta
con un servidor, éste le proporciona una interfaz idéntica a como si estuviera trabajando local-
mente en el equipo remoto. Así, el usuario o las aplicaciones no se enteran, ni tienen por qué, de
cómo es que el sistema operativo hace las operaciones de entrada salida correspondientes, esto
es, si son realizadas en los dispositivos de entrada salida locales o en los remotos.
5.5.1. Métodos de Acceso

Los métodos de acceso dependen mucho del dispositivo de almacenamiento que se esté
usando. En general se cuentan con dos tipos de tecnologías de almacenamiento:
Cintas Magnéticas. Éstas sólo permiten al acceso secuencial de los datos, pudiendo rebobi-
narse las veces que sea necesario para poder releer otro dato. La ventaja que tienen estos
dispositivos es su gran capacidad de almacenamiento en comparación con los discos y
su relación muy atractiva de costo/byte. Aunque esto está cambiando muy rápidamente a
favor de los discos.
Discos. Permiten el acceso directo a los discos con cierto tiempo de latencia en la recuperación
de la información, pero mucho más rápidos que el acceso a una cinta. También se incluyen
en esta categoría a las unidades de CD/DVD y a las memorias USB o pendrive.
Del funcionamiento de estos dispositivos se desprenden también los dos enfoques de acceso
a los archivos. El acceso secuencial y el acceso directo que analizaremos en las dos secciones
siguientes.
5.5.2. Acceso secuencial

Como se comentó, una cinta solamente puede entregar registros uno después de otro, sin po-
der regresar rápidamente a los registros leídos anteriormente, por ende el acceso secuencial solo
permite procesar registro por registro. El sistema operativo mantiene un apuntador de archivo
hacia el siguiente registro a leer. Si se hace una operación de escritura sucede algo similar: el
sistema operativo realiza la operación de escritura y mueve el apuntador de archivo hacia el si-
guiente registro. Si se encuentra al final del archivo, entonces apunta hacia el nuevo espacio que
puede ser ocupado por otro registro. En la figura 5.6 vemos cual es a estructura de un archivo en
cinta.
Figura 5.6: Archivo de acceso secuencial
5.5.3. Acceso directo o aleatorio.

El archivo se compone de registros de tamaño fijo lo que permite a las aplicaciones leer o
escribir información de ese mismo tamaño en cualquier lugar concreto del archivo. Este método
276 5.5. MECANISMOS DE ACCESO A LOS ARCHIVOS
aprovecha las ventajas de los discos que pueden escribir rápidamente información en un cilindro
dado, permitiendo así el acceso inmediato a cualquier bloque del archivo tanto para lectura como
para escritura.
En general un archivo se considera compuesto de varios bloques de tamaño fijo, por lo tanto,
las aplicaciones o el sistema operativo pueden acceder a cualquier registro en casi el mismo
tiempo, en comparación con los dispositivos de acceso secuencial. También es posible simular
en un dispostivo de acceso aleatorio el acceso secuencial, puesto que también es posible acceder
a los registros en el orden dado.
En la mayoría de los sistemas actuales están orientados a caracteres o bytes y a bloques. Por
lo tanto, el usuario debe de proporcionar el byte o el bloque al que desea acceder. Un disco o un
CD-ROM es común que guarde muchos archivos. El usuario entonces debe de proporcionar el
nombre al que desea acceder y el byte o número de bloque, refiriéndose a partir del byte cero
o al bloque cero del archivo en mención. El sistema operativo traducirá entonces el nombre del
archivo y el número de bloque a una dirección de número de pista y número de sector o de
cilindro para determinar su ubicación exacta dentro del disco. Al número de byte o bloque y
nombre del archivo se le denomina número de bloque relativo.
Un número de bloque relativo es un índice referido al comienzo del archivo. Entonces el

primer bloque relativo del archivo será 0, el siguiente 1 y así sucesivamente. El nombre del
archivo se busca en las entradas de directorio, en donde se encuentra almacenado el comienzo
verdadero en disco de ese archivo. Después de haber encontrado el comienzo real en el disco, el
sistema operativo añade el número de bloque solicitado por el usuario para formar su dirección
correcta. Algunos sistemas utilizan el cero como número de bloque inicial dentro del archivo,
mientras que otros utilizan el 1 como inicio del archivo.
Ahora supóngase que un usuario desea acceder al registro N de un archivo. Suponga también
que los registros tienen una longitud lógica de L. El sistema operativo traducirá esta petición en
una solicitud de entrada salida sonde se piden entonces L bytes a partir de la ubicación L ∗ (N )
dentro del archivo. Como los registros lógicos son del mismo tamaño, resulta sencillo realizar
operaciones de lectura escritura o borrar registros en cualquier parte del archivo.
El sistema operativo verifica también que el resultado anterior no exceda el tamaño espe-
cificado en la entrada de directorio. Si se excede, entonces generará un error de fin de archivo
alcanzado End Of File (EOF). De esta forma se asegura que un usuario no acceda a otros
archivos para los cuales no tenga autorización.
5.5.4. Acceso a archivos por índice
Los manejadores de bases de datos utilizan algunos archivos especiales llamados archivos de
índice los cuales relacionan un dato con una posición específica dentro del archivo, permitiendo
así un acceso extremadamente rápido cuando un usuario realiza búsquedas de datos. De esta
forma el manejador de bases de datos solamente realizará la búsqueda en el archivo índice el
cual es mucho más pequeño que la base de datos original, después que ha encontrado el dato
solicitado, leerá la posición del registro en disco y procederá a leerlo completo de disco para
ponerlo a disposición del usuario.
Figura 5.7: Ejemplo de archivo índice y archivo relativo
Como puede verse en la figura 5.7, el archivo índice tiene almacenados los apellidos de
algunas personas y en otro campo guarda la dirección del registro en donde se localiza toda la
información concerniente a esa persona. Con este método no es forzoso que el archivo relativo
se encuentre ordenado, puesto que es más fácil ordenar el archivo índice.
Un archivo relativo puede tener varios archivos índice asociados, lo que permite una gran
versatilidad al momento de hacer búsquedas. Es común en bases de datos utilizar campos llave
para generar los archivos de índice. Es lógico que para poder usar un archivo de índice es ne-
cesario primero establecer el campo llave que va a utilizarse y entonces generarlo. Este proceso
de generación de archivos índice puede tardar mucho tiempo de acuerdo al tamaño del archi-
vo relativo. Una vez generado, los accesos serán mucho más rápidos por medio del archivo de
índice. Otro problema que debe tenerse en cuenta es que a medida que se agregue información
al archivo relativo, ésta no se refleja en el archivo índice, por lo que es necesario generarlo de
nuevo o implementar mecanismos que permitan la actualización simultánea de ambos archivos.
278 5.6. MANEJO DE ESPACIO EN MEMORIA SECUNDARIA
5.6. Manejo de espacio en memoria secundaria

Después de que hemos visto la perspectiva del usuario, es momento de pasar a la perspectiva
del implementador. A los usuarios les interesa qué nombres tienen los archivos y qué operacio-
nes pueden realizar sobre ellos, les interesa también saber si la estructura de directorios es de
tipo árbol y otros aspectos de interfaz. A los implementadores les interesa más qué técnicas y
estructuras de datos deben de usar para implementar lo más eficientemente posible el almacena-
miento de archivos en disco y la implementación de directorios, cómo administrar el espacio de
disco y como hacer que todo funcione de la forma más eficiente y confiable posible.
5.6.1. Implementación de archivos

La tarea más importante que debe de controlar el sistema de archivos es conocer qué bloques
pertenecen a cada uno y proporcionar los mecanismos de lectura y escritura de los mismos. Para
proporcionar estas funcionalidades existen diferentes técnicas. A continuación daremos las más
comunes.
Asignación contigua. Es el esquema más sencillo. Se define el tamaño de bloque, que puede
ser ya sea por sector, o cluster que es lo más común. Ya definido el tamaño de bloque, se divide el
tamaño total del archivo entre el tamaño de bloque y se asigna esa cantidad de bloques contiguos
para almacenar el archivo en disco. El sistema operativo registra los bloques asignados como
marcados e indica en la estructura de datos a qué archivo le pertenecen.
La asignación de espacio contiguo en disco tiene dos ventajas importantes:
1. Su implementación es sencilla por que para llevar el control solamente necesita registrar
dos datos: la dirección en disco del primer bloque y el número de bloques con que cuenta el
archivo. Así es posible localizar cualquier bloque del archivo mediante una simple suma.
2. El desempeño de lectura es excelente porque puede leerse todo el archivo del disco en una
sola operación. Sólo se necesita posicionar el brazo en el primer bloque y los datos podrá
transferirse al máximo ancho de banda. (Lógicamente si el archivo es más grande que un
cilindro entonces necesitará reposicionarse el brazo en el siguiente al siguiente).
El problema principal de esta técnica es que con el tiempo tiende a fragmentarse. La frag-
mentación significa que, a medida que se van añadiendo y eliminando archivos, puede llegarse
el caso en el que el número de bloques contiguos disponibles no sea suficiente para almacenar
archivos mayores que un bloque.
Vamos a poner un ejemplo de cómo es que se fragmenta un disco. Supóngase que el arreglo
de la figura 5.8 es el disco. Se define un tamaño de bloque de 10Kb y que se necesitan hacer las
siguientes operaciones:
1. Escribir el archivo a de 20Kb.
2. Escribir el archivo b de 15Kb.
3. Escribir el archivo c de 10Kb.
4. Borrar el archivo b de 15Kb.
5. Escribir el archivo d de 30 Kb.
6. Borrar el archivo c de 10Kb
7. Escribir el archivo e de 40Kb.
a a b b c
⇓
a a c d d d
⇓
a a d d d e e e e
Figura 5.8: Fragmentación del disco con el almacenamiento secuencial
De acuerdo a las operaciones realizadas, cuando el disco está limpio se escribe sin ningún
problema los archivos a, b y el archivo c. Todos van en secuencia. Cuando se borra el archivo b
queda un hueco de dos bloques. La siguiente petición, exige tres bloques libres para el archivo d,
de modo que tiene que colocarse al final de los archivos en el espacio libre del disco. Enseguida
viene una petición de eliminación del archivo c de 10Kb. Como está junto con el archivo que se
borró el b tenemos ahora tres bloques libres. La última petición es la escritura del archivo e, pero
éste solicita cuatro bloques de modo que debe de escribirse de nuevo al final de los archivos en
el espacio libre.
Aunque en el ejemplo se observó que cuando se eliminan archivos que están juntos se crean
bloques más grandes, si las nuevas peticiones requieren aún más espacio, éstas deben de hacerse
al final de los archivos.
A medida que trascurre el tiempo, se irán acumulando los huecos pequeños, evitando así
escribir archivos grandes aún cuando la suma de todos los huecos sea mayor al tamaño del
archivo que se desea escribir.
Por el problema de fragmentación es que esta técnica ya no se utiliza para la implementación
de sistemas de archivos aunque para el acceso a ellos es muy rápida, por que siempre podemos
acceder a ellos en una sola operación de lectura.
Asignación por lista ligada. Este método consiste en guardar el archivo como una lista ligada
de bloques de modo que cada palabra contenida al principio del bloque indique la posición del
siguiente. El resto del bloque es para datos.
Con este esquema, las entradas de directorio almacena solamente la dirección del primer blo-
que del archivo, siendo entonces más pequeñas. Otra ventaja con respecto a la técnica anterior
es que aquí se utilizan todos los bloques, por tanto no existe fragmentación del del disco o frag-
mentación externa. Solamente existe fragmentación interna en el último bloque. La desventaja
es que el acceso a cada bloque implica la lectura del anterior, lo que hace a esta técnica dema-
siado lenta en operaciones de lectura/escritura debido al acceso aleatorio y al reposicionado de
las cabezas de lectura/escritura en busca de cada bloque del archivo.
2 −→ 13 −→ 15 −→ EOF
Bloque 0 Bloque 1 Bloque 2 Bloque 3
8 2 13 15
Figura 5.9: Uso de listas ligadas de bloques de disco
Como puede verse, otro problema es que el acceso ya no puede hacerse directo. Esto es,
para que el sistema operativo pueda, por ejemplo, alcanzar el último bloque de un archivo es
necesario leer n − 1 bloques, para poder acceder al número de bloque final, por lo que se pierden
todas las ventajas que puede proporcionar el disco con acceso aleatorio. Otro problema con
este enfoque es que la cantidad de bytes almacenados en un bloque ya no es potencia de 2. La
mayoría de los programadores está acostumbrado a utilizar potencias de dos como tamaño de
bloque, de modo que el sistema operativo necesita concatenar dos bloques para dar la cantidad
de bytes solicitada, lo que disminuye el rendimiento del sistema debido a las operaciones de
copiado.
Estas desventajas pueden eliminarse sacando el apuntador de cada bloque de disco y colo-
cándolo en una tabla en memoria. En la figura 5.10 podemos ver cómo quedaría esta tabla para
el ejemplo de la figura 5.9.
Bloque Físico
0
1
2 13
3 8
4
5
6
7
8 2 ←− Aquí empieza el archivo
9
10
11
12
13 15
14
15 EOF
Figura 5.10: Tabla de Asignación de Archivos
Con este enfoque los programadores pueden hacer uso de los bloques completos. El sistema
operativo tiene la opción de cargar la tabla de asignación de archivos o FAT (File Allocation
Table) a memoria una sola vez, de modo que el acceso a ésta es muy rápido.
No obstante el problema de fragmentación sigue existiendo aunque a otro nivel. Cuando
el sistema operativo crea por primera vez un archivo, le asigna todos los bloques que necesita
y éstos será muy probable que estén juntos. A medida que se añaden y se eliminan archivos
pequeños y grandes, el sistema operativo empezará a asignar bloques, en donde quiera que
éstos se encuentren. Esto hace que con el tiempo sea más difícil acceder a cada bloque del
archivo, debido a que se tendrá que hacer nuevamente muchos reposicionamientos de las cabezas
lectoras/escritoras. Aunque el sistema puede acceder a todos los bloques, el tiempo de acceso a
los mismos se incrementará en la medida en que éstos se encuentren dispersos por todo el disco.
Los sistemas operativos de microsoft han venido arrastrando el problema de fragmentación
desde el sistema de discos MS-DOS. Aunque era difícil notarlo por la pequeña capacidad de
los discos. A medida que éstos fueron creciendo en capacidad, el problema se hizo mucho más
notorio.
El problema se agrava cuando el sistema operativo tiene que implementar el servicio de
memoria virtual, si éste no define una partición especial en disco. Para poner un ejemplo, los
sistemas operativos de Microsoft siguieron este enfoque. Los diseñadores, no creyeron necesario
tener una partición especial para intercambio a modo de no reducir el espacio útil en disco
duro del usuario. De esta forma, el sistema operativo sigue indicando al usuario que cuenta con
todo su espacio en disco duro, pero el sistema mantiene oculto un archivo de intercambio que
aumenta y disminuye de acuerdo al uso del sistema. Esto ocasiona que muchos bloques queden
reservados por el sistema de intercambio así, los archivos de usuario tienden a fragmentarse
más rápido de lo normal, siendo entonces obligatorio correr cada cierto tiempo una aplicación
para defragmentar el disco duro que viene incluida en el propio sistema operativo o mediante
aplicaciones de terceros.
Otra desventaja de este método es que, para ganar la mayor velocidad posible, toda la tabla
debe de estar en memoria. Para discos pequeños, esto no es problema, pero para un disco de 80
GB con un bloques de 1 KB, la tabla necesitaría 80 millones de entradas. Si cada entrada necesita
tener un mínimo de cuatro bytes, entonces la tabla tendría 320 MB, lo que sería demasiado,
incluso para las computadoras actuales de 1 GB de memoria RAM.
Nodos-i. En este método se asocia a cada archivo una estructura de datos llamada nodos-i o
nodos-índice que contiene los atributos y direcciones en disco de los bloques de archivo. Dado
el nodo-i, es posible encontrar todos los bloques del archivo. La gran ventaja de este esquema
respecto a los métodos anteriores es que el nodo-i sólo tiene que estar en la memoria cuando
el archivo correspondiente está abierto. Si cada nodo-i ocupa n bytes y no puede haber más de
k archivos abiertos al mismo tiempo, la memoria total ocupada por el arreglo que contiene los
nodos-i de los archivos abiertos es de sólo kn bytes.
Este arreglo, es mucho más pequeño que el que se utilizaría para mantener la tabla de asigna-
ción de archivos. La razón es simple. La tabla debe tener forzosamente un tamaño proporcional
al tamaño del disco. Si el disco tiene n bloques, la tabla necesita n entradas. A medida que
aumenta el tamaño de los discos aumentará también la tabla en la misma proporción. En con-
traste„ el esquema de nodos-i requiere un arreglo en la memoria cuyo tamaño es proporcional al
número máximo de archivos que pueden estar abiertos a la vez. No tiene que ver el tamaño del
disco.
La estructura de un nodo-i la podemos ver en la figura 5.11. Como puede verse, en la es-
tructura se designa la primera parte del bloque para mantener los atributos del archivo, luego
se designan las primeras diez entradas para almacenar direcciones directas simples. Esto es,
almacenan direcciones de bloques de datos directamente.
La dirección de bloque de apuntadores se usa para extender la capacidad de los apuntadores
directos simples. Estas entradas pueden ser:
Indirecto simple. Es aquella que reserva un bloque de disco para guardar direcciones de tipo
directo simple.
Indirecto doble. Señala un bloque que contiene direcciones de bloques de tipo indirecto simple.
Indirecto triple. Señala un bloque que contiene direcciones de tipo indirecto doble.
Este mecanismo puede extenderse hasta donde sea necesario de modo que puedan guardarse
archivos de tamaño arbitrario. Para hacerlo, simplemente hay que agregar a la tabla de la figura
Atributos del archivo

Dirección del bloque 0 −→
Dirección de bloque de apuntadores −→ Bloque con más direcciones
Figura 5.11: Estructura de un nodo-i
5.11 más entradas al final especificando el tipo de direccionamiento que manejará, pudiendo ser
incluso, indirecto cuádruple, quíntuple, ... hasta donde sea necesario.
Implementación de directorios. Hasta ahora hemos visto la forma en la que es posible ma-
nejar los archivos en disco. A partir de este momento pasaremos a ver cómo se implementan los
directorios.
Un archivo, debe tener un nombre y atributos que permitan indicar las operaciones que pue-
den llevarse a cabo sobre éste y los usuarios que están autorizados a efectuarlas. Para que un
archivo pueda ser utilizado, es necesario primeramente abrir el archivo. Para ello el usuario debe
proporcionar un nombre, ya sea por medio de una ruta absoluta o una relativa. Con esta infor-
mación, el sistema operativo localizará la entrada de directorio correspondiente y comenzará a
efectuar las operaciones solicitadas.
De acuerdo a la técnica de manejo de archivos utilizada la información obtenida de la entrada
de directorio puede variar. Por ejemplo, puede proporcionar el bloque inicial y final si es que se
usa asignación contigua o el primer bloque si el esquema es de tipo FAT o nodo-i. En todos los
casos la principal función del sistema de directorios es estableces una correspondencia entre el
nombre de archivo ASCII y la información necesaria para localizar los datos.
Un aspecto muy importante es la manera en la que se relacionan los atributos con los archivos
y las entradas de directorio, su dueño, la fecha y hora de creación. Muchos sistemas lo hacen en
las entradas de directorios.
La primera opción es usar una estructura de datos con entradas de tamaño fijo, una por cada
archivo, que contiene un nombre de archivo de longitud fija, una estructura con los atributos del
archivo y una o más direcciones de bloques que indica en qué posición en disco se encuentra el
archivo.
En la figura 5.12 vemos cómo pueden distribuirse estos datos en la estructura de datos de
entradas de tamaño fijo.
nombres.txt atributos Bloque inicial

cuentas.dat atributos Bloque inicial
muebles atributos bloque inicial
Figura 5.12: Implementación de directorio con entradas de archivo fijas
El manejo de la estructura presentada en la figura 5.12 es muy fácil de implementar pero tiene
muchos inconvenientes. El primero de ellos es que por ser los nombres demasiado cortos llegan
a ser poco descriptivos, lo que dificulta la búsqueda de éstos por el usuario. Otro problema es el
manejo de subdirectorios que deben de implementarse de otra forma para mantener la estructura
coherente.
En los sistemas que usan nodos-i, se utiliza la misma lista, pero la diferencia es que ahora
usan uno o más nodos-i para guardar la información referente a los atributos en lugar de hacerlo
en las entradas de directorio. De esta forma, la entrada de directorio puede ser más corta: se
incluye solamente el m¿nombre de archivo y un número de nodo-i. En la figura 5.13 vemos
cómo se organiza esta estructura.
nombres.txt −→
cuentas.dat −→
muebles −→
-
Estructura de
datos con
atributos.
Figura 5.13: Implementación de directorios con nodos-i

Este enfoque permite organizar lógicamente directorios, subdirectorios y archivos en una

misma estructura diferenciando a un directorio de un archivo con un bit en especial, de manera
que ahora un nodo-i puede contener ya sea datos de un archivo o un nuevo directorio con una
estructura similar.
En la actualidad la mayoría de los sistemas operativos manejan nombres largos, con un
máximo de 255 caracteres para el nombre de un archivo. Para implementar esta facilidad, se
pueden utilizar también entradas de directorio fijas, pero esto implicaría un gran desperdicio de
almacenamiento puesto que no todos los archivos tendrían esa cantidad de caracteres.
Otra opción es utilizar un enfoque en el cual cada entrada de directorio tenga una parte
fija correspondiente a los atributos, fecha de creación y propietario. Otra parte variable que
corresponde al nombre del archivo que puede tener cualquier longitud de caracteres. El nombre
de archivo termina con el caracter nulo o NULL que está indicado por el valor 0 en la tabla de
caracteres ASCII. El problema con este enfoque es que cuando se borra una entrada de directorio
quedará entonces un hueco en donde posiblemente no haya espacio para la siguiente entrada de
directorio, pero existe la posibilidad de compactarlo, por estar la estructura de directorios en
memoria.
El último esquema de manejo de las entradas de directorio, es mediante el uso del heap.
Cada entrada de directorio cuenta entonces con un apuntador que indica el principio del nombre
del archivo en un lugar denominado montón o heap. El heap es un lugar en memoria en donde
se encuentran almacenados todos los nombres del archivo separados solamente por un caracter
especial. Comúnmente el caracter nulo o NULL que está indicado por el valor 0. De esta forma,
cuando se elimina un archivo, en la lista de directorios queda un hueco de tamaño variable en
donde tal vez no quepa la entrada del siguiente archivo, pero ahora sí es factible compactar
puesto que la lista de directorios se encuentra en memoria o en su defecto puede hacerse cuando
se apaga, se inicia el sistema o en momentos en donde la carga del sistema sea muy baja, por
ejemplo, en la noche.
Observe en el ejemplo de la figura 5.15 que el apuntador al nombre del archivo 1 contiene el
valor 0 lo que indica que el nombre empieza en la posición cero del montón. Observe también
que el el apuntador al nombre del archivo 2 contiene el valor de 30, lo que indica que ese
nombre empezará a partir de la posición treinta del montón. Recuerde también que los nombres
de archivo terminan con un caracter especial, en este caso sigue siendo el caracter cero, nulo o
NULL. representado por el símbolo de .
En todos los esquemas de manejo de directorios vistos hasta ahora, la búsqueda de nombres
se hace recorriendo toda la lista linealmente hasta encontrarlos. Un método más eficiente podría
ser el uso de tablas hash para acelerar la búsqueda. En una tabla hash se asigna un valor llamado
clave o llave que se calcula a partir del nombre del archivo. El cálculo puede realizarse convir-
Longitud de entrada
del archivo 1
Atributos del archivo 1
c o n t a b
i l i d a d
Entrada - - f i n a
para un n c i e r a
archivo - r e a l
Longitud de entrada
del archivo 2
v e n t a s
- d e l - m
e s
Longitud de entrada
del archivo 3
v e n t a
.
.
.
Figura 5.14: Estructura de directorios incorporados
tiendo los caracteres a sus valores ASCII y, por ejemplo, sumarlos y luego hacer una división
entre un número impar. La tabla consistirá entonces en n-1 entradas donde cada una contendrá
un nombre. Bajo este esquema es necesario manejar las colisiones. Una colisión sucede cuando
al calcular el valor llave de algún nombre éste ya ha sido ocupado por otro, por lo tanto, esa
posición no puede ser asignada al nuevo nombre. Una forma de solucionar este problema es me-
diante el uso de listas simplemente ligadas, de modo que si esa posición de la tabla está ocupada,
entonces se crea un nuevo nodo de lista y éste se liga a la posición ya ocupada. Esto permite que
siempre haya lugar en la lista no importando cuántas veces haya sido ocupada esa llave. Este
esquema combina la fortaleza de la búsqueda por llaves y una ligera búsqueda lineal dentro de
la lista simplemente ligada.
El problema de este enfoque es que si está mal diseñado el cálculo de las llaves entonces la
tabla hash puede degenerar en una sola o muy pocas listas simplemente ligadas perdiéndose las
Apuntador al
nombre de archivo 1 (00)
Entrada
para un
Apuntador al
archivo
nombre de archivo 2 (30)
c o n t a b
00
i l i d a d
06
- - f i n a
12
n c i e r a
18
- r e a l
24
30 v e n t a s
36 - d e l - m
42 e s v e n
48 t a
.
.
.
Figura 5.15: Uso de heap de entradas de directorio
ventajas de la tabla hash.
5.6.2. Servidor de archivos

Dentro de los servicios que proporciona un sistema operativo está el de proporcionar al
usuario los medios adecuados para poder hacer uso de sus archivos. Hasta ahora hemos tratado
solamente la forma de implementar el sistema de archivos analizando los enfoques más comu-
nes. En esta sección nos dedicaremos a otro aspecto muy importante sobre las distintas formas
de presentar al usuario los archivos con los que puede trabajar.
También ahora es común que no sólo los usuarios tengan acceso a un servidor de archivos,
si no que lo hagan directamente algunos programas de computadora como los navegadores que
necesitan acceder a información concerniente a la dirección en la que se encuentra almacenada
alguna página de internet.
Ahora pasaremos a una rápida explicación de un servidor de archivos.
Sobre las implementaciones de los sistemas de archivos a nivel de usuario, el sistema ope-
rativo debe de ser capaz de proporcionar diferentes formas de acceder a los archivos que han
sido guardados en el disco duro. Desde los comienzo de la computación ha sido necesario per-
mitir a un usuario acceder a sus archivos de forma remota vía terminal o por medio de otras
computadoras.
Un servidor de archivos entonces será aquella computadora que sea capaz de proporcionar
acceso a los archivos guardados en algún medio de almacenamiento masivo como un disco duro,
una cinta, un DVD o algún otro a uno o varios usuarios. Entonces en general podemos decir que
cualquier computadora es un servidor de archivos. Cuando las redes de computadoras personales
hicieron su aparición se modificó un poco esta definición. Se excluyen aquellas computadoras
que solamente dan servicio a un solo usuario y se reemplaza por aquellas que pueden propor-
cionar el servicio de archivos a más de un usuario a la vez. Aunque una computadora personal
puede proporcionar archivos a muchos usuarios, debe hacerlo de forma secuencial, éstos so-
lamente pueden usarla un usuario a la vez. Una computadora que es capaz de proporcionar el
servicio de archivos a más de un usuario al mismo tiempo se le denomina servidor de archivos
Actualmente se ha afinado aún más la clasificación de servidores de acuerdo al tipo de servicios
que manejan y podemos encontrar las siguientes:
1. Servidor de archivos. Proporciona servicios de archivos a usuarios de la red.
2. Servidor de Aplicaciones. Proporciona ejecución de aplicaciones locales o remotas a

usuarios de la red.
3. Servidor de bases de datos. Proporciona servicio de bases de datos.
4. Servidor de nombres de dominio. Llamado también DNS (Domain Names Server) Es

aquel que proporciona la traducción de un nombre de dominio, por ejemplo:
www.itapizaco.edu.mx
por su correspondiente dirección IP. Para el caso anterior correspondería a: 148.208.224.1.
5. Servidor de correo. Proporciona servicio de correo electrónico a sus usuarios ya sea local
o de red internet.
6. Servidor FTP. (File Transfer Protocol) Servidor de archivos en red.
7. Servidor de impresión. Proporciona servicios de impresión vía red local o remota.
8. Servidor de juegos. Permite que varios usuario se conecten vía red y compartan los mis-
mos escenarios de un juego, es posible hacer alianzas, comerciar, pagar tributos o inter-
cambiar recursos.
9. Servidor de noticias. Proporciona automáticamente las noticias actualizadas a sus usuario

suscritos.
10. Servidor proxy. Permite compartir la red internet a varios usuarios con una sola salida
a internet. Restringiendo o privilegiando a distintos usuarios de acuerdo a las pautas del
administrador.
11. Servidor telnet. Servicio de conexión de terminal en el servidor para la ejecución de

aplicaciones, tiene el problema de que envía las contraseñas sin cifrar de modo que pueden
ser “vistas” por terceros.
12. Servidor WEB. El servidor de páginas WEB proporciona los archivos en formato html
para que sean interpretados por el navegador WEB del usuario.
A continuación detallaremos un poco más aquellos que consideramos más importantes.
5.6.2.1. Servidor de archivos
Es aquella computadora que permite la conexión de varios usuarios permitiéndoles las ope-
raciones comunes de archivos. Es posible también que aplicaciones remotas hagan uso de los
archivos locales con los que cuenta el servidor. La mayoría de las veces no permite la ejecución
de aplicaciones en el servidor.
Una definición sencilla puede ser: un servidor de archivos es una computadora que almacena
diferentes tipos de archivos y los pone a disposición de varios clientes de la red simultáneamente.
Básicamente cualquier servidor puede funcionar como servidor de archivos.
Algunos protocolos que suelen utilizarse en servidores de archivos son:
1. NETBEUI. Protocolo usado por MS-DOS y Windows para compartir archivos vía red.
2. NetWare IPX/PSX. Protocolo usado por Novell para compartir archivos en la red.
3. SMB/CIFS. Protocolo de sistemas de archivos de red para Windows.
4. Samba. Usado por Unix/Linux para compartir información con Windows.
5. NFS. network File System.
6. TCP/IP. (Transfer Control Protocol/Internet Protocol). Es el protocolo de la red por exce-

lencia y va ganando terreno frente a los otros convirtiéndose poco a poco en el estandard
de redes de computadoras. Bajo este protocolo pueden encapsularse varios de los mencio-
nados en los puntos anteriores, haciéndoles fácilmente compatibles. Esto se hace mediante
una técnica conocida como túnel que permite empaquetar esos protocolos en datagramas
de tipo TCP/IP.
Existen varios protocolos más de comunicación que pueden encontrarse en la literatura de

redes de computadoras.
5.6.2.2. Servidor de aplicaciones
Es una especialización de los servidores de archivos. La diferencia radica en que el sistema

operativo proporciona archivos ejecutables para que el usuario pueda hacer sus tareas. La ejecu-
ción puede ser ya sea local o remota. La mayoría de las veces el servicio se complementa con el
servidor de archivos de modo que el usuario puede ejecutar la aplicación en el servidor mismo
haciendo uso de los archivos que están también en éste. (Application server). Tipo de servidor
que permite el procesamiento de datos de una aplicación de cliente.
Las principales ventajas de la tecnología de los servidores de aplicaciones es la centralización
y la disminución de la complejidad del desarrollo de aplicaciones, dado que las aplicaciones no
necesitan ser programadas; en su lugar, estas son ensambladas desde utilerías que se encuentran
en el servidor de aplicaciones.
Aunque es aplicable a todas las plataformas, actualmente el término es prácticamente un
sinónimo de la plataforma J2EE de Sun Microsystems. De todas maneras, abarca servidores
de aplicaciones basadas en web, como plataformas para el comercio electrónico, sistemas de
administración de contenido o creadores de sitios web.
Ventajas de los servidores de aplicaciones.
1. Integridad de la información y código de programas. Al haber administración centra-

lizada en una o pocas computadoras, las actualizaciones se efectúan de manera rápida y
estarán disponibles automáticamente para todos los usuarios del sistema. No hay riesgos
de mezcla de versiones antiguas con nuevas. El código no puede ser alterado por terceros.
Los datos al estar centralizados se actualizan en un solo lugar proporcionando información
actualizada a todos los usuarios.
2. Administración centralizada. Los cambios realizados en los archivos de configuración

de las aplicaciones se reflejarán inmediatamente a todos los usuarios, de manera que no se
necesita recorrer toda el área de una empresa para realizar los cambios.
3. Seguridad. Para poder acceder al servidor el usuario debe de autenticarse. Además las
aplicaciones las proporciona el propio servidor haciendo uso de certificados para poder
autorizar su ejecución o uso de los archivos de datos del sistema, por lo tanto se consideran
más seguras.
4. Desempeño. Al limitar el tráfico de la red solamente a la visualización de resultados,

bajo el modelo cliente/servidor el usuario solamente enviará sus consultas y recibirá sus
resultados siendo éstos calculados por el servidor logrando así un excelente desempeño
de grandes aplicaciones.
5.6.2.3. Servidor de bases de datos
Un servidor de base de datos es un caso particular de un servidor de archivos. Es un programa

que provee servicios de base de datos a otros programas u otras computadoras, basándose en el
modelo cliente-servidor. Puede hacer referencia a aquellas computadoras dedicadas a ejecutar
los programas llamados manejadores de bases de datos. Esto es, proporciona los mecanismos de
acceso es un manejador de bases de datos que se ejecuta sobre las funciones básicas del servidor
de archivos. El acceso puede ser local o remoto.
Los sistemas de administración de base de datos (SGBD) generalmente proveen funcionali-
dades para servidores de base de datos, en cambio otros (como por ejemplo, MySQL) solamente
proveen construcción y acceso a la base de datos.
5.6.2.4. Servidor de páginas WEB
Es un servidor que proporciona servicios concernientes a la WWW. Existen dos tipos:

1. Sitios de Intranets. Son aquellos sitios WEB diseñados exclusivamente para el flujo de
información corporativa dentro de una empresa.
2. Sitios de Internet. Son aquellos que se encuentran disponibles para todo el mundo, siendo
necesario contar con al menos un servidor de nombres de dominio, un servidor de páginas
WEB y un servidor de correo electrónico opcional.
Se deben tener al menos una computadora con conexión a internet, y se debe contar con un
conjunto de programas básicos para dar servicio WEB. Existen básicamente dos tipos de páginas
WEB que se manejan actualmente:
Páginas estáticas. Las páginas estáticas son aquellas que se diseñan una sola vez y que
son actualizadas manualmente.
Páginas dinámicas. Son aquellas generadas vía algún lenguaje de programación WEB
como PHP o java en combinación con manejadores de bases de datos, lo que permite la
actualización dinámica o en tiempo real de las mismas.
5.6.3. Seguridad en los archivos
La seguridad de los archivos se refiere tanto al hecho de impedir que personas no autorizadas
accedan a su información como a posibles desastres que inutilicen al sistema de archivos. La
destrucción de un archivo, es problemático. La destrucción de todo el sistema de archivos es
un desastre. Incluso si se daña la computadora, ésta puede reemplazarse sin muchos problemas.
Pero cuando se daña el sistema de archivos, hay muy poco por hacer. Es posible también intentar
recuperar la tarjeta de interfaz del disco duro siempre y cuando los platos magnéticos no tengan
problema.
Si se pierde en forma definitiva el sistema de archivos, independientemente de fallo del

hardware o por algún problema de software, la recuperación de la información será un proceso
muy largo, difícil y muchas de las veces será imposible. La pérdida de información es algo que
debe de enfrentar todo profesionista que use una computadora.
Aunque el sistema de archivos no podrá nunca prever desastres naturales o daños imprevistos
del hardware, sí puede ayudar a proteger la información de diversas maneras.
Los discos flexibles pasan el control de calidad sin mucho problema, pero a través del uso
y debido a que las cabezas de lectura escritura tienen contacto físico con la superficie, si éstas
bajan un poco más de lo debido pueden causar rayaduras en su superficie. Incluso, si el propio
empaque del disco baja por causa de un golpe o por haber soportado un peso excesivo, puede
causar también rayaduras que dañen a uno o más sectores.
Es posible también que bajo la presencia de un campo relativamente débil, durante mucho
tiempo podría ocasionar la pérdida de algunos sectores o de todo el sistema de archivos conte-
nido en éste.
Se sabe que ha habido discos que han soportado mucho peso y campos magnéticos intensos,
pero cuando se trata de información importante, no está demás considerar un cuidado adecuado
con sentido común de los discos.
Los discos duros, tienen un promedio de vida que va de los cuatro a los cinco años sin pre-
sentar algún problema. Algunos durarán mucho más. No obstante, aunque nuestro disco duro no
reciba golpes, puede, por el uso continuo empezar a presentar problemas de lectura o escritura.
Aunque el controlador de disco puede manejar los sectores defectuosos o marcarlos para
que no se usen, existen otras técnicas que se pueden emplear para mantener segura nuestra
información. En la siguiente sección mencionaremos algunos mecanismos de protección que
todo profesionista de la información debe de conocer.
5.6.3.1. Seguridad en el acceso a los archivos y directorios
Actualmente es una necesidad la protección de la información para impedir que personas no

autorizadas accedan a información privilegiada.
El sistema operativo debe proporcionar los mecanismos básicos que permitan asegurarse que
los archivos deben ser leídos solamente por aquella persona que lo creó y por los que hayan sido
autorizados expresamente por el propietario.
En los sistemas basados en UNIX y en GNU/linux, la seguridad en el acceso a los archivos
está implementada mediante el uso de tres campos en la entrada de directorio bajo la siguiente
estructura:
1. El primer campo define los permisos de acceso del propietario del archivo o directorio.
Por omisión tiene los permisos de lectura, escritura y ejecución o acceso al directorio.
2. El segundo campo define los permisos de grupo. Estos los puede definir, ya sea el propie-
tario del archivo o en su defecto el administrador del sistema.
3. El tercer campo define los permisos de todo el mundo. Esto es, cualquier persona que tenga
contacto con el archivo o directorio puedeejercer los permisos que tenga esta sección.
En la tabla 5.2 vemos cómo están definidos.
drwxr-xr-x 2 nalonzo nalonzo 4.0K 2008-01-18 06:47 figuras

-rwxr-xr-x 1 nalonzo nalonzo 154K 2008-01-21 06:22 introduccionSO.tex
-rwxr-xr-x 1 nalonzo nalonzo 17K 2008-01-21 18:01 introduccion.tex
-rw-r–r– 1 nalonzo nalonzo 80K 2001-05-20 16:12 LETRACD.GIF
-rw-r–r– 1 nalonzo nalonzo 16K 2001-05-20 15:52 PART1.GIF
-rw-r–r– 1 nalonzo nalonzo 821 2008-01-15 09:12 portada.tex
Tabla 5.2: Una entrada de directorio tradicional de UNIX, GNU/Linux
La primera columna establece los permisos y está dividida en cuatro partes. La primera
indica el tipo de entrada. por ejemplo, para la primera línea tenemos que es una entrada de
directorio. Luego vienen tres grupos escritos de la forma rwx. El guión significa que no se tiene
asignado ese permiso. La siguiente columna indica el número de enlaces que tiene, luego el
nombre del propietario, el del grupo al que pertenece, el tamaño (en bytes), una marca de tiempo,
y el nombre del archivo. La marca de tiempo que se visualiza es la de la última modificación.
Para archivos especiales de dispositivo el campo de tamaño se reemplaza normalmente por los
números de dispositivo mayor y menor.
El significado de las rwx es el siguiente:
1. r. Se tiene permiso de lectura sobre el archivo o directorio.
2. w. Se tiene permiso de escritura sobre el archivo directorio.
3. x. Tiene dos significados:
Si es un archivo, indica que éste se puede ejecutar.
Si es un directorio, indica que se tiene permiso para entrar a él y mostrar sus conte-
nidos.
En un sistema basado en Windows o en un entorno gráfico de UNIX, GNU/Linux, los permi-

sos se pueden modificar abriendo el menú secundario de un archivo o directorio (normalmente,
se selecciona y se da click derecho), entrar en la opción de propiedades y de ahí a la pestaña o
al botón de permisos.
En ambos sistemas se tiene una opción para ocultar los archivos. En los sistemas basados
en UNIX, los nombres de archivos empiezan con un punto. En los basados en Windows existe
como un atributo. A nivel consola, en UNÍX, GNU/Linx tenemos las órdenes chmod y chown
que permiten cambiar atributos y propietario. En Windows tenemos la orden attrib.
La otra opción para el control de accesos es mediante las ACL(Access Control List) o listas
de control de acceso. Con el esquema anterior es difícil y a veces imposible lograr todas las
exigencias de permisos requeridos por varios usuarios sobre un mismo directorio o archivo. Las
listas de control de acceso permiten un control extremadamente flexible, permitiendo asignar
todos los permisos mencionados anteriormente, incluso, se pueden determinar fechas y horas de
acceso específicas a las que puede acceder al archivo o directorio un usuario dado.
Tanto los sistemas basados en UNIX como los basados en windows a partir de windows NT
con NTFS implementan esta facilidad.
Las ACL no pueden ser usadas en los sistemas windows que hagan uso del sistema de archi-
vos FAT16 o FAT32, por que no están diseñadas para este propósito. Esto significa que cualquier
usuario que tenga acceso a la computadora podrá leer sin ningún problema cualquier tipo de in-
formación que se encuentre en esa computadora. Por lo tanto, si se cuenta con información que
debe ser exclusiva de algún usuario, lo mejor es hacer uso de un sistema de archivos que las
soporte, de otra forma debe de utilizarse algún mecanismo de incriptación de ello hablaremos
en la sección 6.7 en la página 345.
5.7. Modelo jerárquico

Hasta ahora nos hemos dedicado a analizar los tipos de archivos. A partir de este momento
trataremos lo concerniente a los directorios. Un directorio es un archivo especial que permite
mantener una agrupación lógica de archivos o directorios que están relacionados o que tienen
algo en común. por ejemplo, un usuario puede crear un directorio con su nombre y ubicar ahí los
archivos de uso personal. A su vez dentro de este directorio puede crear otros para clasificar sus
vídeos, sus fotos, los archivos de texto y sus archivos de música, de manera que sea más fácil
encontrar aquella información que requiere de una forma más rápida.
Los directorios pueden implementarse de varias formas. Dentro de éstas tenemos las siguien-
tes.
Directorios de un solo nivel. Es la forma más sencilla de guardar los archivos. También se
le conoce como directorio raíz, pero como es el único, el nombre no importa. Cuando
empezaron a surgir las primeras computadoras personales era común este tipo de organi-
zación, debido a que los discos eran de poca capacidad y por que la mayoría de las veces
solamente podía trabajar olamente un usuario. Si la computadora se compartía entonces
cada usuario portaba su información en un disco flexible e incluso transportaba también
su propio sistema operativo de disco. También existieron computadoras multiusuario que
utilizaron este tipo de estructura de directorio. por ejemplo, la primer supercomputadora la
CDC 6600, tenía solamente un directorio que compartían todos los usuarios. El problema
de usar un solo directorio es que es posible que varios usuarios intenten usar un mismo
nombre para archivos diferentes causando incluso pérdida de información al sobreescribir
un archivo existente de forma accidental. También otro problema inherente es la poca or-
ganización del sistema de archivos. Con el tiempo se vuelve difícil y complicado navegar
a través de muchos archivos que no tienen que ver con los que realmente usa algún usuario
determinado. Por estas y otras razones actualmente ya no se usan.
Directorios de dos niveles. Mediante el uso de esta organización de directorios, no importa que
varios usuarios escojan el mismo nombre para diferentes archivos. Estos son identidades
diferentes por el simple hecho de estar almacenados en directorios distintos. De esta for-
ma proporcionando a los usuarios directorios privados, el usuario es libre de asignar los
nombres que desee sin preocuparse por los demás usuarios. Bajo Este esquema, tendremos
entonces el directorio raíz, después tendremos los directorios privados de los usuarios y
dentro de ellos los archivos de cada uno.
Sistemas de directorios jerárquicos. Es la organización que usan la mayoría de los sistemas

operativos actuales. En esta tenemos a nuestro directorio raíz, después tenemos los direc-
296 5.7. MODELO JERÁRQUICO
torios privados de los usuarios y éstos también tienen el permiso de crear a su vez tantos
subdirectorios como crean necesario para organizar sus archivos. De esta manera se crea
un árbol de directorios y el sistema operativo proporciona un conjunto de órdenes para
poder navegar a través de ellos, basándose también en los permisos adecuados de acceso.
Figura 5.16: Ejemplo de directorio tipo árbol
Cuando el sistema de archivos está organizado como árbol de directorios, es posible acceder
a diferentes archivos, ya sea entrando primeramente a cada uno de ellos, o haciendo uso de la
ruta completa para referenciar el archivo. A esta ruta se le denomina nombre de ruta. El nombre
de ruta especifica a qué directorios se deben de acceder primeramente para poder hacer uso de
un archivo. El nombre del archivo va al final del nombre de ruta. Los sistemas UNIX/Linux
utilizan la “/” como separador de directorios y de archivo. Los sistemas basados en Windows
usan la barra invertida \ para esa función. La ruta absoluta se especifica a partir del directorio
raíz. En la tabla 5.3 tenemos algunos ejemplos de rutas absolutas.
Windows \sistemas\vídeo
UNIX/Linux /home/nalonzo/sistemas
MULTICS >usr>datos
Tabla 5.3: Rutas absolutas en UNIX/Linux, Windows y MULTICS
Observe cómo éstas se especifican desde el directorio raíz, esto significa que deberán empe-
zar, por ejemplo en windows con un \ y en UNIX/Linux con una /.
Las rutas relativas son aquellas que no llevan al principio el \ o la /. Esto hará que el sistema
operativo empiece a buscar en el directorio actual el nombre del directorio o el archivo que se
desea. En la tabla 5.4 tenemos algunos ejemplos de rutas relativas.
La ruta relativa también está relacionado con el concepto de directorio de trabajo o direc-
torio actual. El usuario puede especificar tanto para el sistema operativo como para la mayoría
Windows documentos\datos
UNIX/Linux documentos/dato
Tabla 5.4: Ejemplos de rutas relativas
de las aplicaciones en qué directorio desea que se ubique después de que éstas empiezan a eje-
cutarse.
Vamos a suponer que tenemos un archivo llamado datos en el directorio /home/documentos,
De acuerdo a lo visto anteriormente tenemos dos maneras de hacer referencia a éste:
Mediante ruta absoluta: less /documentos/datos
Mediante ruta relativa:
• cd /documentos
• less datos
Observe que cuando usamos la ruta relativa ha sido necesario ubicarse primeramente en el
directorio documentos el directorio actual o directorio de trabajo. Después de esto se puede
acceder al archivo sin la ruta.
La mayoría de los sistemas operativos actuales permiten establecer rutas por omisión, de ma-
nera que si se hace referencia relativa a un programa o a un archivo, el sistema empieza a buscar
en el directorio de trabajo o directorio actual. Si no lo encuentra empezará entonces a buscar en
las rutas establecidas por defecto. Es común que estas rutas por defecto estén almacenadas en las
variables de entorno. Muchas aplicaciones establecen variables de entorno de manera que pue-
dan localizar los archivos necesarios para su ejecución. Una variable de entorno es aquella que
se inicializa desde un archivo de configuración momentos después de que se inicia el sistema
operativo o que puede ser definida por el usuario en tiempo de ejecución.
Existen dos nombres de directorios especiales que son muy útiles para hacer referencia a
otros directorios. Estos son el nombre de directorio “.” y el nombre de directorio “..”, llamados
directorio “punto” y directorio “punto punto”. El directorio “.” hace referencia al directorio de
trabajo actual. y el directorio “..” hace referencia al nombre del directorio padre. De esta forma
si estamos haciendo uso de la orden “cd” Change Directory y deseamos subir al directorio padre
tenemos que ejecutar la instrucción.
cd ..
si se ejecuta la instrucción
cd . el sistema operativo no hará nada(estamos en el directorio actual).
298 5.7. MODELO JERÁRQUICO
En los sistemas UNIX/Linux para regresar inmediatamente al directorio de trabajo por de-
fecto se usa la orden cd sin ningún parámetro.
Operaciones con directorios Las operaciones más comunes que podemos realizar sobre los
directorios son las siguientes:
1. Crear. Se crea un directorio vacío. Automáticamente se crean dentro de él los nombre de

directorio especiales de “.” y “punto punto” Un directorio que solamente contiene estos
directorios se considera vacío.
2. Borrar. Permite eliminar un directorio. El directorio debe de estar vacío o en su defecto

algunos sistemas solicitan un parámetro adicional para asegurarse de que eso es lo que
quiere en realidad el usuario.
3. Abrir directorio. Se comentó que un directorio es un caso especial de archivo, por lo

tanto, también es posible abrir un directorio y leerlo el resultado será todos los nombres
de archivo y directorios que contenga.
4. Cerrar directorio. Una vez que se ha leído un directorio, éste debe cerrarse, puesto que
es un caso especial de archivo . Esto permite guardar los cambios hechos en la estructura
de directorios a disco y lleguen a ser permanentes.
5. Leer directorio. Una llamada de este tipo devuelve la siguiente entrada de un directorio
abierto.
6. Renombrar directorio. Esta operación permite cambiar el nombre al directorio, como a

cualquier otro archivo normal.
7. Enlace de directorio. Esta operación permite a un archivo o a un directorio aparecer en

más de un directorio, sin duplicar la información, esto se hace comúnmente incrementando
el nodo-i correspondiente al archivo o directorio para indicar al sistema operativo que éste
se encuentra en otro lado además de su ubicación normal. Hay que observar nuevamente
que en “el otro lado” solamente se encuentra el nombre del archivo. El enlace permite
acceder a él como si realmente fuera un archivo local.
8. Desligar. Esta operación permite eliminar la entrada del archivo del directorio donde se
encuentra. En general esta operación solamente eliminará la entrada de directorio corres-
pondiente. Si existe más de una instancia o enlaces al archivo, se decrementará el contador
de nodo-i (específico de UNIX) y se eliminará la entrada de directorio correspondiente, las
demás entradas permanecerán hasta el contador de nodo-i llegue a cero. En ese momento
el archivo o directorio quedará eliminado de disco.
Existen otras operaciones relacionadas con los permisos asociados a cada directorio, inclu-
yendo las listas de acceso y los permisos de lectura escritura a los mismos.
5.8. Mecanismos de recuperación en caso de falla
Regresando a los mecanismos de protección el primero que mencionaremos se refiere a

las copias de protección. La mayoría de las personas piensa que a ellos no les va a pasar y
confían en su buena suerte. Además también consideran que respaldar no vale tanto la pena
debido al tiempo que se debe dedicar para hacer la tarea, muchas veces debido también a que los
archivos se van actualizando continuamente, lo que implica una gran pérdida de tiempo si este
respaldo se hace manualmente. Tampoco consideran necesario usar una herramienta automática
por que manejan relativamente poca información. Cuando el disco duro falla de repente, es
donde empiezan una búsqueda desesperada de profesionales que ayuden a la recuperación de su
información. En esos momentos se dan cuenta que el “rescate” de la información salió mucho
más caro que si hubieran tenido un disco duro de respaldo, si es que lograron recuperarla. De otra
forma, también los costos son elevados desde el punto de vista productivo: rehacer un proyecto,
la contabilidad de todo el año o el pago de multas por no haber entregado a tiempo el trabajo.
Las compañías dan un mayor valor a sus datos y es común que tengan toda una política de
respaldo de información. en general pueden manejar respaldos, diarios, semanales, mensuales e
incluso anuales o más Hacen también uso de aplicaciones que permiten realizar los respaldos en
cinta de forma automática, usando una técnica llamada respaldo incremental. Con esta técnica
se reduce el tiempo de respaldo debido a que solamente se respaldan aquellos archivos que han
modificados. El problema con esta técnica es que la fecha debe estar siempre bien establecida.
aunque la mayoría de las veces el usuario será advertido sobre el hecho de sobreescribir un
archivo más antiguo sobre uno más actualizado. Además de acuerdo a la política de respaldo
incremental, esta situación no actualizaría la información en el respaldo. Para evitar un caso de
este tipo, el servidor se conecta con otras computadoras o servidores de reloj y verifican que la
fecha sea acorde al mismo.
Los medios más comunes de respaldo son las cintas, cuya relación precio/megabyte ronda
alrededor de unos cuantos pesos. Como se puede ver, el hacer respaldos no es tan trivial como
parece.
300 5.8. MECANISMOS DE RECUPERACIÓN EN CASO DE FALLA
5.8.1. Implementación
La implementación de los mecanismos de protección van orientados hacia la prevención de
la pérdida de información y también hacia la pérdida o borrado involuntario o accidental de
archivos. Los mecanismos de protección son los siguientes:
1. Copia de seguridad de las aplicaciones. La mayoría de las aplicaciones llevan dos ar-
chivos paralelamente y con unos cuantos minutos de variación que son elegidos por el
usuario. De esta forma, si se pierde el archivo principal, el usuario tendrá que recuperar
solamente la información capturada durante ese lapso de tiempo.
2. Copias por el sistema operativo. Este mecanismo es muy usual en muchos sistemas
operativos. Cuando un usuario borra un archivo, éste no se borra en realidad, si no que
pasa a un directorio conocido como papelera de reciclaje de esta forma, si el usuario
borró accidentalmente ese archivo podrá recuperarlo inmediatamente restaurándolo de la
papelera. Cabe hacer mención que los archivos que se encuentran en la papelera no podrá
ser usados como archivos normales hasta que no se restauren.
3. Copias de respaldo El problema de hacer respaldos de información no es trivial. Anali-

cemos primero aquellos archivos que es necesario respaldar. Empecemos por los archivos
binarios o ejecutables. No es necesario respaldarlos debido a que pueden volver a ins-
talarse a partir del CD-ROM original. La mayoría de las veces, ni siquiera es necesario
respaldar el sistema operativo, puesto que también es susceptible de ser instalado desde el
medio original. Puede deducirse entonces que solamente deben respaldarse algunos direc-
torios específicos junto con todo su contenido y no respaldar todo el sistema de archivos.
También dentro de estos directorios a respaldar existen directorios o archivos que jamás
sufren modificaciones como por ejemplo algunos archivos de ayuda o ciertas bases de da-
tos de consulta que se actualizan solamente en periodos relativamente largos de tiempo y
que es muy probable que al momento de hacer el respaldo no hayan sufrido modificación
alguna. A partir de esto llegamos a la idea de respaldos incrementales. El método más
común de respaldo incremental es hacer un respaldo completo en forma periódica, por
ejemplo cada mes y entonces hacer un respaldo cada semana de solamente aquellos archi-
vos que se han modificado y sobre éste, hacer un respaldo diario que se hace solamente de
aquellos archivos que sufren modificaciones diarias. Lo mejor sería hacer un respaldo de
solamente aquellos archivos que han sido modificados desde la última vez que se hizo el
respaldo. Esto reduce drásticamente el tiempo de respaldo. No obstante, el precio a pagar
es que dificulta la recuperación de la información: primero es necesario restaurar el últi-
mo respaldo completo, luego todos los respaldos semanales en orden inverso y por último
también los respaldos diarios, de nuevo en orden inverso. Es normal que se usen esquemas
de respaldo incremental más elaborados para facilitar la recuperación.
4. Respaldos comprimidos. Debido a que casi siempre se respaldan grandes cantidades de

información, es buena idea comprimirlos antes de escribirlos en cinta. Sin embargo, se
corre el riesgo de que una vez comprimidos, un pequeño error dentro del archivo en cinta
interfiera en el algoritmo de descomprensión e impedir la lectura de todo el archivo o
incluso de toda la cinta. Por ello, si se va a respaldar los datos en forma comprimida, debe
de analizarse cuidadosamente si es absolutamente necesario. Es común también hacer dos
respaldos para asegurarse de que no vaya a suceder esta situación, habiendo comprobado
previamente que el archivo es perfectamente descomprimible.
La mayoría de los sistemas de archivos no permiten respaldar archivos que estén siendo
usados actualmente. También si se llegara a permitir esta situación bajo las circunstancia de
que el archivo esté siendo usado en modo de solo lectura, puede ser posible que un minuto o
segundos después cambie su modo a escritura, lo que hace que el respaldo realizado no será
consistente con respecto al archivo original. Esto obliga entonces a dedicar completamente el
sistema de archivos a la operación de respaldo, lo que implica dejar de usar el sistema. Pero un
respaldo de mucha información puede tardar más de una hora, dependiendo de la cantidad de
información, lo que lo hace complicado, puesto que tendría que dejar el sistema fuera de línea
durante parte de la noche.
La creación de respaldos, como se ve, presenta muchos problemas no técnicos en una orga-
nización. El mejor sistema de manejos de respaldos en línea del mundo podría ser inútil si el
administrador de sistemas guarda todas las cintas de respaldo en el sótano, junto con materiales
inflamables o que puede ser susceptible a inundaciones, incluso a ser destruidas por roedores.
Además el hacer un respaldo diario, no sirve de mucho si las cintas se encuentran en el mismo
edificio u oficina y el incendio, además de acabar con las computadoras, termina también con
las cintas de respaldo. Lo recomendable es tener también otro paquete de cintas de respaldo en
otro edificio, aunque esto también sea un problema potencial de seguridad frente al espionaje o
robo de información.
Existen dos formas de realizar los respaldos de un disco en cinta.
1. Respaldo físico. Permite hace una copia exacta bloque por bloque del disco. El programa
lo que hace es copiar a nivel de bloque todo el disco, uno a uno registrando también la
posición a la que corresponde cada uno de ellos. La principal ventaja que ofrece es que es
posible eliminar casi por completo los posibles errores de copiado, incluso si un bloque
está dañado, la aplicación avisará y además solamente afectará al archivo o directorio
302 5.9. PROBLEMAS
involucrado, siendo posible también que el administrador resuelva el problema antes de

seguir con el respaldo. El problema principal es que también almacenará bloques vacíos
lo que implica gran pérdida de espacio en cinta. No tiene caso almacenar bloques vacíos.
Esta técnica se usa solamente para sistemas de archivos pequeños.
2. Respaldo lógico. Comienza en uno o más directorios específicos y respalda en forma

recursiva todos los archivos y directorios que se encuentren en ellos y que hayan sido
modificados a partir de una fecha dada. Este tipo de respaldo es el más común. Bajo
este enfoque se guarda también la estructura de directorios que está arriba de un archivo
modificado para permitir su restauración en el lugar correcto.
5.8.2. Consistencia del sistema de archivos

Hasta ahora hemos tratado de forma general los métodos de respaldo para recuperar algunos
archivos o directorios completos del sistema de archivos. Cuando el sistema de archivos lee un
bloque de disco y lo coloca en memoria, realiza modificaciones y entonces tiene que regresarlo
a disco. Si ocurre una falla antes de que se escriban los bloques modificados a disco, se dice
entonces que el sistema de archivos presenta inconsistencias.
En muchas ocasiones, el sistema operativo verificará al momento de iniciar que por ejemplo,
el tamaño registrado en la entrada de directorio coincida con el número de nodos-i asignados. Si
esto no sucede entonces obligará al administrador a hacer una verificación completa del sistema
de archivos para eliminar inconsistencias. Todos los sistemas operativos tiene un paquete de
utilerías para asegurarse de que el sistema de archivos está libre de inconsistencias y la mayoría
de las veces intentará resolverlas por sí mismo. En UNIX/Linux, esta utilería se llama fsck y en
Windows tenemos a scandisk.
Los sistemas operativos ejecutan estas utilerías comúnmente después de una caída del siste-
ma para verificar el estado del sistema de archivos.
5.9. Problemas
5.1. ¿Por qué es necesario el uso de archivos?
5.2. ¿Qué ventajas proporciona hacer uso de dispositivos de almacenamiento masivo?
5.3. ¿Cuál es la estructura de datos utilizada para guardar información en disco?
5.4. ¿Qué información mantiene la estructura de datos de tipo archivo?

5.5. Explique las operaciones que pueden hacerse sobre un archivo.
5.6. ¿Cuáles son las dos principales formas de acceso a archivos que proporciona un sistema
operativo?
5.7. Enumere los tipos de datos presentes en un lenguaje de programación.
5.8. Dibuje un diagrama que represente la jerarquía de los tipos de datos.
5.9. ¿Qué es una estructura?
5.10. ¿Qué es un objeto?
5.11. ¿Cuál es la principal diferencia entre una estructura y un objeto?
5.12. ¿Cómo se forma un nombre de archivo en MS-DOS?
5.13. ¿Cómo se forma un nombre de archivo en UNIX/Linuxen Windows 2000?
5.14. Describa ocho extensiones comunes de archivos.
5.15. ¿Cuáles son los tipos de archivos manejados por UNIX/Linux?
5.16. ¿Cuáles son los archivos normales?
5.17. ¿Qué es un archivo de texto?
5.18. ¿Qué es un archivo binario?
5.19. ¿Un archivo binario es necesariamente ejecutable? Explique su respuesta.
5.20. ¿Cómo se presenta el sistema de archivos al usuario?
5.21. ¿Cuáles son los métodos de acceso a los dispositivos de almacenamiento masivo? Ex-
plíquelos.
5.22. ¿Qué es un archivo de índice?
5.23. ¿Qué es un directorio o carpeta?
5.24. ¿Cuál es el directorio raíz?
5.25. Explique la estructura de directorios jerárquicos.
5.26. ¿A qué nos referimos con una ruta relativa?, ¿Y con una absoluta?
304 5.9. PROBLEMAS
5.27. ¿Qué es una ruta por omisión o por defecto?
5.28. ¿Cuál es el concepto de una variable de entorno?
5.29. ¿Cuál es el significado de los directorios “.” y “..”?
5.30. ¿Cuáles son las operaciones con directorios?
5.31. ¿En qué partes puede dividirse un disco?
5.32. Explique la estrategia de asignación contigua de bloques para un archivo.
5.33. Explique la estrategia de asignación por lista ligada de bloques para un archivo.
5.34. Explique la estrategia de almacenamiento por medio de la tabla de asignación de archi-

vos.
5.35. Explique la estrategia de almacenamiento por medio de nodos-i para el almacenamiento

de archivos.
5.36. ¿Cómo se almacenan los nombres largos?, ¿Qué estructuras de datos se utilizan?
5.37. ¿Cómo se manejan las colisiones en una tabla hash?
5.38. ¿Qué es un servidor de archivos?
5.39. ¿Cuáles son las diferentes servicios que se derivan de un servidor de archivos? Explique
cada uno de ellos.
5.40. ¿Cuáles son los protocolos de red más comunes? Explique cada uno de ellos.
5.41. ¿Qué es un servidor de aplicaciones?
5.42. ¿Qué ventajas proporciona un servidor de aplicaciones?
5.43. Proporcione una definición de un servidor de bases de datos.
5.44. ¿Cuál es la tarea de un servidor de páginas WEB?
5.45. ¿A qué se refiere la seguridad de archivos?
5.46. ¿Cual es el tiempo de vida útil de un disco duro?
5.47. ¿Qué deben proporcionar los mecanismos básicos de seguridad de un sistema operati-
vo?
5.48. ¿Como implementa UNIX/Linux el mecanismo de seguridad básico para el acceso a

directorios y archivos?
5.49. ¿Cuál es el significado de las abreviaturas rwx en una entrada de archivo?, ¿Y en una
entrada de directorio?
5.50. ¿Qué órdenes se ocupan para la manipulación de permisos y propietarios?
5.51. ¿Qué significa ACL?, ¿Para que sirven?
5.52. ¿Para qué se implementan los mecanismos de protección?
5.53. ¿Cuál es el mecanismo de protección más básico e importante en un sistema de archi-

vos?
5.54. ¿Cómo se lleva a cabo un respaldo incremental?
5.55. ¿Cuál es la estrategia más común que usan las aplicaciones para prevenir pérdidas
accidentales de algún archivo?
5.56. Explique para qué sirve la papelera de reciclaje.
5.57. Haga un análisis sobre aquella información que debe ser respaldada en un sistema de
computadora y cuál no.
5.58. ¿Qué es un respaldo comprimido?
5.59. Explique cómo se lleva a cabo un respaldo físico.
5.60. Explique cómo se lleva a cabo un respaldo lógico.
5.61. Explique a qué se refiere el concepto de consistencia del sistema de archivos.
5.62. ¿Para que se usan las llamadas al sistema?
5.63. ¿Qué funciones contiene la interfaz de la biblioteca estándar?
5.64. Describa de forma general la declaración de las funciones de manejo de archivos.
5.65. ¿Qué significa EOF?
5.66. ¿Qué funciones de la biblioteca estándar se usan para la entrada/salida de caracteres?
5.67. Explique los tres tipos de interfaz que proporciona el sistema operativo a sus usuarios.
5.68. Explique los tres pasos para poder trabajar en un sistema operativo en modo consola.
5.69. ¿Cuáles son las órdenes más comunes que se utilizan en una sesión de usuario en modo
consola?
5.70. Explique cómo se inicia sesión en una interfaz gráfica.
5.71. ¿Bajo qué forma entrega el sistema operativo la interfaz correspondiente a los progra-
madores?
5.72. ¿Qué es un intérprete de órdenes?
5.73. En un sistema UNIX/Linux, ¿Cuál es el símbolo que se utiliza para usuarios normales?,
¿Y para el administrador?
5.74. ¿Qué tareas realiza el intérprete de órdenes?
5.75. ¿Por qué hay que saber utilizar el intérprete de órdenes?
5.76. Describa el proceso para ejecutar un intérprete de órdenes.
5.77. ¿En cuál archivo se guarda la contraseña cifrada?
5.78. Describa los tipos de shells que ofrece UNIX/Linux.
5.79. ¿Qué es una tubería?
5.80. ¿Cuál es la función de una tubería?
5.81. Defina el redireccionamiento de entrada/salida.
5.82. ¿Qué diferencia existe entre una tubería y el redireccionamiento de entrada/salida?

En el libro de Francisco Manuel Márquez[72] se explica detalladamente el sistema de archi-
vos en UNIX.
McKusick[68] y su equipo explican cómo implementar un sistema de archivos rápido para
UNIX. Sandberg[91] a su vez detalla el diseño e implementación del sistema de archivos de red
de Sun y relata su experiencia en [90]. Rosenblum y Ousterhout[86] diseñan e implementan un
sistema de archivos denominado sistema de archivos estructurado por registros.
Tweedie[104] entra con cierto detalle en el sistema de archivos ext2fs de Linux.
Los sistemas RAID permiten unir dos o más discos para verlos como uno solo. Existen dife-
rentes niveles (denominados niveles RAID) que indican la forma de implementar la distribución
de los datos en los discos. Holland[49] describe una herramienta para sistemas RAID, mientras
que Chen y Petterson[27] describen una técnica para maximizar el desempeño en arreglos de
discos divididos.
Diane Tang[102] realiza una evaluación de desempeño de algunos sistemas de archivos.
También S. Chen y Towsley[28] realizan otras medidas de desempeño sobre una arquitectura
RAID.
Capítulo 6
Protección y Seguridad
U alquier aplicación, incluyendo los sistemas operativos, deben de realizar sus tareas en un
C tiempo adecuado como para que puedan entonces considerarse útiles. Cualquier aplicación
que entregue su trabajo tiempo después, comparado, por ejemplo, con un operador humano, no
tendrá entonces oportunidad de que al menos se siga usando, por muchos que sean los beneficios
que pueda proporcionar.
A medida que salen al mercado nuevos procesadores más rápidos, discos duros y memorias
de mayor capacidad, se les exige entonces a las aplicaciones y a los sistemas operativos mayor
facilidad de uso y desempeño. Ha habido muchas aplicaciones de software que al no poder
funcionar con una velocidad adecuada han sido desechados y retomados nuevamente mucho
tiempo después, hasta el momento en que ya existía el hardware adecuado como para poder
ser utilizado. Un ejemplo de ello fueron los algoritmos de entrenamiento de redes neuronales
artificiales. Incluso, con los avances de hardware actuales se sigue teniendo problemas para el
entrenamiento de grandes redes.
Existen muchas áreas, principalmente en el campo de la ciencia, en donde se requiere una
gran capacidad de cómputo para llevar a cabo sus tareas. En estas áreas la mayoría de las veces
se sacrifica la facilidad de uso, como por ejemplo, los entornos gráficos, para aprovechar esa
preciosa capacidad de cómputo en la resolución de problemas. Tenemos por ejemplo, el área
emergente de los algoritmos bioinspirados aplicados a la optimización de recursos, la búsqueda
combinatoria de nuevos compuestos farmacéuticos, la clasificación de estrellas y muchos más.
En el lado productivo se requieren sistemas que puedan controlar fábricas completas. Estos
sistemas se encuentran presentes en toda la línea de producción y comúnmente se usan sistemas
operativos en tiempo real.
Los grandes sistemas de correo electrónico, páginas WEB y los buscadores se ven cada
día más presionados por la competencia, tanto en la capacidad de almacenamiento que deben
309
310
soportar como en la velocidad promedio a la que deben de atender a sus usuarios. A medida
que se incrementa el número de usuarios aumenta el tiempo de espera del mismo. Bajo este
panorama, los administradores de sistemas deben de buscar alternativas que permitan mejorar el
tiempo de respuesta a sus usuarios.
En el área de la computación personal, el slogan de las empresas de software es vender, por
ejemplo uno de los campos más exigentes son los juegos. Las operaciones gráficas son las más
costosas computacionalmente hablando. En segundo lugar tenemos el medio ambiente gráfico,
que en la actualidad ya no es un lujo, es una necesidad para la mayoría de los usuarios de
computadoras.
Debido a que las empresas les interesa más vender, salen al mercado con cierta regularidad
nuevas versiones de software que incluyen muy pocas ventajas o funcionalidades con respecto
a la versión anterior. No obstante, cada cierto tiempo que va de unos tres a cuatro años1 , salen a
la luz versiones de sistemas operativos o de aplicaciones que exigen una capacidad de cómputo
mayor que el promedio de las computadoras con una vida cercana a los dos años anteriores. Esto
obliga irremediablemente a una actualización de hardware, cerrándose de esta forma el ciclo. Es
común que el software vaya a la zaga con respecto al desarrollo del hardware, pero, como se
dijo en cierto momento, el software da un salto intentando emparejarse y ocasionando entonces
una actualización obligada. (Si es que se desea contar con lo último en innovación tecnológica).
También se ha visto que algunos sistemas operativos tienen poco soporte hacia atrás. Esto
es, llega el momento en que los cambios son tan grandes que ya no es posible seguir soportando
las características de varias aplicaciones que en las versiones anteriores del sistema operativo
funcionaban correctamente.
La mayoría de las personas que compran un nuevo sistema de cómputo se basan principal-
mente en tres aspectos: la velocidad de procesador, la capacidad de la memoria y el disco duro.
Los más informados tomarán en cuenta también la capacidad de memoria caché en el procesa-
dor, la memoria RAM, las velocidades de bus de la tarjeta madre y de la memoria incluyendo
también la velocidad de acceso del propio disco duro, obteniendo con estos datos el timming
o los ciclos de reloj que debe insertar la CPU para esperar a que la memoria RAM o el disco
duro haga la tarea designada. Así, se dará una idea más clara de cuanto se está desperdiciando
en tiempo de procesador.
Aunque que la velocidad del procesador es importante, también hay que observar que se
debe de combinar adecuadamente la velocidad del procesador con la del bus de la tarjeta madre,
con la velocidad de la memoria y por supuesto, con el tiempo de acceso del disco duro. No
tiene caso tener un procesador de 3GHz, sin memoria caché, montado en una tarjeta madre con
1
Que por otro lado, es el tiempo de vida o garantía que tiene una computadora o servidor convencional
CAPÍTULO 6. PROTECCIÓN Y SEGURIDAD 311
un bus de 100MHz2 , o una memoria PC663 o agregando un disco duro de por ejemplo, 5400
revoluciones por minuto, que tenga, eso sí 200 GBytes de capacidad (No creo que exista uno
de estos). (compárese con un disco duro SCSI de 15 mil revoluciones por minuto). El ejemplo
anterior es un extremo y es muy improbable que se dé, pero si vamos a hablar de optimización
y desempeño es necesario tener en cuenta el hardware que tiene nuestro equipo y ajustar en la
medida de lo posible las velocidades junto con nuestro presupuesto.
La tendencia actual es facilitar en la medida de lo “imposible” el uso de la computadora. Al
hacer uso del término imposible4 , me refiero al hecho de que la mayoría de las aplicaciones y
de los sistemas operativos incluirán código que se use muy raras veces y que, en cambio debió
dedicarse muchísimo tiempo de programación y depuración para implementarlas, en lugar de
impulsar funcionalidades que ayuden a disminuir claramente la brecha entre el sistema operativo
y el usuario mejorando el tiempo de respuesta. El costo por incluir funcionalidades de este tipo
puede incurrir en una carga más grande y también una disminución significativa de la preciada
memoria RAM.
Todo ello se ve impulsado por la necesidad de venta y por la necesidad de tener cautivos a
los usuarios. De este modo, si se encuentran con otro sistema operativo en donde sea necesario
tener que aprender una larga lista de órdenes o un esquema que exija un razonamiento mínimo
acerca del uso de algún servicio del sistema operativo. La mayoría de los usuarios regresarán a
la comodidad del “doble click”.
Aunque el invento del ratón significó un gran avance en la computación, también ha creado
una gran dependencia del mismo y si la gente no tiene al alcance de un “click” y su ícono
correspondiente la función que desea, no encontrará la manera de hacerlo por otro camino. Así,
cada vez más vamos formando a nuestros futuros egresados como “Licenciados del doble click”.
A son de broma incluso algunos usuarios se refieren a la cantidad de clicks que son necesarios
para instalar un sistema operativo o alguna aplicación dada.
Este enfoque puede ser perfecto para aquellas personas que no tienen que ver con la compu-
tación, pero un egresado de las ciencias de la computación y áreas afines, debe estar preparado
más allá del famoso doble click.
Aunque cabe aclarar que muchas personas consideran que regresar a la línea de órdenes
frente a una consola es retroceder a la edad de piedra de la computación. Ojalá y algún día no
tengan que instalar un servidor SUN de última generación, con todos sus servicios, un desem-
peño inmejorable y tener que configurarlos en la terminal5 !!!.
2
Actualmente existen tarjetas base que corren a 1 GHz en bus.
3
Quiere decir que corre a 66 MHz. Existen en el mercado memorias que corren a 800MHz.
4
Considerando que el usuario debe estar ante un sistema operativo “amigable” o en otras palabras “a prueba de
tontos”.
5
Aunque intentan poner una interfaz gráfica amigable, su fuerte está en el desempeño y a ello dedican más su
312 6.1. CONCEPTOS Y OBJETIVOS DE PROTECCIÓN
6.1. Conceptos y objetivos de protección

La información se ha convertido en un arma muy poderosa que puede ayudar a mejorar las
ventas de una empresa o de hundirla si la competencia tiene acceso a ella y lanza el producto
antes. Este sería un caso de plagio ocasionado por una falla de seguridad en la protección de los
datos.
Actualmente la mayoría de las empresas utilizan diferentes mecanismos de seguridad para
proteger su información.
Cuando hablamos de sistemas de computadora, el principal responsable de manejar y cuidar
la información es el sistema operativo. En éste se mezclan diferentes subsistemas, como la in-
terfaz del sistema operativo, y el sistema de archivos para poder dar acceso a la información al
usuario adecuado.
A medida que aumenta la información almacenada en los sistemas de computadora, se in-
crementa también la necesidad de protegerla.
Cuando hablamos de información escrita en papel dentro de alguna oficina en un edificio, la
seguridad en el acceso se reduce a dejar pasar solamente a las personas autorizadas al mismo. A
este procedimiento se le llama seguridad física y puede implementarse de varias formas como
por ejemplo, tener un guardia que solicite la identificación correspondiente a las personas que
desean entrar o mediante llaves que usa solamente el personal autorizado o mediante una caja
fuerte que tenga un mecanismo de combinación.
En un ambiente informático existe a su vez otro problema, en la actualidad es posible acceder
a casi cualquier computadora que se encuentre conectada en una red con salida a internet.
Aparte de considerar la seguridad física, se debe de considerar también la seguridad lógica
para el acceso a la información en el sistema de archivos.
6.1.1. Conceptos fundamentales de seguridad

Ya vimos que al menos existen dos grandes áreas que abarcan la seguridad: la seguridad
física y la seguridad lógica. Empecemos hablando acerca del concepto de seguridad.
La seguridad en términos informáticos aún no tiene una definición que haya sido ampliamen-
te aceptada. En donde coinciden la mayoría de los autores es que debe de cubrir los siguientes
puntos:
1. El sistema debe ser consistente. El sistema debe comportarse como se espera, esto es, no
deben darse nunca cambios inesperados.
tiempo.
2. Servicio. El sistema debe proporcionar los servicios necesarios de forma confiable, cons-
tante y consistente.
3. Protección interprocesos. Si un programa está mal diseñado no debe de afectar el fun-

cionamiento ni del sistema operativo ni de las aplicaciones que estén corriendo en ese
momento. Tampoco se debe permitir el acceso a un área de memoria a otro proceso a
menos que haya sido autorizado antes.
4. Control de acceso. La información generada por un usuario no debe ser puesta a disposi-
ción de otros a menos que así lo decida el propietario. El sistema operativo debe de contar
con los mecanismos adecuados en el sistema de archivos de tal forma que pueda asegurar
diferentes modalidades de acceso a los archivos. (Vea por ejemplo, la sección 5.6.3.1 en
la página 293).
5. Autenticación. El sistema debe contar con los mecanismos adecuados para asegurarse de
que la persona es realmente quien dice ser. Además de contar con los privilegios necesarios
para realizar las tareas a las que está autorizado y de acceder a sus archivos bajo esos
privilegios.
6.1.1.1. Seguridad física
Los equipos informáticos deben protegerse mediante medidas de seguridad física. Estas me-
didas pueden ir desde guardias de seguridad hasta mecanismos sofisticados de autenticación.
La seguridad física debe de contemplarse desde la planeación misma del centro de proce-
samiento de datos. Por ejemplo, debe seleccionarse un área elevada para evitar inundaciones,
pero no tanta como para atraer continuamente rayos o en su defecto instalar pararrayos a una
distancia adecuada, para evitar que lleguen a caer en sus cercanías.
Otro aspecto importante de observar es evitar en la medida de lo posible su ubicación en
donde haya continuas marchas, mítines y manifestaciones. o en su defecto buscar la manera de
protegerlo con las medidas adecuadas.
La calidad del servicio eléctrico es otro factor en el que debe de poner sumo cuidado. Con-
tinuos apagones puede ocasionar desde la pérdida parcial de datos, hasta el daño de los propios
equipos. Considérese también el uso de fuentes ininterrumpibles de poder, la instalación de sis-
temas de potencia de emergencia o ambos, dependiendo del caso.
Todas estas medidas de seguridad deben de ser acompañadas de políticas y procedimientos
claros sobre el acceso y uso del equipo y de la información. Debe también de existir el regla-
mento correspondiente que norme con sanciones las faltas que pongan en riesgo los sistemas o
la información, de manera que se hagan cumplir las reglas por el bien de todos.
314 6.1. CONCEPTOS Y OBJETIVOS DE PROTECCIÓN
Existen muchos libros sobre la seguridad en donde se puede ampliar este tema. El escribir
más sobre ello sale del alcance de los objetivos de este libro.
6.1.1.2. Seguridad lógica
La seguridad lógica se refiere a la protección que debe de proporcionar el sistema operativo

a la información de los usuarios y de buscar alternativas para asegurar la integridad, la disponi-
bildad y la confidencialidad de los datos.
Empezaremos discutiendo sobre el medio ambiente en el que trabaja el sistema operativo.
Es importante reconocer la naturaleza de los ataques. Básicamente pueden clasificarse en las
siguientes:
1. Amenazas. En general los sistemas de computación tienen tres metas a cumplir basándose
en la seguridad. Por supuesto, para estas metas tienen sus respectivas amenazas:
Integridad de datos. Implica que solamente los usuarios autorizados pueden hacer
cambios a los datos. Esto implica que nadie ajeno a esta información puede alterar o
añadir información falsa.
Confidencialidad de datos. Sólo puede acceder a los datos la persona autorizada
para ello. Implica que nadie más puede leer y mucho menos modificar los datos con-
tenidos en el sistema. Esto es, si el propietario de los datos ha indicado que solamente
un determinado grupo puede acceder a esa información, el sistema debe asegurarse
de que así sea.
Disponibilidad del servicio. Significa que nadie debe poder alterar el sistema de
modo que se vuelva inestable o que sea imposible usarlo. Los ataques que se realizan
para lograr esto se llaman ataques de negación de servicio.
2. Intrusos. Un intruso es una persona que no está autorizada a entrar en un sistema dado,
de modo que intenta hacerlo sigilosamente. Existen dos clasificaciones para los intrusos:
Intrusos pasivos. Son aquellos que solamente les interesa leer los archivos y que,
por supuesto, no están autorizados para ello. Aquí podemos incluir a aquellas per-
sonas que solamente quieren curiosear y que muchas veces no tiene conocimiento
técnico para llegar más allá. Si el sistema lo permite, entonces verán el contenido de
cualquier archivo. Por ejemplo en un sistema UNIX, GNU/Linux, tanto las carpetas
como los directorios se crean por omisión con permisos de lectura y ejecución para
el grupo y para todo el mundo. En los sistemas basados en windows, antes de la
versión de NT, no tenían ningún tipo de protección, más que la que proporcionaba
la utilería attrib y que además para alguien con ese conocimiento resultaba absurda-
mente fácil cambiar también los permisos. Incluso aquellos sistemas basados en NT
sin una buena administración de usuarios para mantener los datos privados, puede
resultar igual de sencillo ver el contenido de los archivos.
Intrusos activos. Estos intrusos, desean, además de leer, hacer cambios en los datos,
ya sea para beneficio personal o simplemente destruir la información. Claro, tampoco
están autorizados para realizar esos cambios o borrar los archivos.
Estos usuarios, son por lo común gente que se encuentra autorizada a entrar al sis-
tema, pero consideran un reto violar los mecanismos de seguridad para ganar pri-
vilegios. En este grupo podemos encontrar a profesores, estudiantes o técnicos que
trabajan en el mismo centro de cómputo o que estudian en una universidad.
hay otros que intentan usar su posición dentro del sistema para intentar ganar dinero.
Por ejemplo, en un banco, una técnica común es truncar las fracciones de centavo y
enviar esas fracciones a otra cuenta. Esto lo logran modificando los programas o los
scripts que hacen las consultas o actualizaciones a las bases de datos. En otros casos
son capaces de chantajear a la administración exigiéndoles mejores condiciones de
trabajo e incluso dinero, amenazándolos con destruir la información.
El último grupo es el de aquellos que se introducen en los sistemas comerciales o
militares para robar nuevos diseños y patentarlos antes de que lo haga la empresa.
Así cuando la empresa intente patentarlo, la persona que lo hizo podrá demandarla
o exigir regalías por uso de la patente, en la mayoría de los casos la empresa pre-
fiere pagar las regalías o comprar de nuevo su patente a detener la producción del
nuevo producto, evitando así grandes pérdidas económicas. En el caso de accesos no
autorizados a un sistema militar puede vender la información al enemigo.
3. Pérdida de datos. Sin considerar aquellas que son ocasionadas por gente mal intenciona-
da, existen pérdidas accidentales de datos, dentro de ellas podemos enumerar las siguien-
tes:
Causados por la naturaleza. Inundaciones, terremotos, tormentas eléctricas o hu-

racanes.
Ocasionados por terceros. Motines, guerras, incendios, ratas o ratones que acaba-
ron con los cables, las cintas o los discos de respaldo.
Errores de hardware. Fallas del disco duro, cintas o discos magnéticos expuestos a
campos electromagnéticos intensos inadvertidamente o a un rayo muy cercano.
Errores de software. Errores de programación o en las líneas de telecomunicación.
316 6.2. FUNCIONES DEL SISTEMA DE PROTECCIÓN
Errores humanos. Extravío de los discos de respaldo, borrar inadvertidamente uno

o varios archivos, captura incorrecta de los datos.
La forma más barata y común de evitar muchos de estos problemas es manteniendo res-
paldos en un lugar alejado y bien resguardado del centro de procesamiento de datos. En la
sección 5.8 de la página 299 se vieron algunas de las técnicas más comunes de respaldo
de datos.
6.1.2. Vigilancia
La vigilancia es una técnica que permite monitorear de cerca a algunos usuarios sospechosos
de forma que pueda llevarse un seguimiento de todas las actividades que está realizando. A
medida que el tiempo pasa se van acumulando pruebas sobre el sospechoso de modo que no
haya ninguna duda sobre sus actos no autorizados.
Para evitar que hagan daño a otros usuarios, es normal que se implemente un sistema de
cómputo exclusivamente para recolectar toda esta información. A estos sistemas se les denomina
jaulas y pueden estar dentro del mismo sistema operativo pero en otro directorio que emula
perfectamente al sistema real o puede ser, como se dijo, una copia en otra computadora. Debido
a que los intrusos (que pueden ser hackers o crackers) intentan borrar todas las huellas que van
dejando a su paso es recomendable ir almacenando la información en otro sistema paralelo.
Este esquema debe complementarse con las técnicas adecuadas de auditoría y registro de
actividades del sistema.
Existen otras herramientas que permiten monitorear al sistema en tiempo real como swatch.
Esta herramienta debe configurarse con algunas palabras clave o patrones que buscará en los
archivos de logs en tiempo de ejecución. Cuando encuentre una coincidencia ejecutará la acción
correspondiente que puede consistir en enviar una alarma, ejecutar otra aplicación o enviar un
correo electrónico al administrador.
6.2. Funciones del sistema de protección

La seguridad es diferente a la protección. La seguridad incluye a los mecanismos que deben
implementarse para evitar intrusiones no autorizadas en los sistemas. En cambio, la protección
son mecanismos que se usan para evitar el daño o la lectura no autorizada a cierta información o
de otros usuarios. La protección se concebía como algo asociado a los sistemas operativos multi-
usuario. En la actualidad se ha extendido el concepto de protección de tal forma que incrementan
la fiabilidad de cualquier sistema complejo que haga uso de recursos compartidos.
Los mecanismos de protección pueden mejorar la fiabilidad detectando errores latentes en

las interfaces definidas entre los distintos subsistemas componentes. Un recursos no protegido
no puede defenderse frente al uso o mal uso por parte de un usuario no autorizado o poco com-
petente. Un sistema orientado hacia la protección podrá distinguir entre un usuario autorizado y
otro que no lo es. Por ende proporcionará el servicio al primero y al segundo lo restringirá de
acuerdo a las políticas establecidas por el administrador.
6.2.1. Fundamentos de la protección

Cuando se diseña un sistema de seguridad, es recomendable ajustarse a un principio, de
modo que el sistema en cada una de sus partes sea coherente y continúe esa línea durante todo
el desarrollo del proyecto. Uno de estos principios es el principio de privilegio mínimo. Este
principio establece que, por cada capa o nivel de seguridad se asigne a cada usuario, proceso o
aplicación exclusivamente los privilegios mínimos necesarios para que lleve adecuadamente su
función. De esta forma se asegura que cuando ocurra un fallo de seguridad, solamente se vea
afectado el nivel correspondiente a ese proceso, dejando intactos a los demás niveles, incluso
también a los demás procesos dentro del mismo nivel.
Desde el punto de vista de un sistema operativo, el principio de privilegio mínimo estará
implementado en los procesos, llamadas al sistema o estructuras de datos, de tal manera que
si algún componente tiene un daño, este daño también será mínimo. En la sección 6.6.2.2 en la
página 337 se habló del uso del desbordamiento de pila para obtener privilegios de administrador
en el sistema. Esta situación, tal vez no pueda impedirse, pero como se dijo en la misma sección,
la CPU podrá evitar la ejecución del código que haya sido sobreescrito en la pila. Así la pila no
tiene el privilegio de almacenar código ejecutable y por tanto, el problema no pasará a mayores.
Otra funcionalidad es el manejo de control de acceso a niveles muy finos. Esto es, el siste-
ma debe proporcionar el acceso solamente cuando sea requerido. Por ejemplo, si un trabajador
promedio tiene un horario de las 7:00 AM a las 3:00 PM de lunes a viernes, el sistema debería
proveer los mecanismos adecuados de tal manera que éste solamente pueda entrar a realizar sus
funciones esas horas y los días de trabajo entre semana únicamente. Así se evita que el sistema
esté abierto a algún ataque en otro horario al menos para ese nombre de usuario. Lo más común
es que los ataques se lleven a cabo en los días y horas no laborables. Algunos sistemas utilizan
contraseñas del tipo “úsese una vez y tírese”. Esto es, a cada usuario se le asigna una contraseña,
para su sesión actual, y será entonces necesario renovarla, cada día o por cada sesión.
Actualmente la mayoría de los sistemas operativos, proporcionan la capacidad de ir alma-
cenando todos los eventos sucedidos mientras ha estado activo el sistema. Como se vio en la
sección 6.8.2 en la página 357. En los archivos logs se van guardando, por ejemplo, los accesos
318 6.3. IMPLANTACIÓN DE MATRIZ DE ACCESO
de los usuarios incluyendo la fecha, hora y el tiempo que estuvo dentro de la sesión. De esta
forma, el administrador del sistema puede localizar actividades que estén fuera de lo común y
prevenir así daños mayores.
La administración de usuarios basada en el principio de privilegio mínimo, implica que cada
usuario tenga su propia cuenta, esto permite asignarle solamente los privilegios necesarios sobre
su información y restringir su acceso a otros datos. Algunos sistemas operativos basan sus me-
canismos de control de acceso en base a roles denominado RBAC (Role-Based Access Control)
para proporcionar esta funcionalidad.
6.3. Implantación de Matriz de acceso

Una forma de representar los derechos de acceso a los usuarios o procesos es mediante una
matriz de acceso. Una matriz de acceso está formada por un conjunto de filas que representan
los dominios y las columnas representan objetos. Cada entrada de la matriz está compuesta de
un conjunto de derechos de acceso. Puesto que la columna define los objetos explícitamente,
se puede omitir el nombre del objeto del derecho de acceso. La entrada access(i,j) define el
conjunto de operaciones que un proceso que se ejecute en el dominio Di puede invocar sobre el
objeto Oj .
Un esquema basado en matriz de acceso proporciona mecanismos para especificar una gran
variedad de políticas. Aquí el problema principal de implementación es asegurar que las propie-
dades semánticas que son inherentes a la matriz de acceso se cumplan. Esto es, se debe garantizar
que un proceso que se ejecute en el dominio Di sólo pueda acceder a los objetos especificados
en la pila i y de acuerdo a las entradas especificadas en la matriz de acceso. En la figura 6.1
tenemos un ejemplo.
Archivo 1 Archivo 2 Archivo 3 Impresora Láser

D1 Lectura Lectura
D2 Imprimir
D3 Ejecución Lectura
Lectura Lectura
D4 Escritura Escritura
Figura 6.1: Matriz de acceso
En la figura 6.1, el dominio D1 tiene acceso de lectura sobre el archivo 1 y sobre el archivo 2.
El dominio D2 puede solamente imprimir usando la impresora láser. El dominio D3 puede eje-
cutar el archivo 1 y leer el archivo 3. Aunque, por obvias razones, se debe de incluir un permiso
de lectura “oculto” para poder ejecutar el archivo 1, que más bien, aquí estaría indicando que
no puede ser visualizado por el dominio D3 . El dominio D4 tiene permisos de lectura/escritura
sobre el archivo 1 y el archivo 3.
En un sistema de protección dinámico es necesario en algunas ocasiones revocar derechos de
acceso a los objetos compartidos por diferentes usuarios. Se debe dar respuesta a las siguientes
preguntas para saber la manera mediante la cual se debe hacer la revocación:
1. Parcial o total. ¿Es necesario revocar solamente un subconjunto de derechos asociados
con un objeto, o revocar todos?
2. General o selectivo. Si se va a revocar un derecho, ¿afecta a todos los usuarios o sola-

mente a un subconjunto de ellos?
3. Inmediata o diferida. ¿La revocación debe darse inmediatamente o debe ser efectuada
en algún momento en el futuro?
4. Temporal o permanente. ¿Se puede revocar el acceso por un período de tiempo determi-
nado o ya no se debe volver a asignar ese derecho?
6.4. Protección basada en el lenguaje

Ha sido tradicional que el núcleo del sistema operativo actúe como un agente de seguridad
que inspecciona y valida cada intento que se realiza para acceder a un recurso protegido. Esta
validación puede dar pie a un procesamiento extra para la CPU. Este proceso se puede apoyar
por hardware para reducir el costo de validación o se pueden sacrificar algunos aspectos de la
protección. Se debe conseguir un balance entre eficiencia y seguridad, lo cual se vuelve difícil
si es que los mecanismos de soporte para la seguridad restringen la flexibilidad para implemen-
tar diversas políticas de protección o los entornos de protección se hacen más grandes de lo
necesario.
Los objetivos de la protección se hacen mucho más afinados en la medida que el sistema
operativo se hace más complejo. Esta refinación es posible dado que los programadores de sis-
temas de protección pueden hacer uso de las ideas originadas en los lenguajes de programación,
especialmente de la programación orientada a objetos en donde se hace uso de tipos de datos
abstractos con diferentes mecasnismos de acceso. Los sistemas de protección se ocupan de la
identidad de un recurso y de la naturaleza funcional de se acceso. En los sistemas de protección
más actuales permiten que un usuario administrador asigne los permisos correspondientes sobre
las funciones específicas que debe de realizar en el sistema de aplicación. Estas políticas de pro-
tección pueden variar con el tiempo. Por estos motivos, la protección es un asunto que no solo
320 6.4. PROTECCIÓN BASADA EN EL LENGUAJE
concierne a los diseñadores de un sistema operativo, también los programadores de aplicaciones

deben de tener acceso a mecanismos que les permitan proteger los recursos de un subsistema de
aplicación contra intentos de acceso de usuarios no autorizados o errores que puedan provocar
pérdidas de datos.
Los lenguajes de programación pueden permitir que el desarrollador declare el control de
acceso deseado a un recurso compartido en un sistema. Este tipo de declaración puede integrarse
al lenguaje junto con la declaración del tipo de dato, por ejemplo. De esta manera el diseñador
de cada subsistema puede especificar sus necesidades de protección, así como su necesidad de
usar otros recursos del sistema. Este tipo de especificación, se daría durante la redacción del
programa. Este enfoque tiene varias ventajas, de acuerdo a lo descrito por Siverchatz[95]:
1. Las necesidades de protección se declaran de forma sencilla en vez de programarse como

una secuencia de llamadas a procedimientos de un sistema operativo.
2. Las necesidades de protección pueden expresarse independientemente de los recursos que

ofrezca un sistema operativo en particular.
3. El diseñador de un subsistema no tiene que proporcionar los mecanismos para hacer cum-
plir la protección.
4. Una notación declarativa es natural por que los provilegios de acceso están íntimamente
relacionados con el concepto lingüístico de tipo de datos.
Las ventajas relativas del cumplimiento de la protección par parte del núcleo en comparación
con la protección proporcionada en gran medida por un compilador serían
1. Seguridad: La obligación del cumplimiento por parte del núcleo ofrece mayor grado de
seguridad que el que ofrece el compilador ya que en el compilador, la seguridad depende
de lo correcto que sea el traductor, del mecanismo suyacente de administración de alma-
cenamiento que proteja los segmentos desde los cuales se ejecuta el código compilado y
de la seguridad de los archivos desde los que se carga un programa.
2. Flexibilidad: En un lenguaje de programación hay más flexibilidad que en el núcleo del

sistema operativo, aunque este último puede proporcionar recursos suficientes para que
el sistema haga cumplir sus propias políticas. Con un lenguaje de programación se puede
declarar la política de protección y hacerse cumplir según sea necesario en una implemen-
tación.
3. Eficiencia: Se logra una eficiencia máxima cuando el hardware apoya directamente el

cumplimiento de la protección. En la medida que se requiera soporte de software baja el
rendimiento pero es posible verificar el cumplimienot de acceso estático fuera de línea en

el momento de la compilación.
La incorporación de conceptos de protección en lenguajes de programación, comop herra-
mienta práctica para el diseño de sistemas, apenas está en su infancia. Es probable que la pro-
tección se convierta en un asunto de vital importancia para los diseñadores se sistemas nuevos
con arquitecturas distribuidas y requisitos cada vez más estrictos sobre la seguridad de datos.
6.5. Concepto de seguridad

6.5.1. Clasificaciones de la seguridad
6.5.1.1. Seguridad por hardware
La implementación de la seguridad es una combinación de hardware y software. Como se

vio en la sección 6.2.1 en la página 337 es posible evitar vía hardware la ejecución de programas
que se encuentren en áreas que se supone contienen solamente datos o referencias. El problema
es que muchas veces se les complica el diseño a los fabricantes de chips de procesadores.
Aunque puede verse también desde el punto de vista competitivo. Es más fácil que un usuario
compre un chip de procesador que tenga integrado vía hardware un sistema de seguridad que le
va a permitir relajar un poco la gran cantidad de aplicaciones que debe de comprar para poder
mantener su sistema seguro, quitándole la molestia de cientos de virus, troyanos, software espía
además de toda la fauna existente y de ser posible impedir que su bandeja de entrada se le llene
de correo basura.
Aunque los fabricantes de chips de procesadores estén dispuestos a realizar tal cometido,
los fabricantes de sistemas operativos deben también hacer uso de estas nuevas características y
explotarlas como debe de ser.
6.5.1.2. Seguridad por software
Por su parte, el sistema operativo debe acometer también su responsabilidad con respecto a
la seguridad e implementar los mecanismos adecuados tomando en cuenta el tipo de usuario al
que va dirigido.
Si se mantiene el principio de mínimo privilegio éste debe de respetarse en todos los ámbitos.
Esto significa que debe de haber un sistema operativo a la medida para cada situación. Por
ejemplo, no podrá usarse el mismo sistema operativo para divertirse en casa que aquel que va
a usarse en la empresa o en un banco. Como puede verse los niveles de seguridad debe de
extremarse en el último caso.
322 6.6. VALIDACIÓN Y AMENAZAS AL SISTEMA
Los usuarios también tienen su propia responsabilidad. Aunque en la sección 1.1.1.1 en la

página 3 se indicó que se les debe facilitar la interacción con la computadora. Esta interactividad
no debe sacrificar para nada a la seguridad del sistema.
Otro aspecto que muchos usuarios no entienden es que precisamente esa facilidad de in-
teracción evita que éstos aprendan otras formas más seguras de utilizar su computadora y que
haya ocasiones en que incluso les sea complicado hacer uso de una línea de órdenes. Aunque
no se pretende que todo mundo sea un experto en el uso de órdenes del sistema de bajo nivel,
se ha comprobado que a medida que aumenta la capacitación del personal, disminuye también
el número de incidentes de seguridad. En ocasiones solo es necesario que sepan distinguir entre
formatos o aplicaciones que pueden involucrar la ejecución de código malicioso y cambiarlos
por otros más seguros, incluso sin perder en absoluto compatibilidad con otras aplicaciones.
Además es recomendable, de acuerdo al principio de mínimo privilegio, que las aplicaciones
puedan configurarse para que los usuarios que las usen tengan exactamente las funcionalidades
necesarias para su trabajo. por ejemplo, aún no queda claro para qué una secretaria que única-
mente redacta oficios, tenga disponible todo un lenguaje de programación en su editor de textos
al alcance de su mano. Si ella no hace uso de esa funcionalidad, es seguro que un atacante que
tenga acceso a su equipo sí haga uso de él. Por ejemplo, puede enviarle un correo electrónico
con un adjunto bajo ese formato incluido el código malicioso. Desde ese momento podemos
identificar una vulnerabilidad en ese equipo.
6.6. Validación y amenazas al sistema
6.6.1. Validación
6.6.1.1. Validación de usuarios
En los primeros sistemas no había aún autenticación de las personas que deseaban entrar a
la computadora. Por ejemplo, en los sistemas MS-DOS simplemente era necesario introducir el
disco del sistema operativo y a partir de ahí era posible tener acceso a todos los recursos de la
computadora y leer a su vez todos los discos flexibles o discos duros que estuvieran al alcance.
Ahora todos los sistemas operativos cuentan con algún método de autenticación. Cuando una
persona inicia una sesión en el sistema operativo, lo primero que tiene que hacer es introducir
su nombre de usuario y una contraseña. Algunos sistemas pueden obviar la contraseña más
aún cuando la seguridad no es un factor importante en el sistema, como por ejemplo en una
computadora para uso personal o multimedia.
Con estos datos, el sistema operativo determina la identidad del usuario y al mismo tiempo
los privilegios que tiene asignados.

En la mayoría de los sistemas de información públicos es necesario autenticarse con el ser-
vidor antes de poder hacer uso de los datos. En sistemas de información pública todo mundo
puede crear cuentas de usuario. Al hacerlo el servidor solicitará información general como el
nombre, la edad, estado civil, ocupación, el correo electrónico y posiblemente podrá escoger su
preferencias de consumo para recibir publicidad personalizada, tal como sucede en las cuentas
de correo de servidores públicos.
Cuando se realizan transacciones por internet, el nombre de usuario y la contraseña identi-
fican unívocamente al usuario de computadora con la persona, puesto que se da por hecho que
nadie más conoce esa información.
Existen muchas formas de autenticación. En general cualquiera de ellas se basará en alguno
o más de los siguientes puntos:
Información privada del usuario. Es una o más palabras que sólo conoce el usuario.
Cosas que se posee el usuario. Puede ser por ejemplo, una llave de hardware, una tarjeta elec-
trónica, alguna característica física, como sus huellas digitales digitales o el iris de sus
ojos o algún otro dispositivo que sea irrepetible por cada usuario.
Como puede notarse, la forma más utilizada de autenticación es la del par nombre de usuario
y contraseña. Este método es fácil de entender y de implementar. La forma más sencilla de ha-
cerlo es manteniendo una lista de pares que incluye el nombre de inicio de sesión y su contraseña
respectiva.. Cuando una persona desea entrar al sistema escribe su nombre de usuario y su con-
traseña, el sistema buscará el nombre en la lista y comparará la contraseña, si coincide entonces
permitirá a la persona entrar al sistema, de otra forma será rechazado el inicio de sesión.
Es común que la contraseña, cuando la escribe el usuario se cambie por asteriscos, incluso
algunos sistemas no muestran absolutamente nada para ni siquiera dar información de la longitud
de la misma. El primer enfoque lo utilizan los sistemas de windows NT en adelante, mientras
que los sistemas Unix toman el segundo enfoque.
Si un hacker o un cracker quieren entrar a un sistema, lo primero que deben hacer es con-
seguir un nombre de usuario y su respectiva contraseña. En la sección 6.6.2.1 vimos algunas de
las técnicas más comunes, por ejemplo, la de ingeniería social.
Existe una gran variedad de ataques para obtener los nombres de usuarios y sus contraseñas.
Para obtener el primero se puede hacer uso de una utilería llamada finger en Unix o intentar
con diferentes tipos de nombres. Es común que los ataques vayan dirigidos. Lo primero que
hará un hacker si es posible, será un poco de ingeniería social, ya sea de manera local o remota,
fingiendo ser un amigo de internet en una sala de chat. Después intentará encontrar la contraseña.
Esto se logra mediante una técnica conocida como ataque a diccionario. Con esta técnica el
atacante creará primeramente un diccionario de área local, por ejemplo, uno para Estados Unidos
y otro para México (Si se va a atacar una computadora de México no tendrá mucho sentido usar
un diccionario estadounidense), incluso pueden ser aún más localizados, como por ejemplo, el
estado o ciudad llegando incluso a nivel de oficina o la casa. Este diccionario contendrá los
nombres de los objetos y las personas más comunes en ese lugar. Después creará un programa
shell o programa por lotes para automatizar el ataque que irá proporcionando una a una las
palabras al sistema hasta encontrar la contraseña correcta. Existe una versión completamente
funcional con varios diccionarios incluidos con la opción de añadirle más se llama john the
ripper. Es libre en internet y es usada por muchos administradores de sistemas para verificar las
contraseñas de sus usuarios, pero también puede ser usada para otros fines. Más aún si el cracker
tiene acceso a la computadora como usuario local.
Aunque parezca increíble, algunos estudios, como el Morris y Thompson (1979) demos-
traron que cerca del 87 % aparecían en las listas que diseñaron, que consistía en una lista de
contraseñas verosímiles tales como los nombres de pila y apellidos, nombres de calles, ciuda-
des, palabras de diccionario escritas normalmente y al revés, número de matrículas de auto y
cadenas de caracteres cortas formadas aleatoriamente.
Otra técnica es la conocida como marcadores bélicos Un marcador bélico es una compu-
tadora con un programa diseñado para marcar automáticamente números telefónicos. Si se com-
bina uno de estos con los ataques a diccionario puede ser una combinación fatal. Por ejemplo un
cracker usó un marcador bélico combinado con la adivinación de contraseñas logrando entrar
a una computadora de citybank en Arabia Saudita, de donde obtuvo una lista de números de
tarjetas de crédito y registros de transacciones.
Con todo lo anterior vale la pena preguntarse ¿Es necesario construir contraseñas difíciles
de adivinar?
La respuesta es obviamente sí. Enseguida se proporcionan algunas reglas que deben de se-
guirse para obtener una contraseña difícil de adivinar:
1. Las contraseñas deben de contener al menos ocho caracteres.
2. Deben contener letras mayúsculas y minúsculas.
3. Deben contener además dígitos y caracteres especiales.
4. No deben usarse palabras que se encuentren en un diccionario, ni ser nombre de objetos

de oficina o marcas de algún tipo.
5. Debe ser fácil de recordar. Una contraseña imposible de adivinar no sirve si se olvida.
Algunos sistemas operativos obligan a los usuarios a cambiar su contraseña con regularidad,
limitando posibles daños si es que llega a adivinarse la contraseña de algún usuario. El problema
de este enfoque es que si la cambian con demasiada frecuencia se vuelva un proceso tedioso y
acabarán por hacer uso de contraseñas fáciles o si usan contraseñas complicadas las anotarán en
hojitas adhesivas y las tendrán pegadas cerca del monitor o en algún cristal a la vista de todo el
mundo convirtiéndose en un problema de seguridad potencial.
6.6.1.2. Dominios
Un enfoque comúnmente usado se llama dominios. Un dominio es un conjunto de opera-

ciones asignadas a un recursos y por ende, también solamente a ciertos usuarios, a lo cual se le
denominará derechos de acceso. De esta forma, si un usuario necesita hacer uso de la unidad de
CD-ROM, entonces, su UID6 será asignado a ese dominio. Un usuario puede pertenecer a tantos
dominios como sea necesario.
Figura 6.2: Definiciones de Dominios
En la figura 6.2 tenemos definidos tres dominios. El dominio 1 tiene asociados dos archivos
el archivo 1 tiene permiso de lectura y el archivo 2 tiene permisos de lectura y escritura. El
dominio dos tiene tres archivos el archivo 3 tiene permiso de lectura y que el archivo 4 tiene
permisos de lectura, escritura y ejecución. El archivo 5 tiene permisos de lectura y escritura. El
dominio 3 tiene un archivo de lectura, escritura y ejecución. El dominio 2 y tres comparten una
impresora que tiene solamente permisos de escritura.
6
Identificador de usuario
Todo usuario puede hacer uso de objetos. Un objeto puede ser por ejemplo, la CPU, una
unidad de cinta o un disco duro. Cada objeto está relacionado con un conjunto de operaciones
que se pueden ejecutar sobre dicho objeto. Se puede concluir entonces, que todo objeto pue-
de se considerado como un dominio. Incluso, es posible también definir dominios en base a
un subconjunto de operaciones de un objeto que permitan tener un control más fino sobre las
operaciones que pueden llevar a cabo determinados usuarios sobre un objeto en particular.
6.6.1.3. Listas de control de acceso
En la implementación de un sistema operativo, casi nunca se almacena la matriz de la figura

6.1 por que puede llegar a ser muy grande y además tiene pocos elementos y sería un gran
desperdicio de espacio en disco. Una solución sería el hacer uso de matrices esparcidas. Aunque
en realidad es más fácil almacenar la matriz por filas o por columnas y luego almacenar sólo los
elementos no vacíos. Los tipos de acceso más comunes son:
Lectura. Permite la lectura del archivo.
Escritura. Escritura o reescritura del archivo.
Ejecución. Permite cargar el archivo en memoria y ejecutarlo.
Adición. Permite añadir información nueva al final del archivo.
Borrado. Permite eliminar el archivo y liberar la entrada de directorio para su uso futuro junto
con el espacio.
Listado. Permite listar el nombre y los atributos del archivo.
Cuando se almacena por filas consiste en asociar a cada objeto una lista ordenada que con-
tiene todos los dominios que pueden tener acceso al objeto y cómo. Esta lista se denomina lista
de control de acceso (ACL: Access Control List).
Cada archivo en la figura 6.3 tiene asociada una lista ACL. Por ejemplo, el archivo F1 indica
que el usuario A, tiene permiso de lectura y escritura y B tiene solamente permiso de lectura.
El archivo F2 tiene en su ACL a tres usuarios con permisos distintos: el usuario A y el usuario
C tiene permiso de lectura, B tiene permiso de lectura y escritura. Observe que los procesos
pertenecientes a ese usuario también tienen exactamente los mismos derechos. De esta forma,
no importa tanto el identificador de proceso, es el dueño del proceso quien es el que indica al
sistema operativo a qué archivos y qué derechos tiene de acuerdo a su lista de control de acceso.
En la figura 6.3 muestra la forma básica del uso de las listas de control de acceso. En la
práctica se usan sistemas más elaborados. Hasta ahora solamente se han manejado tres tipos
Figura 6.3: Uso de las listas de control de acceso
de permisos (RWX), pero pueden existir más. Puede haber, por ejemplo, permisos globales o
genéricos. También pueden asignarse derechos por grupo y no por usuario, de esta manera, se
facilita la administración de algunos recursos que deben ser compartidos por varios usuarios. La
manera más común es crear nuevos grupos. El GID o identificador de grupo, puede incluirse en
la lista de control de acceso correspondiente. El sistema operativo debe por tanto, verificar si un
usuario pertenece a un grupo que sí tenga los permisos para acceder al archivo solicitado.
6.6.1.4. Sistemas basados en la confianza
El incremento de funcionalidades dentro de un sistema operativo o de las mismas aplicacio-

nes involucra escribir más líneas de código que a su vez implica una mayor complejidad. Por
todo ello, es más fácil que queden agujeros de seguridad escondidos dentro de tantas funciona-
lidades. En general, si se desea un sistema seguro, entonces su diseño debe permanecer lo más
simple posible. Por ejemplo, cuando se enviaban correos electrónicos en texto plano o ASCII,
no había forma de que éste pudiera dañar un sistema de cómputo. Eran completamente seguros.
Luego a los diseñadores se les ocurrió la idea de ampliar las capacidades del correo electrónico
para incluir otros tipos de documentos, por ejemplo, los archivos en formato Word que pueden
contener macros que podría dañar el sistema. Esto implica que la mayoría de las veces, tenga
que ejecutarse el programa correspondiente para poder visualizar el archivo. Pero al momento
de hacerlo, se ejecutará la macro con el código malicioso. Esta idea puede que no haya venido
precisamente por la necesidad de los usuarios. Vino más bien por la tendencia a facilitar a tal
grado la interacción con el usuario, que algunos lectores de correo pueden llamar automática-
mente al programa asociado sin intervención del propio usuario. Además viene también de la
necesidad de sacar nuevas versiones del programa y poder obtener algún dinero extra con las
actualizaciones.
Otro ejemplo es el contenido de las páginas WEB. Antes todo el contenido era estático y los
elementos animados que podía contener una página se reducían a imágenes tipo gif . Al pasar el
tiempo, se pasó por incluir contenido dinámico dentro de los sitios WEB. El contenido dinámico
implica que el usuario tenga que correr pequeños programas llamados applets o cokies (galle-
titas) para hacer una página más atractiva. Todo esto implica que cualquier persona maliciosa
pueda usar estos pequeños programas con otros fines e instalar, por ejemplo, un keylogger7 .
Cuando las páginas eran estáticas, no había tantos problemas de seguridad. Ahora, apenas se ha
corregido un problema, cuando ya otros han tomado su lugar.
Algunas instituciones prefieren la seguridad a las funciones llamativas. Por ejemplo, los
sistemas militares, pero la mayoría de las empresas prefieren un sistema fácil de usar aunque esté
lleno de agujeros de seguridad a implementar sistemas más sencillos con la debida capacitación.
Para resumir, es necesario contar con un modelo de seguridad en el centro del sistema opera-
tivo que sea lo suficientemente sencillo, por ejemplo, como el principio de privilegios mínimos
de modo que todos los involucrados en el proyecto puedan entenderlo completamente y resistir
todas las presiones por añadir funciones superfluas, que debiliten la seguridad en general.
En el centro de todo sistema basado en el enfoque de confianza se encuentra la base de
cómputo de confianza (TCB Trusted Computing Base que consiste en el hardware y software
necesarios para hacer cumplir todas las reglas en materia de seguridad. Si la base de confianza
trabaja de acuerdo a las especificaciones, la seguridad del sistema no podrá ser violada, sin
importar que las otras cosas estén mal.
La TCB consta de la mayor parte del hardware, haciendo a un lado aquellos dispositivos que
por su propia naturaleza no afectan la seguridad, una porción del kernel del sistema operativo y
la mayoría, si es que no todos los programas de usuario que tienen facultades de superusuario.
Entran también aquellas funciones propias del sistema operativo como la creación de procesos,
la administración de la memoria, la planificación de procesos y la mayoría de las tareas de
administración de archivos y de entrada salida.
Una parte importante de la TCB es el monitor de referencias. El monitor de referencias acep-
ta todas las llamadas al sistema con implicaciones de seguridad, como la solicitud de apertura de
archivos y decide si debe de ser procesada o no. De esta forma permite colocar todas las decisio-
nes de seguridad en un solo sitio, sin posibilidad de ignorarlo. Muy pocos sistemas operativos
7
Un pequeño programa que captura la entrada del teclado y es capaz de enviar los resultados a otro sitio o un
correo electrónico
se diseñan de esta manera y en muchas de las ocasiones es la razón principal de sus problemas
de seguridad.
En la figura 6.4 tenemos el mecanismo básico para implementar un monitor de referencias.
Figura 6.4: Implementación de un monitor de referencias
Observe que es necesario verificar en el módulo del monitor de referencias, si la petición

de servicio solicitada por todo proceso está permitida para ese usuario. Si es así entonces podrá
seguir adelante. De otra forma será detenida.
6.6.1.5. Auditoría
Una de las principales actividades que debe de llevar a cabo un administrador es la de efec-
tuar regularmente auditorías a los registros del sistema. En la sección 6.8.2 se habló brevemente
de algunas instrucciones que pueden usarse para leer los registros de actividades del sistema. No
obstante, confiar al cien por ciento en estos registros no tiene fundamento. En primer lugar por
que la mayoría de la información escrita se encuentra en texto plano y es muy fácil de modificar
si se tiene el permiso de acceso correspondiente. Lo más recomendable es guardar los registros
en otra máquina que se encuentra fuera de la computadora que se va a auditar o en el mejor de
los casos enviar la salida correspondiente, no a los archivos de logs del sistema si no directa-
mente a la impresora. De esta forma, se hace muy difícil de poder eliminar. En el entendido de
que la impresora no se encuentre al alcance de los atacantes.
En un sistema basado en Unix existe el mecanismo de logs para almacenar toda la informa-
ción concerniente a las actividades del sistema.
La mayoría de las actividades realizadas por un sistema Unix son susceptibles de ser mo-
nitorizadas: desde el tiempo que utiliza la CPU para ejecutar una aplicación, pasando por los
accesos a los archivos, el ingreso de los usuarios al sistema, procesos que ejecutan hasta la hora
en que salen incluyendo los accesos fallidos que ha habido durante el inicio de alguna sesión.
Aunque el sistema de logs tiene el problema de ser texto plano, tiene la ventaja de que puede
ser también procesado rápidamente y de esa forma saber si existen actividades irregulares en el
sistema, esto es permiten de manera automática detectar actividades “sospechosas”.
Un sistema Unix se basa en los siguientes procesos y archivos para poder dar seguimiento a
las actividades del sistema:
El demonio syslogd . Este proceso se lanza automáticamente después de que arranca un sis-
tema Unix. Es el proceso encargado de guardar los informes correspondientes a las ac-
tividades desarrolladas en una máquina. Recibe los mensajes de las diferentes partes del
sistema y se encarga de clasificarlos en distintos archivos, de acuerdo a su procedencia.
syslog. El archivo syslog (guardado en /var/log/ o en otro directorio parecido) es uno de los
archivos de log más importante del sistema; en éste se almacenan, en texto plano, los
mensajes correspondientes a la seguridad de la máquina, como los accesos o los intentos
de acceso a ciertos servicios. No obstante, este fichero es escrito por syslogd, por lo que
dependiendo de nuestro archivo de configuración encontramos en el archivo una u otra
información. Al estar guardado en formato texto, podemos ver su contenido con un simple
more, less o cat.
messages. En este archivo de texto se almacenan datos “informativos” de algunos programas,

mensajes de baja o media prioridad destinados más a informar que a avisar de sucesos
importantes, como información relativa al arranque de la máquina.
wtmp. Es un archivo binario y no podemos visualizar su contenido con visores de texto. Aquí
se almacena información relativa a cada conexión y desconexión al sistema. Podemos ver
su contenido con la orden last.
utmp. El archivo utmp es un fichero binario con información de usuarios que están conectados
actualmente; el programa /bin/login genera un registro en este fichero cuando un usuario
conecta, mientras que init lo elimina cuando lo desconecta. Para ver el contenido de es-
te archivo podemos se utilizan como last (indicando el nombre del archivo mediante la
opción -f), w o who (que significa en este caso quien).
lastlog. El archivo lastlog es un archivo binario guardado generalmente en /var/adm/ en Sola-

ris, y contiene un registro para cada usuario con la fecha y hora de su última conexión;
podemos visualizar estos datos para un usuario dado mediante la orden lastlog.
sulog. Es en este archivo de texto donde se registran las ejecuciones de la orden su, indican-
do fecha, hora, usuario que lanza el programa, usuario cuya identidad adopta, terminal
asociada y éxito (‘+’) o fracaso (‘-’) de la operación.
Puede hacerse uso de herramientas que facilitan el resumen de la gran cantidad de informa-
ción contenida en los archivos logs del sistema, como por ejemplo la herramienta swatch[7],
que permite avisos en tiempo real cuando se detecta alguna actividad sospechosa.
Tan pronto se ha detectado una intrusión al sistema es prioridad establecer que tipo de in-
formación ha sido expuesta y analizar todo el sistema en busca de puertas traseras. Es necesario
aislar completamente el sistema para evitar que el intruso efectúe una acción que pueda com-
prometer mucho más el sistema, como el borrado del disco duro o algo similar.
6.6.1.6. Controles de acceso
En la sección 6.6.1.3 se hizo una descripción de cómo hacer uso de las listas de control
de acceso como medio de control de las actividades en el sistema de archivos. Como podrá
recordarse a cada archivo y directorio se le asigna un propietario, un grupo o una lista de usuarios
con permisos particulares. Otro enfoque, que podemos encontrar en Solaris 10 es el de control
de acceso basado en roles (RBAC, role-based access control). La idea principal ahora es el
privilegio. Un privilegio es el derecho que tiene un objeto (ya sea un usuario o un proceso) de
ejecutar una llamada al sistema o a usar una opción dentro de dicha llamada al sistema como
abrir un archivo para lectura o escritura. La ventaja es que se pueden asignar privilegios a los
procesos, limitando a exactamente el tipo de acceso que necesitan para realizar su tarea.
Los privilegios y programas pueden asignarse a roles. Un rol es parecido a un dominio, esto
es, es un conjunto de privilegios que forman parte de una tarea común (rol). Así los roles se
asignan a los usuarios para que pueda ejecutar la aplicación con la que podrá desempeñar su
tarea. La asignación de roles que activan uno o más privilegios reducen el riesgo de seguridad
asociado con los superusuarios y con los programas que necesitan privilegios de superusuario
temporalmente (programas con el setuid activado).
En la figura 6.5 vemos cómo el usuario n ejecuta un proceso con los privilegios que están
asignados a un rol.
Figura 6.5: Control de acceso basado en roles

6.6.1.7. Seguridad del núcleo
En la sección 6.2.1 en la página 327 analizamos los sistemas de seguridad basados en la

confianza en donde se hacía incapié en mantener el sistema lo más sencillo posible. El mismo
principio se puede aplicar al kernel.
Es mucho más sencillo hacer un sistema seguro si la seguridad se ha mantenido como una
política desde el propio diseño del núcleo del sistema
Las medidas de seguridad más importantes están implementadas en el núcleo, que debe de
mantenerse intencionalmente lo más pequeño posible.
Otro aspecto que se debe considerar son los manejadores de dispositivos. Deben de venir
de una fuente fiable o ser revisados exhaustivamente para asegurarse de que no introducirán
problemas de estabilidad al kernel.
Hasta ahora hemos analizado los temas más importantes que deben de considerarse tanto en
la protección como en la seguridad. Aquí los resumimos para recalcar aún más su importancia:
La entrada al sistema. La persona debe de proporcionar su nombre de usuario y su contraseña.
La verificación. El sistema valida la contraseña cifrándola y comparándola con la contraseña

cifrada en el sistema, si coincide se le acceso. De otra forma el sistema lo rechazará incre-
mentando cada vez más el tiempo para permitir una nueva conexión. Al tercer intento es
posible que el sistema tarde un tiempo grande.
El control de acceso. El sistema operativo provee los mecanismos de acceso a los recursos de
forma tal que asigna solamente los recursos necesarios autorizados a cada usuario.
Auditoría. El administrador u otro equipo deben de vigilar continuamente los registros del
sistema para prevenir o detener ataques.
La técnica más confiable y que debería estar implementada completamente en todos los
sistemas operativos es la de los sistemas basados en la confianza en donde todas las llamadas
son analizadas antes de que sean pasadas al núcleo. Este enfoque se describió en la página 327
en la sección 6.6.1.4.
Aunque un sistema esté basado con la política de seguridad en mente, deben de hacer pruebas
exhaustivas antes de poner el sistema operativo en el mercado. En realidad, tal parece que es todo
lo contrario. Las estrategias de marketing y las propias compañías liberan versiones beta para
que sean probadas por los usuarios. En esta etapa es posible detectar muchos errores y aún así
el sistema operativo que llega al usuario final está lleno de fallos.
Para enfrentarse a esta gran cantidad de problemas y resolverlos lo más pronto posible, en
la actualidad existen sistemas de reporte de errores automatizados para la mayoría de las aplica-
ciones incluidos los sistemas operativos. Esto permite que los desarrolladores sean rápidamente
notificados sobre alguna vulnerabilidad encontrada durante el trabajo diario de los usuarios.
Muchas de ellas están a tal grado automatizadas que simplemente solicitan al usuario su auto-
rización para que sea enviado el reporte de error junto con toda la información necesaria para
poder reproducir el fallo y corregirlo. El usuario debe esperar a que se genere el paquete de
parches o Service pack que incluye las nuevas versiones de utilerías o aplicaciones que tienen
corregidas las vulnerabilidades encontradas durante uno o dos años.
6.6.2. Amenazas al sistema

6.6.2.1. Ataques internos
Son aquellos que se realizan dentro del propio sistema por usuarios que trabajan en la em-
presa. Podemos tener los siguientes:
Ingeniería social. La ingeniería social es una técnica que ocupan algunos usuarios para ha-
cerse de contraseñas de otras personas o incluso del superusuario o administrador. Se le llama
ingeniería social por que el usuario llega con la persona que escogió como víctima y podrá hacer
cualquiera de las siguientes cosas:
1. Hacer preguntas. El usuario mal intencionado empezará por preguntar el nombre de la

pareja, los hijos o la mascota o el registro federal de contribuyentes. La mayoría de la gente
usa alguna de esas palabras como contraseña haciendo algunas modificaciones sencillas.
2. Buscar pequeñas notas. Hay muchas personas que escriben sus contraseñas cerca del
monitor o el teclado “para acordarse más rápido”. Una simple ojeada y el usuario se hará
de una nueva contraseña.
3. Mirar el teclado. Si se observa suficientes veces, un usuario será capaz de “leer” la con-
traseña a medida que la persona la escribe. Es mucho más fácil cuando la persona no está
familiarizada con el teclado.
4. Buscar en el cesto de basura. La mayoría de la gente no da importancia a lo que se tira en

la basura. Las personas encargadas de la limpieza pueden fácilmente confundir un papel
con el nombre de usuario y contraseña con uno cualquiera y tirarlo.
Caballos de troya. El nombre viene por la manera en cómo los griegos lograron penetrar en
la ciudad de Troya. En términos de computación se trata de un pequeño programa que parece
inocente pero que contiene código que puede realizar alguna función inesperada o destructora.
Por ejemplo, dicha función puede modificar, borrar o cifrar los archivos del usuario, además
de que pueda reenviarse a otros vía correo electrónico. El programa comúnmente va disfrazado
como una aplicación útil y gratuita como un juego, un visor de algún formato de vídeo, un
programa que proporciona nombres de usuario y contraseñas para entrar a sitios de pornografía
o algo parecido que pueda llamar la atención del usuario de manera que se animen a bajarlo e
instalarlo. Como puede verse, ya que se está ejecutando el caballo de troya puede hacer todo lo
que tiene permitido el usuario, incluyendo conexiones a la red borrar archivos o enviarlos a una
dirección preestablecida por el diseñador del programa.
Otra manera de engañar al usuario para que ejecute el caballo de troya es guardándolo en un
directorio en donde alguien lo pueda ejecutar. La mayoría de los sistemas operativos manejan
una variable de entorno llamada $PATH que indica en cuáles rutas debe de buscar el sistema
operativo para ejecutar una orden. Las entradas más comunes pueden ser las siguientes:
/usr/local/SDK/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games para mostrar las rutas que
existen actualmente en $PATH se usa la orden:
echo $PATH
Así, cuando se teclea una orden en el shell éste verifica primero si existe un programa con
ese nombre en cada ruta separada por “:” si lo encuentra entonces lo ejecuta, de otra forma
indicará que no existe. Si el caballo de troya fue insertado en alguno de esos directorios y es
llamado por el usuario entonces habrá ganado la batalla. También es común que se haga uso
de aquellos errores de “dedo” más comunes como por ejemplo “cst” en lugar de “cat”, “la” en
lugar de “ls”. Si el usuario comete este pequeño error, se ejecutará el programa y luego mostrará
un mensaje indicando que el programa no existe para pasar inadvertido. En muchas ocasiones
cuando un intruso ha robado una contraseña intentará colocar el caballo de troya llamándolo
como una orden del sistema colocándolo en el mismo directorio del usuario. Así sólo le queda
esperar a que éste ejecute una de esas órdenes. Este truco puede funcionar en un sistema basado
en windows, por que el sistema operativo verifica primero si el programa se encuentra en el
directorio actual antes de buscarlo en las rutas del sistema. En un sistema basado en UNIX no se
ejecutará debido a que el directorio actual no se toma en cuenta a menos que la orden se ejecute
indicando el directorio actual por ejemplo: ./ls, lo cual es muy improbable que haga el usuario.
Falsificación de inicio de sesión. Esta técnica la usa un usuario que tiene acceso al sistema.
Elabora un programa que se asemeja al inicio de sesión del sistema y la deja corriendo en su
propia sesión. De esta forma, cuando llega otro usuario escribirá su nombre de usuario para
ingresar, a continuación el programa le solicita la contraseña y la guarda en el directorio del
falsificador. En vez de dar acceso al usuario simplemente termina la sesión y permite que el
sistema operativo pida nuevamente el nombre de usuario y contraseña. El usuario pensará que
se equivocó y nuevamente ingresará con sus datos al sistema. El falsificador tendrá entonces en
su directorio los datos necesarios para acceder a la información de la víctima. Si el falsificador
deja corriendo muchas sesiones falsas en diferentes áreas podrá hacerse de muchas contraseñas
en muy poco tiempo.
Actualmente esta es una técnica común que usan algunos estafadores en internet. Hacen una
interfaz idéntica a la de algún banco, envían un correo electrónico a la víctima indicando que el
banco necesita confirmar alguna información y que es necesario que entre a verificarlos. Junto
al mensaje proporcionan la liga al sitio de internet con la interfaz falsa. Si el usuario se introduce
en ella, escribe sus datos de acceso y no observa la barra de dirección del navegador8 entonces
le habrá dado su información al defraudador con las consecuencias que ya conocemos.
Bombas lógicas. Son segmentos de código insertados en el sistema que verifican que se siga
dando algún evento, por ejemplo que un usuario siga proporcionando su nombre y contraseña.
Si se sigue haciendo esto todo el tiempo no pasa nada, pero si trascurre mucho tiempo sin que
ese evento suceda entonces la bomba se activará ocasionando pérdida de información o alguna
otra cosa.
Algo parecido a una bomba lógica son las trampas. La diferencia es que una trampa per-
mite el acceso al sistema por medio de un usuario oculto. Esto puede lograrse insertando en el
programa de autenficación una parte de código que evite la verificación de la contraseña para
ese usuario en específico. La única manera de evitar este problema es mediante la revisión de
código fuente como procedimiento estándar. De esta forma, cuando un programador termine de
codificar un módulo, tendrá que explicar ante un comité de control cada línea del código escrito.
Esto permite elevar considerablemente la probabilidad de encontrar alguna trampa y también
aumenta el riesgo para el programador, puesto que puede ser una forma persuasiva para evitar
este tipo de conductas.
6.6.2.2. Ataques externos
Son aquellos que son efectuados desde fuera de las instalaciones. Lo más común es que
estos ataques vengan desde la red o internet. Su primer objetivo es buscar la manera de entrar
al sistema por algún puerto y de hacerse de uno o más nombres de usuario y después intentar
adivinar las contraseñas para poder acceder al sistema. Algunos de ellos, como ciertos virus solo
intentan reproducirse en la computadora y reenviarse a otros huéspedes o hosts.
8
Aunque algunos navegadores se les puede engañar haciendo que muestren una dirección cuando en realidad
están en otro sitio
Puertas traseras. Son parecidos a las bombas lógicas en el sentido de que son dejados por
los programadores del sistema operativo o de alguna aplicación. La diferencia es que permiten
el acceso, ya sea local o desde la red, sin que sea un usuario normal del sistema. Para pasar
desapercibido muchas veces utilizará un nombre muy parecido al de otro usuario o a veces ni
siquiera lo necesita para lograr una consola de sesión.
Cuando un sistema ha sido penetrado, es muy común que el atacante añada versiones modifi-
cadas de las órdenes de consola u otros programas comunes, de tal forma que cuando éstos sean
ejecutados por el usuario o el administrador, el atacante tenga la oportunidad de mantener abier-
ta una puerta trasera dada. Por ejemplo, la ejecución de un shell o consola con los privilegios
del usuario actual sin necesidad de nombre de usuario y contraseña. Este programa escuchará
un número de puerto predeterminado brindándole el acceso al diseñador del mismo.
Un problema mayor es cuando se ha publicado el número de puerto hacia el cual hay que
dirigirse para poder tener acceso, lo que implica que no sólo el atacante podrá entrar al sistema
si no que también puede entrar cualquier persona que haya recibido la información, aumentando
así el riesgo de difusión de datos almacenados en el servidor.
Desbordamiento de pila o de búfer. Es una de las formas más comunes utilizadas por los
atacantes externos del sistema, mediante una conexión de red, ya sea de área local o vía telefó-
nica. Los usuarios locales también pueden utilizar esta técnica para obtener mayores privilegios
sobre el sistema.
Una vez que al atacante ha logrado robar un nombre de usuario o contraseña, el siguiente
paso es obtener mayores privilegios. Si no ha podido hacerse de un nombre de usuario y su res-
pectiva contraseña, entonces intentará atacar aquellos programas que proporcionan un servicio
público, como un servidor de correo o un servidor de archivos buscando principalmente que
usen alguna función que pueda comprometer la seguridad del sistema.
En general, lo que hace el atacante es aprovechar un error de algún programa que común-
mente esté escrito en lenguaje C o con alguno que no haga comprobación de límites en arreglos
o en búferes. El proceso que hace es el siguiente:
1. Analizar el programa fuente para ver qué llamadas utiliza. Por ejemplo, una instrucción
que puede comprometer al sistema es la función gets(), que permite leer una cadena desde
teclado, pero que no comprueba que exista suficiente espacio para los caracteres leídos.
2. Si no está disponible el código fuente, probará los programas por prueba y error, esto lo
logra intentando escribir más caracteres de los que podría prever la aplicación.
3. Cuando encuentra que un programa tiene esa vulnerabilidad, lo que hace es escribir un
programa en lenguaje ensamblador y pasarlo como argumento del programa.
4. El programa está diseñado para que exceda la máxima capacidad permitida por la cadena
o el búfer de lectura, lo que ocasiona que se sobreescriba parte de la región de la pila, que
como sabemos, es donde el sistema operativo guarda los parámetros de la llamada a la
función y por ende, guarda también la dirección de retorno de la función.
5. A partir de este momento sólo se espera a que la llamada de función regrese, pero cuando
la CPU toma la dirección de retorno, ésta ya habrá cambiado por cualquiera que haya
colocado el atacante en el punto 2 anterior.
Como puede notarse, el atacante puede, ya sea ejecutar un shell con los privilegios del pro-
ceso o programa atacado o incluso, insertar el código que desee ejecutar en la misma cadena que
se usa como parámetros.
Una alternativa para reducir este tipo de ataques es que la CPU evite la ejecución de instruc-
ciones que se encuentren en la sección de memoria dedicada a la pila. Por ejemplo, las versiones
recientes del chip de SPARC de Sun incluyen este mecanismo de seguridad y por tanto, las
versiones más recientes de Solaris la utilizan. Aunque puede seguirse modificando la dirección
de retorno de la rutina desbordada, cuando la dirección de retorno de la función apunta a una
ubicación dentro de la sección de pila y se intenta ejecutar el código almacenado en ésta, se
produce una excepción y el programa se detiene con un error.
Las versiones recientes de los microprocesadores de AMD e Intel x86 incluyen la funcio-
nalidad NX, que permite detener también este tipo de ataques. Esta funcionalidad también está
siendo utilizada por varios sistemas operativos para x86 y AMD dentro de éstos tenemos a Linux
y Windows XP con el paquete de servicios SP2 (Service Pack 2). La implementación vía hard-
ware implica el uso de un nuevo bit dentro de las tablas de páginas de la CPU. Este bit permite
marcar la página asociada como no ejecutable, impidiendo así ejecutar instrucciones desde ella.
Virus. Los virus son programas autorreplicables que representan otro tipo de amenaza. Co-
múnmente están diseñados para “infectar” a otros programas. Pueden causar muchos problemas
debido a que en el momento en que se encuentran activos en el sistema, pueden destruir o mo-
dificar programas o archivos, dependiendo de las capacidades que haya incluido el programador
del virus. Un virus es un pequeño conjunto de instrucciones que viene dentro de un programa
legítimo. Son muy específicos de la arquitectura, del tipo de sistema operativo y de las apli-
caciones. La mayoría de ellos utilizará una o más vulnerabilidades aún desconocidas (a veces
conocidas) por los administradores de sistemas e incluso de los propios diseñadores de aplica-
ciones o de sistemas operativos. Los virus constituyen un problema muy grave para los usuarios
de máquinas tipo PC, especialmente aquellos que corren alguna versión de Windows. Esto se
debe principalmente a que en esta plataforma existe una gran diversidad de software y el inter-
cambio de programas y la piratería es altísimo, lo que implica una infección casi segura cuando
no se usa software original o legítimo. Por otro lado, la cantidad de vulnerabilidades conoci-
das son muchas, sin considerar aquellas desconocidas para poder cuantificarlas pero que pueden
estar siendo usadas en este momento para la creación de algún virus nuevo.
Los sistemas basados en UNIX, son menos propensos a los virus debido a que los programas
ejecutables están protegidos contra escritura por el propio sistema operativo. Incluso, si un virus
llega a infectar a uno de esos programas, sus poderes están comúnmente limitados, esto es,
son pocos los programas que tiene privilegios de ejecución a nivel de administrador. Cuando un
usuario de un sistema UNIX se infecta con un virus el daño suele no pasar más allá del directorio
de trabajo del propio usuario, dejando intactos los demás directorios de los otros usuarios del
sistema.
La propagación de un virus puede realizarse de muchas formas, las más comunes son:
1. Vía correo electrónico. Es el medio más común para difundir un virus mediante adjuntos
con código tipo Active X.
2. discos magnéticos o memorias USB. Cuando se comparten archivos de microsoft Office,

el virus puede ir en alguna macro de un documento o pequeños programas de Visual Basic.
3. Compartir programas por la red. Como se comentó la piratería es un medio muy común
de distribuir también virus.
4. Programas generadores de números seriales. Estos programas permiten obtener un nú-

mero serial válido para desbloquear completamente las funcionalidades de un programa
de prueba. Cuando se ejecuta el programa se ejecuta también el virus.
5. Caballo de troya. Es un anzuelo para hacer que el usuario ejecute el programa del virus,
puede entonces ser parte de una animación bonita, una presentación, el mostrar algún
documento, etc. Es común que vengan como archivos adjuntos de un correo electrónico.
Gusanos. Es un programa que utiliza un mecanismo de reproducción para afectar el rendi-

miento del sistema. La principal diferencia con respecto a un virus es que consume grandes
recursos del sistema impidiendo su funcionamiento normal, además de utilizarlos para propa-
garse por la red llegando incluso a colapsarla como sucedió con el gusano diseñado por Robert
Morris en 1988 y el gusano Sobig.F. que se distribuía mediante el correo elecrónico. Fue tal
su impacto que uno de cada diecisiete mensajes de correo estaban infectados con el gusano. El
gusano saturó la mayoría de las bandejas de entrada de los sistemas afectados, ralentizó las redes
de comunicaciones y fueron necesarias miles de horas hombre para llevar a cabo las tareas de
limpieza.
6.6.2.3. Penetración al S.O
En la actualidad se ha vuelto una técnica común intentar descubrir de forma controlada las
posibles vulnerabilidades del sistema. Lo que se hace es que algunas personas tomen el papel
de hackers para entrar subrepticiamente a un sistema de computadora. La forma más habitual
es contratar a un grupo de expertos en seguridad conocidos como grupos tigre o equipos de
penetración. Este equipo tratará de introducirse en el sistema utilizando desde las técnicas más
comunes en Internet hasta las más sofisticadas. En muchas ocasiones, son los propios hackers
los que informan al administrador de sistemas de las vulnerabilidades encontradas y que aprove-
charon para hacer la intrusión. No se recomienda esperar a que alguien que no conocemos, aún
con las mejores intenciones, burle las medidas de seguridad existentes, debido a que es posible
que haya difundido su “éxito” a través de la red y en poco tiempo es seguro que se tenga una gran
cantidad de ataques y no precisamente de gente que sólo quiere husmear por el servidor. Muchas
veces intentarán enviar correo basura desde las computadoras afectadas o dirigir ataques a otras
computadoras haciéndonos parecer culpables.
Como comentamos en la sección 6.6.2.1 en la página 334 existen técnicas que fácilmente
podemos contener con un poco de cuidado en la implementación de las aplicaciones, el sistema
operativo o simplemente al administrar el sistema.
Actividades más comunes de un intruso A continuación se da una lista de las actividades

que podría realizar una persona que intenta penetrar desde fuera en el sistema operativo.
1. Instalación de troyanos de conexión inversa que se conecte a un DNS estático, median-

te un gancho, una promoción, una postal o algo parecido. O mediante ingeniería social
conseguirse una cuenta de usuario que ahorraría muchos pasos. El troyano enviará toda la
información a la máquina especificada por el DNS. Si el atacante no tiene una DNS fija
podrá encontrar varios sitios en Internet que ofrecen ese servicio.
2. Entender el objetivo. El atacante buscará toda la información concerniente al hardware de

red con que se cuenta. Marca y modelo del router, de los concentradores o switches, del
servidor, el tipo de sistema operativo o vulnerabilidades conocidas.
3. Intentar introducirse en el sistema pasando a través del router de una red LAN, aprove-
chando las vulnerabilidades encontradas en el paso anterior.
4. Utilizar herramientas “todo en uno” como netcat o nessus. Estas herramientas, permiten
que casi cualquier persona con algo de conocimientos de red pueda llevar a cabo ataques
sistemáticos para encontrar los puntos débiles del sistema.
5. Cuando se haya encontrado una vulnerabilidad explotarla para obtener un shell.
6. Si funcionó se habrá entrado al sistema, enseguida:.
Acabar con los procesos que pueden poner en peligro la identidad en la intrusión.
Por ejemplo cambiando la orden who por una modificada que evite mostrar nuestro
usuario.
Borrar las huellas de intrusión para evitar ser detectados, lo más común es borrar los
logs del sistema o en su defecto enmascararlos.
Evitar que cierre esa entrada que ya se logró colocando una puerta trasera.
Prevención de un ataque Ahora daremos una lista de algunas de las posibles acciones que
deben realizarse para evitar que llegue a efectuarse la intrusión.
1. Cambiar todas las contraseñas que vienen por defecto en routers o en servidores tales
como la cuenta Administrador en Windows con contraseña en blanco. Las de los routers
son específicas del modelo pero los fabricantes las describen en sus páginas de soporte
técnico.
2. Cerrar todo aquel servicio que no se use. mientras menos servicios superfluos haya más
seguro será el sistema, pues habrá menos puntos de entrada.
3. Bloquear vía firewall todos los puertos. Un puerto es un número que identifica un servicio
en el sistema y es común que tenga asociado un programa servidor para proporcionar la
información deseada. Algunas veces estos servicios son lanzados por un programa deno-
minado superserver. que es el único que se encuentra en ejecución. Al recibir una solicitud
por un puerto, se encarga entonces de lanzar el programa correspondiente. De esta forma
se evita que el sistema se sobrecargue con mucho programas de servicio, puesto que no es
muy común que haya peticiones de diferentes servicios continuamente. Cuando la deman-
da de un servicio es muy grande, se recomienda lanzarlos independientes del superserver.
4. Restringir los lugares desde donde se conectan los usuarios en la medida de lo posible.
De preferencia hacerlo por servicios. Por ejemplo los trabajadores de finanzas solamente
podrán conectarse desde sus oficinas, pero no podrán hacerlo desde el exterior, pero si
podrán acceder a sus archivos personales desde su casa. De esta forma, aunque un ata-
cante tenga una cuenta de finanzas, no podrá acceder desde otro equipo que no sea el del
departamento.
5. Reducir al mínimo aquellos programas que corren con privilegios de administrador. En

Unix tienen activado un bit especial llamado setuid o setgid que pueden correrlos usuarios
normales con sus privilegios, pero en algún punto pueden tomar privilegios de adminis-
trador, para regresar nuevamente a los privilegios del usuario.
6. Evitar utilizar todos aquellos programas de conexión remota que envían las claves en tex-
to plano. Si se está instalando un sistema servidor evítelos completamente y proporcione
otras opciones a sus usuarios. Por ejemplo, es cada vez menos frecuente el uso del pro-
grama de telnet que permite conectarse a un servidor Unix (corriendo como servidor el
programa telnetd) para iniciar una sesión remota, pero que envía el nombre de usuario y
su contraseña en texto plano. En cambio se está extendiendo el uso de ssh (Secure Shell)
que usa un canal cifrado para el envío de datos (por el lado del servidor corre el programa
sshd). Lo mismo sucede con el servicio de ftp (file transfer protocol) por su contraparte
sftp (secure file transfer protocol) que abre primero una sesión ssh para enseguida trans-
ferir la información cifrada entre el cliente y el servidor. En el lado del servidor corre el
programa sftpd o algún otro.
7. Ser extremadamente cuidadosos con las relaciones de confianza. Si se dice que confiamos
en un sistema es por que se confía completamente en su seguridad tanto como en la nues-
tra. El problema es que cualquier usuario de ese sistema puede iniciar una sesión en el
nuestro sin pedirle una contraseña.
8. Establecer una política de cuentas adecuada. Desactivar las cuentas que crea por defecto
el sistema cuando se instala, por ejemplo, la cuenta de invitado en windows, debido a que
es común que no tengan contraseña.
9. Evitar contraseñas débiles en el sistema. Esto puede lograrse aumentando los requerimien-
tos para las contraseñas seguras o corriendo programas para romper las contraseñas antes
de que otros lo hagan. De esta forma se le indica al usuario que la cambie por otra más se-
gura. Así mismo se recomienda cambiar las contraseñas después de un tiempo razonable.
10. Establecer una política de caducidad después de cierto tiempo en que no haya sido utili-
zada la cuenta.
Detección de la intrusión Aún después de haber prevenido la intrusión siguiendo los puntos
anteriores, debemos ser capaces de saber si se ha dado alguna en el sistema o no. A continuación
se dan algunas guías generales que permitirán conocer si hemos sido afectados.
1. Verificación continua de los logs del sistema para detectar actividades sospechosas.
2. Monitorear los procesos en ejecución para detectar aquellos que lleven corriendo mucho
tiempo. Es común que difieran en una o dos letras con respecto a los nombres de los
procesos normales, por eso hay hacerlo con mucho cuidado para poder detectarlos.
3. Verificar los sistemas de archivos en busca de archivos setuidados en el sistema. Si un

intruso ha conseguido entrar es común que guarde estos archivos para conseguir acceso
con privilegios después.
4. Es normal también que un intruso cree directorios que consisten de puntos por ejemplo,
“...” para hacerlo parecer como el directorio “..” que significa regresar al nivel anterior en
la estructura de directorios.
5. Verificar continuamente los directorios de los usuarios para saber si no contienen archivos
o directorios que no pertenezcan a el usuario, o en el peor de los casos que existan pro-
gramas setuidados o setgidados También la existencia de programas C debe de evaluarse
con cuidado para descartar la posibilidad de aprovechar alguna vulnerabilidad como por
ejemplo el desborde de pila.
6. Verificar también las conexiones de red que están establecidas tanto las internas, como las
externas. Si encuentra alguna que viene de Rusia debería preguntarse si su jefe anda de
vacaciones o estamos en problemas.
Recuperación de una intrusión Una vez que se ha detectado que un intruso ha logrado rom-
per la seguridad de nuestro sistema, lo que debemos hacer primeramente es aislar el sistema del
mundo exterior. Preferentemente debe de desconectarse inmediatamente de la red, incluso de la
local. En el caso de que sea muy complicado dejar fuera de servicio el sistema, debe bloquearse
al menos la cuenta del usuario que sirvió como punto de entrada para el ataque. Esto no significa
que el usuario no haya tenido la oportunidad de escalar sus privilegios o que no haya podido
hacerse de más de una cuenta, es solamente una medida para evitar más daños. no obstante, in-
dependientemente de bloquear la cuenta, tan pronto sea posible el sistema deberá desconectarse
para poder evaluar completamente los daños.
Ya que el sistema se encuentra aislado debe de procederse con calma. En ocasiones es más
peligroso un administrador desesperado que actúa sin pensar las consecuencias de sus actos. Por
ejemplo, puede ser capaz de borrar archivos que dejen inutilizado el sistema por considerarlos
sospechosos simplemente por que nunca se dio a la tarea de revisar cual era su función o motivo
por el cual están en ejecución. Esto suele ser cierto para aquellos servicios obscuros, como un
servidor de fuentes o uno de sincronización de tiempo.
Después de calmarse, lo primero que debe hacerse es revisar, lo más exactamente posible, la
fecha de la primera intrusión. Esta puede averiguarse preguntando al dueño de la cuenta cuando
fue la última vez que la utilizó (suponiendo que no haya motivos para desconfiar de éste). La
fecha puede darnos un indicio de cuanto tiempo tuvo el intruso para poder modificar el siste-
ma. Aunque usando shells automatizados, pueden instalar muy rápidamente la mayoría de los
programas necesarios para asegurarse dos o más cuentas, junto con sus correspondientes puer-
tas traseras. En esta parte entramos en la fase de investigación y puede durar mucho tiempo.
Incluso, para este tipo de situaciones existen equipos a nivel mundial que se encargan de rea-
lizar estudios muy detallados sobre el nivel de intrusión. A estos estudios se les llama análisis
forense. En México, es el equipo UNAM-CERT (Equipo de Respuesta a Incidentes de Segu-
ridad en Cómputo) de la UNAM (Universidad Nacional Autónoma de México) la encargada de
responder a cualquier tipo de incidente relacionado con la seguridad.
De ser posible, debe llamarse inmediatamente a alguno de estos equipos de expertos. En
caso de que no sea así, debemos entonces proseguir nosotros.
Después de todo lo anterior se deben de fijar claramente cuales son los objetivos que pre-
tenden alcanzarse después de una intromisión. A continuación se da una lista detallada de todos
estos posibles objetivos.
1. Ignorar la intrusión. Suponer que no ha pasado a mayores y que en algún momento se

aburrirá y se irá (Sabemos muy bien que no lo hará y que los daños pueden ser después
más graves).
2. Evitar tiempos muertos del sistema. Poner en funcionamiento el sistema en el menor

tiempo posible. Esto puede lograrse de varias formas, cancelar la cuenta, buscar todos los
posibles archivos modificados, restaurarlos con los originales y continuar con el servicio.
Esta estrategia no asegura que podamos encontrar todos los archivos afectados.
3. Detectar al intruso, reunir pruebas y sancionarlo. Se entra en la parte legal y debe de

procederse con mucha cautela para poder lograrlo, Estamos ahora enfrentando una cacería
en donde la presa lleva la ventaja. Lo único a favor que tenemos es el suponer que aún no
se entera de que ya sabemos que el intruso está en el sistema. Si tenemos la seguridad de
que le intruso no sabe que ya lo detectamos, es posible tenderle una trampa. A este método
se le llama jaula que explicamos muy brevemente en la sección 6.1.2 de la página 316.
De todas formas, Se debe de procurar hacer un respaldo de toda la información importante

para evitar mayores daños. El problema de este enfoque es precisamente la complejidad
que implica ponerle la jaula al intruso sin que este se dé cuenta. Además convencer a un
juez de la intrusión será muy complicado. La mayoría de las empresas no querrá invertir
dinero a menos que la información extraída valga la pena.
4. Restaurar el sistema operativo. Esto se logra haciendo un respaldo de toda la informa-

ción del sistema y luego proceder a reinstalar el sistema operativo completo. Esta estra-
tegia tiene la ventaja de que no es necesario buscar qué archivos fueron modificados por
el intruso para convertirlos en puertas traseras. El problema es que implica más tiempo.
Además, en ocasiones sería muy difícil saber qué técnica o vulnerabilidad usó el atacante
para conseguir su objetivo. Si lo hizo con el primer sistema, no será complicado que vuel-
va a hacerlo con el nuevo. Es por esto que es muy importante analizar concienzudamente
todos los datos disponibles y determinar cual fue el problema que permitió el acceso al
intruso.
5. Implementar un sistema paralelo Si se tiene otro equipo de características similares, es

posible también mantener el sistema atacado aún en línea y reuniendo las pruebas nece-
sarias contra el intruso, mientras que, paralelemente en el segundo equipo se prepara el
nuevo sistema desde cero, con la vulnerabilidad detectada y corregida. Este enfoque tiene
todas las ventajas de las estrategias anteriores. permite averiguar en donde estuvo la falla,
reunir pruebas en contra de atacante y mantener en servicio el sistema.
6.7. Cifrado
La criptografía de hecho, no es parte del sistema operativo propiamente dicho. Se usa un al-
goritmo de cifrado para mantener segura la lista de contraseñas, pero no puede mantener cifrado,
por ejemplo, todo el sistema de archivos u otras funciones.
No obstante, como vimos en la sección anterior, es importante mantener las contraseñas
seguras y la única forma es mediante el cifrado. El algoritmo usado en Unix es unidireccional,
quiere decir que una vez cifrada la contraseña será relativamente imposible descrifrarla a partir
de la contraseña misma. En otras palabras se tiene el programa de cifrado pero no se tiene el
complemento para descifrarlo. ¿Entonces cómo hace el sistema operativo para comparar las
contraseñas? Simplemente cifra la contraseña introducida por el usuario y la compara con la
contraseña cifrada almacenada si coinciden inicia la sesión y si no, se rechaza.
La ventaja de este esquema es que ni siquiera el superusuario podrá ver la contraseña sin
cifrar de otro usuario.
346 6.7. CIFRADO
La desventaja es que alguien que tenga las contraseñas cifradas podrá seguir la misma lí-
nea del sistema operativo, intentará cifrar tantas contraseñas como tenga almacenadas en su
diccionario y las comparará con las cifradas existentes en el sistema. Cuando encuentre una
coincidencia en el diccionario, habrá “descifrado” la contraseña.
6.7.1. Principios básicos de cifrado

Una manera de mejorar la seguridad en los sistemas informáticos es cifrar los registros y
archivos sensibles, ya sea en el disco duro o que se encuentren en tránsito en la red. En la figura
6.6 podemos ver el esquema básico de cifrado y descifrado.
El objetivo principal de la criptografía es tomar un archivo o mensaje, denominado texto
simple o texto plano y convertirlo en un texto cifrado de modo tal que solamente las perso-
nas que tengan la llave podrá descifrarlo para convertirlo de nuevo en texto plano. Todas las
demás persona verán solamente un montón incomprensible de bytes. Los algoritmos de cifrado
y descifrado deben ser públicos. Los pocos que ocultan esos algoritmos pueden caer en el error
de pensar que no podrá ser descubierto el algoritmo. A este método se le denomina seguridad
por ocultamiento. Puede pensarse igual en el diseño de un kernel: el hecho de que las personas
no conozcan el código no significa que no puedan encontrar vulnerabilidades en comparación
con aquellos sistemas de código abierto. Este comportamiento lo podemos ver en las grandes
compañías de software.
Entonces, si todo el mundo puede tener acceso a los algoritmos ¿Como se asegura de que
los archivos no podrán ser descifrados por gente no autorizada?
La respuesta a la pregunta se encuentra sencillamente en los parámetros que se proporcionan
a los algoritmos. Uno de ellos, se le denomina llave o clave.
En la figura 6.6 tenemos el esquema básico de un sistema de cifrado. Consta de dos módulos:
el módulo de cifrado que tiene como entrada un texto plano P y una clave de cifrado k. Después
se tiene una línea de comunicación insegura, que puede cambiarse por un disco duro en una
oficina insegura y por último tiene el módulo que se usa para descifrar el texto. Ahora recibe el
texto cifrado C, la clave correspondiente m y da como salida el texto plano P.
Hay dos clasificaciones generales para los sistemas de cifrado:
1. Esquemas simétricos. Es aquel que utiliza la misma clave para cifrar y descifrar el texto
o mensaje.
2. Esquemas asimétricos. Utiliza claves distintas, una para cifrar y otra para descifrar el
mensaje.
El arte de descubrir las claves utilizadas para el cifrado se le denomina criptoanálisis.

Figura 6.6: Un modelo sencillo de un sistema de criptografía
Existen tres tipos de ataques para romper los códigos de cifrado:
1. Ataque del texto cifrado. Sucede cuando un adversario entra en posesión del texto cifrado
y aplica técnicas estadísticas del lenguaje para intentar determinar el código usado.
2. Ataque usando texto conocido. Ocurre cuando el atancante tiene en su poder el texto
cifrado y además posee también el texto plano y su correspondiente texto cifrado.
3. Texto plano con el algoritmo de cifrado. Es el más peligroso debido a la facilidad que
tiene para generar texto cifrado y poder compararlo con el que se quiere descifrar.
Las características que debe cumplir todo sistema de cifrado son:
1. Confidencialidad. Permite que cifremos un mensaje con la clave pública. de la persona a

la que va dirigido. Así sólo ella podrá descifrarlo utilizando su clave privada.
2. Autenticidad. Sólo el dueño de la clave privada puede codificar el mensaje, y puede leerlo
toda aquella persona que conozca la clave pública. Esta característica es útil para garanti-
zar el origen del mensaje. Es común que en vez de cifrar el texto del mensaje completo, se
cifre solamente un resumen del mismo que se adjuntan al final del mensaje (El resumen
sin cifrar y el resumen cifrado).
3. Integridad. El que lee el mensaje, si desea verificar la autenticidad del mismo, descifrará
el adjunto elaborado en el paso anterior y lo comparará con el resumen en texto plano.
348 6.7. CIFRADO
Deben coincidir. Si no coinciden debe asumirse que el mensaje ha sido cambiado. A este
proceso se le conoce también como firma digital.
6.7.2. Cifrado tradicional

Desde que nació el lenguaje escrito se han buscado formas de mantener en secreto la co-
municación entre grupos de personas. Esto debido a que también siempre ha habido terceras
personas que quieren obtener beneficios de la información enviada de manera escrita. En resu-
men, siempre que hay alguien que desea ocultar algo (el criptógrafo) va a existir también otra
persona que quiere averiguar el contenido (el criptoanalizador).
La primera persona de la que se tiene un registro histórico sobre criptografía, incluido el
método para cifrar y descrifrar, fue Julio César. El método era simple: consistía en sustituir cada
letra de un mensaje por la tercera siguiente en el alfabeto.
Al parecer no fue la única persona en utilizarlo. Existen evidencias de que los griegos y
egipcios utilizaban sistemas parecidos. También otras civilizacines más antiguas como Mesopo-
tamia, china e India tenían también métodos de criptografía.
En los siglos XV y XVI, los sistemas de intercambio simples evolucionaron posteriormente
al elegir una reordenación arbitraria o permutación del alfabeto, de tal manera que cada letra se
corresponde con otra, ya sin ningún patrón determinado.
La seguridad de los métodos explicados en los párrafos anteriores pueden ser más o menos
buena, ésta va a depender del tiempo, la información adicional y de la complejidad del sistema
con que cuente el atacante. no importa qué tan complejo sea, aún tiene las siguientes desventajas:
1. Sólo sirven para dificultar la lectura de la información. No asegura que no puedan ser
descifrados.
2. Hace falta sincronizar las claves por persona con la que nos queremos comunicar (la que
nos dé él, y la que usamos para él).
3. Es necesario tener contacto personal para intercambiar las claves o usar una vía de comu-
nicación segura y que no pueda ser interceptada. (Cifrar lo cifrado).
4. Se pueden hacer ataques aprovechando las propiedades estadísticas conocidas de los len-
guajes naturales, tal como la ocurrencia de algunas palabras comunes. por ejemplo, en el
español los artículos (el, la, los) y las propiedades de las sílabas, disílabas, trisílabas, entre
otras. Todo ello puede hacerse en un tiempo relativamente corto con el uso de computado-
ras y diccionarios del lenguaje utilizado.
La principales ventajas son:
1. Simplicidad. Es muy simple de entender y de implementar.
2. Rapidez. No se necesita de mucho tiempo, de máquinas o computadoras para cifrar o

descifrar los mensajes.
A los métodos nombrados anteriormente se les conoce como cifrado por sustitución. Fun-
cionan reemplazando cada símbolo o grupo de símbolos del texto plano por otros símbolos con
el fin de ocultar los originales.
6.7.3. La norma de cifrado de datos (DES, Data encryption estándar)

Como se habrá notado, es relativamente fácil romper sistemas criptográficos usando la compu-
tadora y algunas técnicas estadísticas del lenguaje. Por lo tanto, es necesario utilizar algoritmos
de cifrado que no tengan debilidades estadísticas o matemáticas y además que sean computacio-
nalmente imposibles de descubrir de modo que pueda desalentarse cualquier intento de este tipo.
También, el costo computacional debe ser razonable, tanto en el cifrado como en el descifrado
del mensaje.
Un algoritmo que se piensa que cumple estas características es el desarrollado por IBM y
que se adoptó como norma en 1977. Este algoritmo se llama DES.
Este algoritmo opera sobre bloques de 64 bits u 8 bytes de entrada . El proceso de cifrado
recibe como parámetro una clave de 56 bits que es dado por el usuario. El espacio de claves
contiene entonces 256 combinaciones posibles. Cada bit del bloque de salida es una función
compleja de cada bit del bloque de entrada y de cada bit de la clave. DES utiliza cifrado simétri-
co. Este algoritmo tiene una estructura tal que el proceso de descifrado es el inverso exacto del
proceso cifrado. A continuación se muestran los pasos del algoritmo de cifrado DES:
1. I0 D0 = t(entrada).
2. Repetir para n = 1 a 16.
In = Dn−1
L
Dn = In−1 f (Dn−1 , Kn )
3. Salida = t−1 (I16 D16 )
El algoritmo realiza una transposición inicial, t, usando una permutación de la entrada de 64

bits. El resultado es dividido a la mitad, o sea 32 bits designadas como izquierda, I0 , y derecha
D0 . El resultado se somete a 16 rondas de cifrado bajo el control de la clave. Después de cada
350 6.7. CIFRADO
vuelta, las mitades izquierda y derecha del resultado intermedio de 64 bits se intercambian;
la mitad izquierda pata la siguiente ronda es la mitad derecha de la anterior. La nueva mitad
derecha se obtiene calculando el XOR (OR exclusivo) de la mitad izquierda de la ronda anterior
y el resultado de una función bastante compleja de la mitad derecha de la ronda previa y la clave
de la ronda actual.
El cálculo de la función f contribuye significativamente a la complejidad computacional del
algoritmo. Sus entradas se utilizan para realizar sustituciones mediante ocho cajas de sustitución
separadas, llamadas cajas-S. Su salida combinada se permuta entonces haciéndola pasar a través
de una caja de permutaciones llamada caja-P.
Cada una de las 16 permutaciones utiliza una clave diferente Ki . Esta clave se obtiene efec-
tuando una serie de permutaciones y desplazamientos sobre la clave de 56 bits dada por el
usuario.
Para terminar el algoritmo en el paso 3 se aplica la inversa de la permutación inicial al
resultado de la última interacción. El descifrado se hace ejecutando los pasos descritos en orden
inverso.
6.7.4. cifrado con clave pública

La criptografía actual está basada principalmente en cifrado asimétrico. Usa por tanto codifi-
cación basada en sistemas de clave privada y pública. Cada persona tiene dos claves: una privada
(no la conoce nadie más que él) y una pública (Se le puede proporcionar a quien sea necesario).
El sistema de cifrado junto con estas claves cumplen con una propiedad importante: lo que
se codifica utilizando la clave pública, se decodifica con la clave privada, o viceversa, de manera
que utilizando las dos consecutivamente se obtiene el mensaje original.
Para completar el esquema de seguridad según el nivel que se requiera es posible utilizar:
La clave pública del destinatario. Se usa para enviarle mensajes al destinatario que debe
descifrar con su clave privada.
La clave privada personal. Para cifrar los archivos propios que no deben ser leídos por
otras personas.
Ambas claves. Para enviar mensajes cifrados firmados, de modo que el destinatario pueda
asegurarse de que realmente los envió la persona que dice ser, ya sea mediante una com-
paración de firmas digitales o mediante algún organismo que certifique la identidad de la
persona con su firma digital.
Es fácil entender que en este esquema, la seguridad la proporciona la clave del destinatario
ya que sólo él puede descifrarlo y la autenticidad del mensaje la proporciona la clave privada
que solo es conocida por su dueño. En resumen tenemos que:
La clave pública personal es conocida por todo el mundo para que envíen mensajes cifra-
dos al dueño de la clave privada.
La clave privada del dueño no se transmite por ningún medio, de esta forma se conserva
en secreto más fácilmente. Esto es, no está propensa a ser interceptada.
Si la clave pública se proporciona solamente a cierto grupo de personas se garantiza que

sólo ellos podrán leerlo. Por supuesto no se debe de proporcionar a nadie más.
El uso de la clave privada garantiza que sólo el propietario generó el mensaje, salvo que
haya sido robada. En ese caso el dueño debe de enviar un certificado de revocación a todos
a los que proporcionó su clave pública. De esta forma se inutilizará dicha clave.
Para mantener comunicación cifrada con varias personas se necesita solamente una clave
pública por cada una de ellas.
Como se dijo, para cada usuario A, la transformación privada CP rA , se describe mediante

una clave privada. La clave pública CP uA , se deduce de la clave privada utilizando una trans-
formación unidireccional cuya inversa es extremadamente difícil de calcular. Las dos transfor-
maciones están relacionadas como sigue:
CP rA (CP uA (T P )) = T P
De modo que el el descifrado de un mensaje genera el texto plano original TP. El descifrado
utiliza la clave privada. y el cifrado se hace con la clave pública
CpuA .
6.7.5. El algoritmo Rivest, Shamir, Adelman o RSA

Este algoritmo fue inventado por un grupo de investigadores del MIT, Rivest, Shamir y
Adelman, y el nombre del de algoritmo se formó utilizando sus iniciales.
El algoritmo se basa en parte en la aritmética modular. Una de sus propiedades es la posibi-
lidad de calcular inversas multiplicativas. Esto es, dado un entero e en el rango [0,n-1], a veces
es posible encontrar un número entero único d en el rango [0, n-1] tal que
ed mod n = 1
352 6.7. CIFRADO
Por ejemplo 5 y 11 son inversos multiplicativos módulo 6 ya que 55 mod 6 = 1. Se puede

demostrar que el entero e ∈ [0, n - 1] tiene un inverso multiplicativo único mod n cuando e
y n son primos relativos, es decir cuando mcd(e,n)=1. Donde mcd significa el máximo común
divisor. El número de enteros positivos que son primos relativos con n es una función denotada
como Φ(n). Para n=nq y p,q primos, se puede demostrar que:
Φ(n) = (p − 1)(q − 1)
Para un número P ∈ [0,n-1] se puede demostrar que la ecuación
C = P e mod n (6.1)
es inversa de
P = C d mod n (6.2)
Si
ed mod Φ(n) = 1, donde Φ(n) = (p − 1)(q − 1)
La ecuación 6.1 se usa para como método de cifrado para muchos algoritmos de clave pú-
blica, con e y n como claves. El descifrado se realiza con la ecuación 6.2 con d y n como claves.
Dado que la clave (e, n) es pública, sólo el número d del par de descifrado (d, n) es privado. Si d
se elige como primo relativo en Φ(n), y e se elige como inversa multiplicativa de d, entonces el
texto plano cifrado utilizando la ecuación 6.1 puede ser descifrado usando d en la ecuación 6.2.
En general estas son las ideas principales del algoritmo RSA. En términos prácticos, el al-
goritmo RSA necesita la determinación de n, d, y e mediante los siguientes pasos:
1. Elegir dos números primos grandes p y q, cada uno superior a 10100 .
2. Calcular n=pq y Φ(n) = (p − 1)(q − 1).
3. Elegir un número d como un número aleatorio grande que sea primo relativo con Φ(n),
esto es que ed mod Φ(n) = 1.
Se pueden utilizar estos parámetros para cifrar texto plano P donde 0 ≤ P < n. Si el texto
plano es más largo se debe entonces dividir en partes más pequeñas que n.
Una forma de intentar atacar este tipo de cifrado es buscar la forma de factorizar números
grandes para encontrar d a partir de la clave pública n y e. que son públicamente conocidos.
Lamentablemente para el descifrador que efectúa el ataque, encontrar los factores de núme-
ros muy grandes puede llevar una gran cantidad de tiempo que con las computadoras actuales
llega a ser prohibitivo. Tampoco ha habido trabajos que demuestren que puede haber alguna
manera más corta y computacionalmente factible para descubrir las claves del algoritmo.
6.7.6. Verificación de identidad

La verificación de identidad es necesario llevarla a cabo para asegurarse de que la persona
que envía el mensaje es realmente quien dice ser. En otras palabras, cualquiera que tenga la clave
pública será capaz de enviar un mensaje cifrado al dueño de la clave privada. A continuación se
listan los pasos para lograr la validación:
1. Ponerse en contacto personalmente o por algún medio difícil de interceptar y compartir

las claves públicas.
2. El receptor B envía al emisor A un mensaje cifrado con su clave pública CpuA . El emisor
A descifra el mensaje y lo regresa a B en texto plano.
3. El receptor B compara el mensaje en texto plano que le envió A, si coincide, entonces B

puede estar seguro de la identidad de A.
6.7.7. Firmas digitales

Las firmas digitales surgieron precisamente de la necesidad de validar a los usuarios. La ma-
yoría de las empresas que se dedican a hacer negocios en Internet están afiliados a empresas que
se dedican a mantener bases de datos en donde almacenan las claves públicas de sus afiliados.
Si alguien quiere saber si la clave pública pertenece a una corporación, simplemente debe hacer
una consulta a esas bases de datos. Claro, el servicio deben de pagarlo.
Una firma digital es una manera de marcar un mensaje electrónico de manera que sea único
y que exista una manera de verificar quien lo redactó. La idea aquí es que funcione como las
firmas autógrafas normales que se usan en transacciones con tarjetas bancarias.
Sea B el receptor de un mensaje M firmado por A. con esta definición, toda firma digital debe
de cumplir los siguientes requisitos:
No debe haber manera de falsificar la firma de A.
B Debe ser capaz de validar la firma de A en el mensaje M.
A no puede negar de ningún modo el haber enviado el mensaje M+.
En la actualidad existen muchas aplicaciones que implementan ambas funcionalidades. Aun-

que va a depender de la implementación de los algoritmos el soporte de esta funcionalidad. En
este modo de operación se debe de proceder como sigue:
1. El emisor aplica su propia transformación usando su clave privada para obtener CprA (P ).
6.8. MEDICIÓN DEL DESEMPEÑO (PERFORMANCE) DE LOS SO, MONITOREO Y
354 EVALUACIÓN
2. Cifrar el resultado utilizando la calve publica de B, CP uB .
3. Se envía el mensaje a B.
4. El receptor aplica primero su clave privada para desincriptar el mensaje.

C = CP rB (CP rA (P ))
5. Luego aplica la clave pública de A para obtener el mensaje en texto plano P.
6.8. Medición del desempeño (performance) de los SO, moni-

toreo y evaluación
Ahora que se han considerado algunos factores a tener en cuenta pasaremos a hablar de los
aspectos de optimización y desempeño más importantes que se deben de tomar en cuenta en el
desarrollo de los sistemas operativos.
Bajo las mismas condiciones de hardware, se considera que un sistema operativo es más
rápido cuando termina la misma tarea en un tiempo menor que otro. En esta situación decimos
que tiene mejor desempeño.
6.8.1. Aspectos a considerar en el desempeño

6.8.1.1. ¿Qué debe optimizarse?
Ponemos un ejemplo de qué es lo que debe optimizarse, con respecto al tiempo invertido: las
partes propias del sistema operativo. Se debe de poner especial atención sobre aquellas tareas
que se realizan un mayor número de veces en una unidad de tiempo dado. Por ejemplo, el
manejador del reloj del sistema debe ser lo más óptimo posible debido a que es usado por varios
planificadores del sistema operativo, además de que debe llevar la cuenta del tiempo. Si este
proceso fuera ineficiente cabría la posibilidad de que contara de más o de menos, haciéndolo de
esta forma inservible para su propósito.
Por otro lado, un servicio que se usa muy pocas veces a lo largo de la vida del sistema
operativo, como por ejemplo una utilería conocida como fdisk9 , que se vio en la sección 4.4.2.2
en la página 218, que se usa una vez cuando se instala el sistema y luego se usará de nuevo
cuando se agregue otro disco al sistema, y como puede verse no se hace todos los días. Sería
entonces ilógico intentar optimizarlo durante cinco meses para reducir el tiempo de creación de
la partición de un minuto a 30 segundos.
9
Se usa para crear las particiones en el disco.
6.8.1.2. Equilibrio espacio-velocidad
Cuando hablamos que un programa se encuentra completamente en RAM junto con sus
datos es indicio de que puede ejecutarse más rápidamente a que si éste se divide en módulos
que deben cargarse o que sea necesario cargar sus datos de disco. En computación, si se desea
que un programa se ejecute más rápido, entonces debe ponerse completamente en memoria.
Esto es, se debe sacrificar espacio. Al contrario, si es necesario optimizar tamaño en memoria
entonces se tendrá que sacrificar velocidad. Incluso, la mayoría de los compiladores, por ejemplo
c++ proporcionan al programador diversas formas automáticas de optimización. Obviamente las
más comunes son de velocidad y de espacio en memoria.
Existen también reglas generales en programación para optimizar con respecto a la veloci-
dad: usar macros en lugar de procedimientos. Cuando el compilador ve una macro lo que hace
es sustituir el código de la misma por su llamada, generando así un programa más grande. Si
se desea optimizarlo para tamaño, entonces deben de usarse llamadas a procedimiento. En es-
te caso, la CPU tendrá que ejecutar varias instrucciones push10 los parámetros de la llamada a
función y guardar también el apuntador de instrucción en la pila, saltar a la primera instrucción
de la función y al regresar, descartar los parámetros y ejecutar varias instrucciones pop11 para
restaurar el apuntador de instrucciones.
Como puede verse, sería una muy mala optimización si un programador pone varias llamadas
a función dentro de un ciclo que va a repetirse tal vez, miles de veces. Lo adecuado sería hacer
uso de macros, al menos en aquellos ciclos que van a repetirse muchas veces. Incluso si se desea
ganar más velocidad debe de verse la posibilidad de eliminar los ciclos.
6.8.1.3. Medición del desempeño
Después de haber tomado en cuenta el programador los aspectos de optimización concer-

nientes al desarrollo de la aplicación y el compilador también haber hecho su parte, lo último
es hacer pruebas de desempeño. La mayoría de los fabricantes de compiladores incluyen alguna
herramienta de perfilado.
El perfilado es un conjunto de técnicas que permiten analizar cómo es que se comporta
alguna aplicación dada durante su tiempo de ejecución.
Por ejemplo, para el código secuencial, a veces es suficiente con obtener datos estadísticos
sobre aspectos de ejecución, tales como el tiempo que la aplicación tarda en ejecutar una función
o alguna línea de código
10
empujar dentro del segmento de pila
11
sacar de la pila
356 EVALUACIÓN
Bajo este esquema, lo normal es que el programa se ejecute bajo la supervisión de una
herramienta de perfilado que es la que aporta información sobre el desempeño de un programa
cuando éste se termine.
Después de analizar los datos obtenidos del perfilado, es fácil ver en donde es necesario
incidir para mejorar el desempeño del código, se puede ver, por ejemplo:
1. Revisar el número de llamadas hechas a alguna función.
2. Identificar las secciones de código que se pueden optimizar.
3. Después de hacer los cambios, se puede ejecutar nuevamente el perfilado y comparar los
resultados con el primero.
Existen distintas formas de llevar a cabo el perfilado. Si es necesario medir exactamente

el tiempo transcurrido o registrar lo que pasa durante la ejecución de una parte del programa
como una función, es necesario añadir algunas llamadas al sistema que permiten contar ticks (o
pulsos) de reloj de estas partes de modo que podamos realizar estas mediciones. Estas llamadas
cuentan el tiempo transcurrido o contabilizan algún evento y calculan diferencias. Como puede
verse, es necesario cambiar el código fuente original antes de ejecutarlo. La introducción de
estas llamadas dentro del programa a perfilar se denomina instrumentación y puede realizarse
de las siguientes formas:
1. Mediante el mismo programa. por medio de uso de macros y compilación condicional.
2. Por el compilador. Mediante el uso de directivas. Es claro que el compilador debe de

soportar la generación de información para el perfilado.
3. Por la aplicación de perfilado. Éste recibe como entrada el programa y se encargará de

etiquetarlo adecuadamente para su ejecución y la obtención de estadísticas.
4. Por el sistema operativo. Puede implementarse la medida global de ejecución de una

aplicación con dos llamadas a times12 y haciendo la diferencia puede obtenerse el tiempo
total de ejecución
Debido a que las secciones de mayor interés están comúnmente anidadas, la sobrecarga
producida por las propias propias llamadas para calcular las medidas influye también en éstas.
por este motivo, la instrumentación se hace selectivamente y sus resultados deben analizarse e
interpretarse con sumo cuidado. Por estas razones el análisis de rendimiento puede convertirse
en un proceso muy complejo.
12
En un sistema basado en UNIX o GNU/Linux
6.8.2. Monitoreo
Incluso en los mejores sistemas operativos habrá procesos que se queden “colgados”, esto
es, siguen consumiendo memoria y tiempo de CPU pero ya no están haciendo un trabajo útil.
Otras veces, algunos usuarios mal intencionados hacen ciclos de peticiones erróneas para ver
si es posible ganar privilegios de administrador, lo que ocasiona que muchas de las veces el
proceso encargado de manejarlas se congele.
El sistema operativo proporciona varias utilerías que permiten conocer qué procesos se es-
tán ejecutando, quién es el propietario, qué tiempo llevan ejecutándose y qué recursos están
consumiendo entre otra información.
En Unix y GNU/Linux se tienen las siguientes utilerías que se ejecutan a nivel de línea de
órdenes:
1. ps. Permite mostrar información relativa a los procesos que se están ejecutando actual-
mente en el sistema.
2. top. Permite mostrar en tiempo real los procesos que se están ejecutando actualmente, el
tiempo de ejecución, la cantidad de memoria que ocupan y el tiempo de procesador que
usan, entre otra información.
3. pstree. Muestra a los procesos que se están ejecutando en forma de árbol de modo que
puede verse fácilmente quienes son los procesos padre y quienes son los procesos hijo.
En un sistema basado en windows tenemos al administrador de tareas quien es el que pro-

porciona toda la información relativa a los procesos y a la carga del sistema
Con este conjunto de herramientas, el administrador del sistema puede ver la carga actual
del sistema y decidir si debe eliminar aquellos procesos que hayan quedado “congelados” para
poder liberar sus recursos y mejorar el rendimiento general del sistema. O en su defecto, si
el sistema está muy cargado, puede entonces decidir eliminar aquellos procesos que no sean
prioritarios en ese momento y reiniciarlos más tarde, cuando la carga del sistema sea menor.
También es capaz de eliminar sesiones de usuarios que hayan infringido el tiempo de uso del
procesador o de algún otro recurso.
Otro aspecto que actualmente debe de tomarse en cuanta es el monitoreo de la red. El sistema
operativo proporciona también varias utilerías que permiten diagnosticar es estado de las inter-
fases de la red, el tiempo de respuesta de algún servidor remoto o el número de saltos que debe
de hacer un paquete para llegar a su destino. A continuación hacemos una breve descripción de
esas órdenes para un sistema UNIX o GNU/Linux.
358 EVALUACIÓN
1. ping. Se usa para saber si un servidor puede responder peticiones de red. La mayoría de
las veces simplemente indica si una computadora o servidor se encuentra activo.
2. traceroute. Permite observar las computadoras o servidores por los que pasa un paquete
antes de llegar a su destino. Se usa también para encontrar o diagnosticar problemas en la
red.
3. dig. Permite hacer peticiones a un servidor de nombres, de esta forma sabemos si es po-
sible o no tener acceso a los servicios de internet mediante el nombre de dominio o si
pueden acceder a nuestros servidores mediante nuestro propio nombre de dominio.
Para un sistema Windows son las mismas órdenes, pero en vez de usar dig debe de usarse
nslookup. También traceroute cambia por tracert.
Los sistemas operativos proporcionan al administrador gran cantidad de información que
va guardándose en los registros del sistema. Esta información incluye todos los eventos que se
generaron desde el momento de arrancar el sistema hasta los generados por las aplicaciones. En
UNIX y GNU/Linux se guardan en el directorio /var/log.
En los sistemas Windows se usa una aplicación llamada registro de eventos que es quien
informa qué es lo que ha sucedido en el sistema.
Un buen administrador del sistema debe monitorear continuamente los logs del sistema para
detectar si existen errores del sistema o para prevenir o incluso detener un ataque cibernético en
potencia. Existen muchas herramientas que analizan automáticamente los logs generados por el
sistema y mediante un conjunto de heurísticas pueden determinar con cierto grado de exactitud
si estamos ante la presencia de un ataque o si el sistema está funcionando normalmente.
6.8.2.1. Utilerías del sistema para visualizar los logs

El esquema más básico es usar los visores de archivos de texto incluidos en el sistema, por
ejemplo, less, more o cat. En el siguiente listado se observa un corto fragmento del archivo
/var/log/syslog:
Jan 21 06:54:59 debian kernel: 127MB HIGHMEM available.
Jan 21 06:54:59 debian kernel: 896MB LOWMEM available.
Jan 21 06:54:59 debian kernel: found SMP MP-table at 000f5480
Jan 21 06:54:59 debian kernel: On node 0 totalpages: 262128
Jan 21 06:54:59 debian kernel: DMA zone: 4096 pages, LIFO batch:0
Jan 21 06:54:59 debian kernel: Normal zone: 225280 pages, LIFO batch:31
Jan 21 06:54:59 debian kernel: HighMem zone: 32752 pages, LIFO batch:7
Jan 21 06:54:59 debian kernel: DMI 2.3 present.
Jan 21 06:54:59 debian kernel: ACPI: RSDP (v000 GBT ) @ 0x000f6da0
Jan 21 06:54:59 debian kernel: ACPI: RSDT (v001 GBT AWRDACPI 0x42302e31 AWRD 0x01010101) @ 0x3fff3000
Jan 21 06:54:59 debian kernel: ACPI: FADT (v001 GBT AWRDACPI 0x42302e31 AWRD 0x01010101) @ 0x3fff3040
Jan 21 06:54:59 debian kernel: ACPI: MADT (v001 GBT AWRDACPI 0x42302e31 AWRD 0x01010101) @ 0x3fff65c0
Jan 21 06:54:59 debian kernel: ACPI: DSDT (v001 GBT AWRDACPI 0x00001000 MSFT 0x0100000c) @ 0x00000000
Jan 21 06:54:59 debian kernel: ACPI: PM-Timer IO Port: 0x1008
Jan 21 06:54:59 debian kernel: ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
Obsérvese que syslog proporciona un informe detallado acerca del hardware que tiene el
equipo y su estado, por ejemplo si está habilitado o deshabilitado.
Otro archivo importante por revisar es el de accesslog. Este archivo contiene los accesos
realizados al sistema:
Nombre Puerto De Último
root tty1 mié ene 16 07:06:30 -0600 2008
www-data **Nunca ha entrado**
Debian-exim **Nunca ha entrado**
nalonzo :0 mié ene 23 03:35:09 -0600 2008
postgres **Nunca ha entrado**
identd **Nunca ha entrado**
lucy :0 mié oct 3 13:17:12 -0500 2007
Para obtener resúmenes de los informes es necesario hacer uso de utilerías llamadas anali-
zadores de logs. Podemos encontrar en la red una gran variadad de éstos, con diferentes capaci-
dades de resumen y de visualización. Existen también muchos analizadores que se especializan,
por ejemplo, en obtener estadísticas de acceso a los servidores WEB como AWStats o sobre el
uso de la red como ntop.
6.8.3. Evaluación
Después de haber obtenido las estadísticas de perfilado es conveniente hacer una evaluación
completa del sistema operativo. Esta evaluación puede incluir la comparación con otros siste-
mas para determinar las ventajas en ahorro de memoria, tiempo de CPU o desempeño de las
aplicaciones.
También es importante saber qué tipo de sistema operativo debe de usarse de acuerdo al
hardware que se tiene. No es lo mismo tener un hardware servidor dedicado a una computadora
personal. Los tipos de aplicaciones que se ejecutan no son los mismos. Incluso en ocasiones,
no es posible comparar el desempeño de juegos entre una computadora personal y una estación
dedicada.
La perspectiva del usuario es otro punto que debe considerarse adecuadamente. En la sección
5.6.2 en la página 287 se dio una lista de varios de los tipos de servicios que puede ofrecer un
servidor. Cada aplicación requiere diferentes recursos y depende mucho también del número de
usuarios a los que se requiere proporcionar el servicio. A mayor cantidad de usuarios, mayores
serán los requerimientos del hardware y por ende se requiere también un sistema operativo más
eficiente.
En resumen los puntos más importantes que deben tenerse en cuenta para seleccionar un
buen sistema operativo o aplicación son, entre otros:
1. Hardware. Éste se escoge de acuerdo al uso que se le dará a la computadora.

360 EVALUACIÓN
2. Aplicaciones. Qué tipo de aplicaciones ejecutará nuestro hardware. Por ejemplo, los cálcu-
los científicos requieren más eficiencia de cálculo que la edición de un texto.
3. Interfaz con el usuario. Qué tan necesario es contar con una interfaz agradable al usuario.
En ocasiones se prefiere la rapidez a la facilidad de uso. Por ejemplo, un servidor de
páginas WEB.
4. Cantidad de usuarios a ser atendidos. No es lo mismo atender a cinco usuarios a tener

que atender a quinientos o mil usuarios en el mismo periodo de tiempo.
5. Costos de licenciamiento. Si se está dispuesto a pagar por el sistema operativo y las

aplicaciones o no se cuenta con los recursos necesarios.
6. Software de código abierto (opensource). ¿Es necesario hacer modificaciones al soft-

ware para adecuarlo a nuestras necesidades? o la aplicación que usamos cumple todas
nuestras expectativas. El código abierto no significa que sea gratuito.
7. Software propietario o software libre. ¿Qué tanto conviene comprar software propieta-
rio? ¿Es más barato el software libre? El hecho de decir que no se paga por el software
libre, no indica que es gratis.
Todo lo anterior se resume en el cálculo del costo total de propiedad que analizaremos en el
siguiente apartado.
6.8.3.1. Costo total de propiedad
El costo total de propiedad es en general un análisis de costos que incluye la adquisición de

hardware, sistema operativo, aplicaciones, gastos de salario para administradores de sistemas,
tiempos muertos, y costos de instalación, por citar algunos.
Por ejemplo, supóngase que se va a realizar la compra de una televisión, un horno de micro-
ondas, un refrigerador o un automóvil. La mayoría de la gente lo primero que ve es el precio,
puesto que es lo que va a pagar a corto plazo. Muy pocas veces se ve el consumo de energía
del horno de microondas o del refrigerador, el costo de servicio del automóvil o el costo de
las refacciones. Tampoco se revisa si el refrigerador, que cuesta $500 ó $1,000 pesos más, va a
salir más barato a largo plazo porque consume el 60 % de energía diariamente para mantener la
misma temperatura.
Para obtener una fórmula general que pueda ser útil en un caso determinado es necesario
contar con mucha información.
Lo primero que hay que saber es el costo inicial de la solución, que puede definirse como:
Costo Inicial de la Solución:

Cinicial = Chardware + Csof tware + Cinstalacion + Cconf iguracion
donde:
Chardware = Costo del Hardware requerido.
Csof tware = Costo del Software incluido sistema operativo y aplicaciones.
Cinstalacion = Costo de la instalación inicial.
Cconf iguracion = Costo de la configuración del sistema operativo y las aplicaciones.
Hasta ahora se ha indicado solamente los costos de la instalación inicial, que va desde des-
empacar el hardware, el software, instalarlo y configurarlo para que empiece a funcionar.
Es claro que mientras se tenga mayor información se puede hacer la ecuación tan compleja
como sea necesario.
El siguiente paso es calcular los costos de operación. Dentro de éstos se deben responder al
menos las siguientes preguntas:
1. ¿Cuántos ingenieros y personal de soporte técnico se requieren para poder operar de forma
eficiente y dar el servicio que los usuarios del sistema necesitan?
2. ¿Cuántos administradores de sistemas son necesarios para poder administrar y operar los
servidores que comprenden la nueva solución?
3. ¿Necesito pagar capacitación adicional para tener autonomía en el soporte de la solución?
4. ¿Puede hacerlo el personal o es necesario contratar personal externo o servicios de con-

sultoría del proveedor de la solución?
5. ¿Cuánto cobra el soporte o servicio del proveedor para que apoye en la solución de pro-
blemas de la aplicación?
6. ¿Será necesario modificar la solución en el período de tiempo que va a estar funcionando

la aplicación?
7. ¿Qué alternativas ofrece el fabricante para poder acceder a nuevas versiones, actualizacio-
nes de seguridad, etc.?
8. ¿Qué tan amigable al usuario es la solución adquirida?
9. ¿Es posible conseguir el personal adecuado para operar y administrar la solución?
En resumen, podemos elegir algunas de las preguntas anteriores o englobarlas en conceptos

más amplios:
362 6.9. PROBLEMAS
Costo de Administración (Cadministracion ). Se define por el costo anual que genera todo
el personal (interno y/o externo) para poder mantener el funcionamiento diario de la solu-
ción. Que va desde la administración de usuarios y permisos, hasta las operaciones diarias
de mantenimiento de respaldos y verificación de logs, por citar algunos.
Para aclarar un poco más los costos de administración quedarían:
Cadministracion = Costo anual de un administrador o ingeniero (interno o externo) * número
de ingenieros de planta * número de años de la solución en funcionamiento * porcentaje
de tiempo dedicado a la solución .
Costo de Operación (Coperacion ). Los costos de operación incluyen aquellos factores de

mantenimiento preventivo y correctivo, tanto de hardware como de software, como la lim-
pieza del hardware, cambio de discos, memoria, actualizaciones de software. Además se
incluyen también todos los gastos generados por la pérdida de operación o soporte reac-
tivo de la solución, extendiéndose a caídas por virus, gusanos, intrusos y otros problemas
de este tipo.
El Costo de operación puede calcularse como:
Coperacion = Número de incidentes promedio por año * número de años de la solución en
funcionamiento * costo por hora de servicio * tiempo aproximado para reparar la falla.
Costo de Soporte a usuarios (Csoporte ). Está compuesto por todos los costos ocasionados
por cualquier tipo de soporte dado a los usuarios finales de la solución.
Csoporte = número de incidentes promedio por año * número de años de la solución en
funcionamiento * costo por hora de soporte * tiempo aproximado para dar el soporte
requerido.
Como puede verse se intentó incluir el mayor número de casos, pero pueden incluirse todavía
otros otros aspectos que puede incidir directamente el costo total de propiedad.
A continuación se resume la ecuación que permite calcular el costo total de propiedad y que
usando los mismos parámetros puede entonces servir para compararlo con otras soluciones.
Costo de soluciones de software = Cinicial + Cadministracion + Coperacion + Csoporte .
6.9. Problemas
6.1. Defina con sus propias palabras los término desempeño y seguridad.
6.2. ¿Cuándo se considera que un sistema operativo tiene mejor desempeño?

6.3. ¿Qué debe optimizarse en un sistema operativo?
6.4. Explique por qué existe un compromiso entre tamaño de programa y su velocidad de
ejecución.
6.5. Como programador, ¿Cuáles son las reglas de optimización que debe de manejar, tanto
para memoria como para velocidad?
6.6. ¿Qué es el perfilado?
6.7. ¿Cuáles son las formas de implementar la instrumentación?
6.8. ¿A que se refiere el término programa “colgado” o “congelado”? Explique.
6.9. Explique las órdenes que dispone UNIX/Linux para ver los recursos que consumen los
procesos en ejecución.
6.10. ¿Cómo se llama la herramienta de Windows para ver los procesos en ejecución y los
recursos que consumen?
6.11. ¿Cuáles son las utilerías que se usan para monitorear la red? Explique cada una de ellas.
6.12. ¿Para que sirven los archivos logs?
6.13. Describa los archivos de logs más importantes.
6.14. Proporcione una definición de cada utilería para revisar los logs del sistema.
6.15. ¿Por qué es necesario hacer una evaluación del sistema operativo?
6.16. ¿Cuáles son los puntos más importantes que deben tenerse en cuenta para la selección
de un sistema operativo?
6.17. Defina qué es el costo total de propiedad.
6.18. Proporcione la fórmula del costo inicial de la aplicación.
6.19. Proporcione la fórmula de los costos de operación.
6.20. Proporcione la fórmula de los costos de administración.
6.21. Proporcione la fórmula de los costos de soporte.
6.22. Proporcione la fórmula del costo de la solución del software.

364 6.9. PROBLEMAS
6.23. ¿Qué es la seguridad?
6.24. Defina el concepto de seguridad física.
6.25. Defina el concepto de seguridad lógica.
6.26. ¿Qué puntos debe cubrir el concepto de seguridad informática? Explique cada uno de
ellos.
6.27. ¿Cuáles son las amenazas de las tres metas de seguridad en sistemas de computación?
6.28. ¿Qué es un intruso? Defina las dos clasificaciones para los intrusos.
6.29. ¿Cuáles son las consecuencias de la pérdida de datos?
6.30. Defina la pérdida de datos.
6.31. Enumere las causas más comunes de pérdida de datos.
6.32. ¿Cuál es la manera más económica para prevenir la pérdida de datos?
6.33. ¿Qué es un ataque a un sistema de computadora?
6.34. ¿A qué se refiere la ingeniería social? Explique los pasos que sigue esta técnica.
6.35. ¿Qué es un caballo de Troya?
6.36. Explique el concepto de falsificación de inicio de sesión.
6.37. Explique el concepto de bombas lógicas.
6.38. ¿Qué es una trampa?
6.39. ¿Qué es un ataque externo?
6.40. ¿Qué es una puerta trasera?
6.41. Explique la técnica de desbordamiento de búfer.
6.42. ¿Cómo puede evitarse el ataque de desbordamiento de búfer?
6.43. Proporcione la definición de virus.
6.44. ¿Qué daños puede ocasionar un virus?
6.45. ¿Cuáles son las principales formas de propagación de un virus?

6.46. ¿Qué es un gusano informático?
6.47. ¿Por qué es necesario vigilar algunos usuarios sospechosos?
6.48. ¿Qué es una jaula?
6.49. ¿Qué es la protección?
6.50. ¿Cuál es la diferencia entre seguridad y protección?
6.51. Explique el concepto de privilegio mínimo.
6.52. ¿Por qué es necesaria la autentificación de usuario?
6.53. ¿Cuáles son las estrategias de autentificación de usuarios? Explíquelas.
6.54. ¿Qué es una cuenta de usuario?
6.55. ¿Qué es un hacker y un cracker?
6.56. Explique la técnica de ataque a diccionario.
6.57. ¿Qué es un marcador bélico?
6.58. Mencione las reglas para construir contraseñas fuertes.
6.59. ¿Qué es un dominio?
6.60. ¿Cómo está estructurada una matriz de acceso?
6.61. ¿Cuáles son los tipos de acceso más comunes?
6.62. ¿A qué se le denomina lista de control de acceso?
6.63. Defina una TCB.
6.64. ¿Para que se llevan a cabo auditorías del sistema?
6.65. ¿Cuál es la función del demonio syslog?
6.66. ¿Qué información guarda el archivo syslog?
6.67. ¿Que información guarda el archivo lastlog y sulog?
6.68. Explique el control de acceso basado en roles.

366 6.9. PROBLEMAS
6.69. Indique los pasos más importantes que debe implementar cualquier sistema operativo
en lo que se refiere a seguridad y protección
6.70. Explique cómo se implementa la seguridad por hardware.
6.71. Explique cómo se implementa la seguridad por software.
6.72. Proporcione la definición de criptografía.
6.73. ¿Cuál es el objetivo principal de la criptografía?
6.74. ¿Para qué sirve una llave pública y una privada?
6.75. Explique las dos clasificaciones generales para los sistemas criptográficos.
6.76. ¿Cómo se le llama al esquema que utiliza la misma clave para cifrar y descifrar el texto?
6.77. ¿Cómo se le llama al esquema que utiliza diferentes claves para cifrar y descifrar el
texto?
6.78. ¿Cómo se le llama al arte para descubrir las contraseñas utilizadas en el cifrado?
6.79. Explique los tres tipos de ataque para romper los códigos de cifrado.
6.80. ¿Cuáles son las características que debe de cumplir cualquier esquema de cifrado?
6.81. ¿Qué es una firma digital?
6.82. Haga un breve bosquejo histórico de la criptografía tradicional.
6.83. ¿Qué siginifica DES?
6.84. ¿Para qué sirve la llave pública en el cifrado asimétrico?
6.85. ¿Para qué sirve la llave privada en el cifrado asimétrico?
6.86. Describa de forma general el algoritmo RSA.
6.87. ¿Para que sirve el proceso de verificación de identidad?
6.88. ¿Por qué es necesario hacer simulacros de penetración al sistema operativo?
6.89. ¿Cómo se les llama a estos grupos de penetración?
6.90. ¿Cuáles son las actividades más comunes de un intruso?

6.91. ¿Cuáles son las acciones que deben de llevarse a cabo para evitar en la medida de lo
posible intrusiones al sistema?
6.92. ¿Qué pasos se deben de seguir para poder detectar una intrusión?
6.93. ¿Qué debe hacerse en caso de haber detectado una intrusión?
6.94. ¿Cuál es la función de un equipo de respuesta a incidentes de seguridad?
6.95. ¿Cuáles son los objetivos que pretenden alcanzarse después de detectar una intromisión
al sistema?

Hay demasiado material como para poder llenar muchos libros sobre seguridad, para empe-
zar, los criterios federales establecidos por la National Institute of Standards & Technology and
National Security Agency los podemos encontrar en [78].
Bishop[15] describe las vulnerabilidades de la red y de un sistema UNIX.
Villalón[50] conjuga adecuadamente la teoría y la práctica y proporciona todo lo necesario
para poseer un sistema basado en UNIX relativamente seguro. Heydon y Tygar[47] proporciona
un conjunto de restricciones de seguridad para UNIX. Wensel[105] habla sobre algunos aspectos
de la seguridad del sistema de archivos de unix. Iyer[53] habla sobre los aspectos generales de
seguridad en internet y en UNIX. Bellovin[13] describe las áreas problemáticas de los protocolos
de seguridad basados en IP y da algunas propuestas para mitigarlas.
Fithen[39] y su equipo hablan acerca de la infraestructura necesaria para poder empezar a
definir una seguridad efectiva, Jamison[54] explica sobre la seguridad física. Zviran[112] llevó
a cabo un estudio empírico sobre la seguridad basada en contraseña.
Charles[23] explica cómo hacer uso de sistemas señuelos para detener a un posible atacante
antes de que llegue a la información verdaderamente importante.
Muffett[73] propone la técnica de autohacking auditando la seguridad más allá del firewall
(pared de fuego) para detectar debilidades antes de que lo haga otra persona. Klein[58] hace
un estudio sobre la facilidad de romper las contraseñas y propone cómo hacer contraseñas más
seguras.
Por el lado de la programación segura en UNIX/GNU Linux Wheeler[107] proporciona
consejos y un howto como hacerlo.
Bibliografía
[1] S. V. Adve and K. Gharachorloo. Shared memory consistency models: A tutorial. IEEE
Computer, 29(12):66–76, 1996.
[2] N. Afshartous and M. C. Harrison. Expressing concurrency in Griffin. pages 292–301.
[3] Ehab S. Al-Shaer. Distributed memory management: Design issues and future trends.
[4] Wenliang Du And. Using minix to teach computer security courses.
[5] A. W. Appel and K. Li. Virtual memory primitives for user programs. In Proceedings of
the 4th International Conference on Architectural Support for Programming Languages
and Operating System (ASPLOS), volume 26, pages 96–107, New York, NY, 1991. ACM
Press.
[6] P. Ashton, D. Ayers, and P. Smith. SunOS Minix: a tool for use in operating system
laboratories. Australian Computer Science Communications, 16(1,):259–269, 1994.
[7] E. Todd Atkins. Swatch.
[8] S. Au and S. Dandamudi. The impact of program structure on the performance of sche-
duling policies in multiprocessor systems, 1996.
[9] N. Audsley. Deadline monotonic scheduling, 1990.
[10] N. C. Audsley, A. Burns, M. F. Richardson, and A. J. Wellings. Hard Real-Time Schedu-

ling: The Deadline Monotonic Approach. In Proceedings 8th IEEE Workshop on Real-
Time Operating Systems and Software, Atlanta, 1991.
[11] Paul Barham. Devices in a multi-service operating system.
[12] Robert M. Barned and Russell J. Richards. Uniform driver interface (udi) reference im-
plementation and determinism. In RTAS ’02: Proceedings of the Eighth IEEE Real-Time
369
370 BIBLIOGRAFÍA
and Embedded Technology and Applications Symposium (RTAS’02), page 301, Washing-
ton, DC, USA, 2002. IEEE Computer Society.
[13] Steven M. Bellovin. Problem areas for the IP security protocols. In Proceedings of the
Sixth Usenix UNIX Security Symposium, 1996.
[14] Brian N. Bershad and Matthew J. Zekauskas. Midway: Shared memory parallel program-
ming with entry consistency for distributed memory multiprocessors. Technical Report
CMU-CS-91-170, Pittsburgh, PA (USA), 1991.
[15] Matt Bishop. A taxonomy of Unix system and network vulnerabilities. Technical Report
CSE-9510, Department of Computer Science, University of California at Davis, May
1995.
[16] David L. Black. Scheduling support for concurrency and parallelism in the mach opera-
ting system. IEEE Computer, 23(5):35–43, 1990.
[17] R. D. Blumofe. Executing multithreaded programs efficiently. Technical Report

MIT/LCS/TR-677, 1995.
[18] Jan Burse. A basic model of parallelism.
[19] Bogdan Caprita, Wong Chun Chan, Jason Nieh, Clifford Stein, and Haoqiang Zheng.
Group ratio round-robin: O(1) proportional share scheduling for uniprocessor and multi-
processor systems.
[20] John B. Carter, John K. Bennett, and Willy Zwaenepoel. Techniques for redu-
cing consistency-related communication in distributed shared-memory systems. ACM
Transactions on Computer Systems, 13(3):205–243, 1995.
[21] Y. Chan, S. Dandamudi, and S. Majumdar. Performance comparison of processor sche-

duling strategies in a distributed-memory multicomputer system. pages 139–145.
[22] Richard Chapman and W. Homer Carlisle. A Linux-based lab for operating systems and
network courses. Linux Journal, 41:??–??, 1997.
[23] Kellep Charles. Decoy systems: A new player in network security and computer incident
response.
[24] J. S. Chase, H. M. Levy, M. Baker-Harvey, and E. D. Lazowska. How to use a 64-bit

virtual address space. Technical Report TR-92-03-02, 1992.
BIBLIOGRAFÍA 371
[25] Jeff Chase, Hank Levy, and Ashutosh Tiwary. Using virtual addresses as object referen-
ces.
[26] Chandra Chekuri. Approximation algorithms for scheduling problems. Technical Report
CS-TR-98-1611, 1998.
[27] P. M. Chen and D. A. Patterson. Maximizing performance in a striped disk array. In Proc.
17th Annual Int’l Symp. on Computer Architecture, ACM SIGARCH Computer Architec-
ture News, page 322, 1990.
[28] S. Chen and D. Towsley. A performance evaluation of RAID architectures. IEEE Transac-
tions on Computers, 45(10):1116–1130, 1996.
[29] Shimin Chen and Mengzhi Wang. Transactional virtual memory with fine-grained range
lock support.
[30] Khien-Mien Chew and Avi Silberschatz. The recoverable-persistent virtual memory pa-
radigm. Technical Report CS-TR-93-08, 1, 1993.
[31] Mark Claypool, David Finkel, and Craig Wills. An open source laboratory for operating
systems projects. pages 145–148.
[32] Wiebren de Jonge, M. Frans Kaashoek, and Wilson C. Hsieh. The logical disk: A new
approach to . . .
[33] H. M. Deitel. Introducción a los Sistemas Operativos. AddisonWelsey IberoAmericana,

1987.
[34] Yannick Deville. A low-cost usage-based replacement algorithm for cache memories.
SIGARCH Comput. Archit. News, 18(4):52–58, 1990.
[35] Jayanta K. Dey, James F. Kurose, Donald F. Towsley, C. M. Krishna, and Mahesh Girkar.
Efficient on-line processor scheduling for a class of IRIS (increasing reward with increa-
sing service.) real-time tasks. In Measurement and Modeling of Computer Systems, pages
217–228, 1993.
[36] Daniel W. Engels, Jon Feldman, David R. Karger, and Matthias Ruhl. Parallel processor
scheduling with delay constraints. In Twelfth Annual Symposium on Discrete algorithms,
pages 577–585, New York, NY, USA, 2001. ACM Press.
372 BIBLIOGRAFÍA
[37] Dawson R. Engler, M. Frans Kaashoek, and James O’Toole. Exokernel: An operating sys-
tem architecture for application-level resource management. In Symposium on Operating
Systems Principles, pages 251–266, 1995.
[38] Dror G. Feitelson, Larry Rudolph, Uwe Schwiegelshohn, Kenneth C. Sevcik, and Parkson
Wong. Theory and practice in parallel job scheduling. In Dror G. Feitelson and Larry
Rudolph, editors, Job Scheduling Strategies for Parallel Processing, pages 1–34. Springer
Verlag, 1997.
[39] Bill Fithen, Steve Kalinowski, Jeff Carpenter, and Jed Pickel. Infrastructure: A prerequi-
site for effective security. In LISA ’98: Proceedings of the 12th USENIX conference on
System administration, pages 11–26, Berkeley, CA, USA, 1998. USENIX Association.
[40] M. J. Flynn. Very high-speed computing systems. Proceedings IEEE, 54:1901–1909,

1966.
[41] Laurent George, Nicolas Rivierre, and Marco Spuri. Preemptive and non-preemptive
real-time uniprocessor scheduling. Technical Report RR-2966.
[42] Kourosh Gharachorloo, Daniel Lenoski, James Laudon, Phillip B. Gibbons, Anoop Gup-
ta, and John L. Hennessy. Memory consistency and event ordering in scalable shared-
memory multiprocessors. In 25 Years ISCA: Retrospectives and Reprints, pages 376–387,
1998.
[43] R. A. Gingell, J. P. Moran, and W. A. Shannon. Virtual memory architecture in sunOS.

Proceedings of the USENIX 1987 Summer Conference, pages 81–94, 1987.
[44] Shantanu Goel and Dan Duchamp. Linux device driver emulation in mach. In USENIX
Annual Technical Conference, pages 65–74, 1996.
[45] S. Hartley. More experience with minix in an operating systems lab.
[46] M. Hayter. A workstation architecture to support multimedia, 1993.
[47] Allan Heydon and J. D. Tygar. Specifying and checking UNIX security constraints. Com-
puting Systems, 7(1):91–112, 1994.
[48] C.A.R. Hoare. Communicating sequential processes. Communications ACM, 21:666–

677, Aug 1978.
[49] W. Holland, G. Gibson, L. Reilly, and J. Zelenka. Raidframe: A rapid prototyping tool
for raid systems, 1996.
BIBLIOGRAFÍA 373
[50] Antonio Villalón Huerta. Seguridad en unix y redes. Antonio Villalón Huerta, 2000.
[51] Apple Computer Inc. Mac os x server fundamentals. Technology brief, 2007.
[52] Damir Isovic. Flexible scheduling for media processing in resource constrained real-time
systems.
[53] Sundar Iyer. Unix and internet security.
[54] Neal S. Jamison. Computer security revisited: physical security. Sys Admin, 3(6):8–12,
1994.
[55] Steven Schlosser Jiri. On multidimensional data and modern disks.
[56] T. Johnson and K. Harathi. Interruptible critical sections. Technical Report 94–007, 1994.
[57] Chang-Sung Jeong Jung-Ju. Massively parallel reconfigurable system architecture-popa.
[58] Daniel V. Klein. “foiling the cracker” – A survey of, and improvements to, password se-
curity. In Proceedings of the second USENIX Workshop on Security, pages 5–14, Summer
1990.
[59] Phillip Krueger and Davender Babbar. The effects of precedence and priority constraints
on the performance of scan scheduling for hypercube multiprocessors. Journal of Parallel
and Distributed Computing, 39(2):95–104, 1996.
[60] B. W. Lampson and D. D. Redell. Experience with processes and monitors in mesa. In
Proceedings of the 7th ACM Symposium on Operating Systems Principles (SOSP), pages
43–44, 1979.
[61] B. Leslie, P. Chubb, N. Fitzroy-Dale, S. Gotz, C. Gray, L. Macpherson, D. Potts, Y. Shen,

K. Elphinstone, and G. Heiser. User-level device drivers: Achieved performance, 2005.
[62] B. Leslie and G. Heiser. Towards untrusted device drivers, 2052.
[63] Ben Leslie, Nicholas FitzRoy-Dale, and Gernot Heiser. Encapsulated user-level device
drivers in the mungi operating system.
[64] Kai Li and Paul Hudak. Memory coherence in shared virtual memory systems. In Pro-
ceedings of the 5th ACM Symposium on Principles of Distributed Computing (PODC),
pages 229–239, New York, NY, 1986. ACM Press.
[65] Jochen Liedtke. On µ-kernel construction, 1995.

374 BIBLIOGRAFÍA
[66] C. L. Liu and James W. Layland. Scheduling algorithms for multiprogramming in a hard-
real-time environment. Journal of the ACM, 20(1):46–61, 1973.
[67] J. Mayo and P. Kearns. A secure-networked laboratory for kernel programming, 1997.
[68] Marshall K. McKusick, William N. Joy, Samuel J. Leffler, and Robert S. Fabry. A fast
file system for UNIX. Computer Systems, 2(3):181–197, 1984.
[69] L. W. McVoy and S. R. Kleiman. Extent-like performance from a UNIX file system. In
Proceedings of the USENIX Winter 1991 Technical Conference, pages 33–43, Dallas, TX,
USA, 21–25 1991.
[70] C. Mercer. Operating system resource reservation for real-time and multimedia applica-
tions, 1997.
[71] David Mosberger. Memory consistency models. Operating Systems Review, 27(1):18–26,
1993.
[72] Francisco Manuel Márquez. UNIX, programación avanzada. Alfaomega-RAMA, 2th

edition, 2001.
[73] Alec Muffett. Wan-hacking with autohack - auditing security behind the firewall.
[74] T. Nakajima and H. Tokuda. Implementation of scheduling policies in realtime mach in

the proceeding of international workshop on object-oriented operating systems, 1992.
[75] Peter Chubb National. Get more device drivers out of the kernel!
[76] M. N. Nelson. Physical memory management in a network operating system. Report No.
UCB/CSD 88/471, pages 1–2, 1988.
[77] N. M. Nelson. Virtual memory for the Sprite operating system. Technical Report UCB/
CSD 86/301, Berkeley, CA (USA), 1986.
[78] National Institute of Standards & Technology and National Security Agency. Federal
criteria for information technology security - volume ii: Registry of protection profiles.
[79] J. K. Ousterhout, A. R. Cherenson, F. Douglis, M. N. Nelson, and B. B. Welch. The sprite

network operating system. Computer Magazine of the Computer Group News of the IEEE
Computer Group Society, ; ACM CR 8905-0314, 21(2), 1988.
[80] Peter Chubb Peterc. Linux kernel infrastructure for user-level device drivers.
BIBLIOGRAFÍA 375
[81] I. Pratt. The user-safe device i/o architecture, 1997.
[82] D. D. Redell, Y. K. Dalal, T. R. Horsley, H. C. Lauer, W. C. Lynch, P. R. McJones,

H. G. Murray, and S. C. Purcell. Pilot: An operating system for a personal computer.
In Proceedings of the 7th ACM Symposium on Operating Systems Principles (SOSP),
pages 106–107, 1979.
[83] D. M. Ritchie. The evolution of the UNIX time-sharing system. BSTJ, 63, 8:1577–1594,
1984.
[84] D. M. Ritchie and K. Thompson. The UNIX time-sharing system. The Bell System
Technical Journal, 57(6 (part 2)):1905+, 1978.
[85] P. Robinson and M. Beigl. Trust context spaces: An infrastructure for pervasive security,
2003.
[86] Mendel Rosenblum and John K. Ousterhout. The design and implementation of a log-
structured file system. ACM Transactions on Computer Systems, 10(1):26–52, 1992.
[87] R. Ross. Reactive scheduling for parallel i/o systems, 2000.
[88] Emilia Rosti, Evgenia Smirni, Lawrence W. Dowdy, Giuseppe Serazzi, and Kenneth C.
Sevcik. Processor saving scheduling policies for multiprocessor systems. IEEE Transac-
tions on Computers, 47(2):178–189, 1998.
[89] Ellard Roush. Performance and the single/multi–processor operating system process
subsystem, 1995.
[90] R. Sandberg. The sun network filesystem: Design, implementation, and experience, 1986.
[91] Russel Sandberg, David Goldberg, Steve Kleiman, Dan Walsh, and Bob Lyon. Design
and implementation of the Sun Network Filesystem. In Proc. Summer 1985 USENIX
Conf., pages 119–130, Portland OR (USA), 1985.
[92] M. Satyanarayanan, Henry H. Mashburn, Puneet Kumar, David C. Steere, and James J.
Kistler. Lightweight recoverable virtual memory. ACM Transactions on Computer Sys-
tems, 12(1):33–57, 1994.
[93] J. Sgall. line scheduling – a survey. Lecture Notes in Computer Science. Springer-Verlag,
Berlin, 1997.
[94] Silberchatz. Sistemas Operativos, Conceptos y diseño. Mac Graw Hill, 1994.
376 BIBLIOGRAFÍA
[95] Gagne Silberchatz, Galvin. Fundamentos de Sistemas Operativos. Mc Graw Hill, 7th
edition, 2005.
[96] William Stallings. Sistemas Operativos. Prentice Hall, 2000.
[97] Chaitanya Swamy and Sachin Jain. Scheduling algorithms.
[98] Andrew S. Tanenbaum. Sistemas Operativos, Diseño e Implementación. Prentice-Hall,

1988.
[99] Andrew S. Tanenbaum. Distributed Operating Systems. Prentice-Hall, 1995.
[100] Andrew S. Tanenbaum. Operating Systems Design and Implementation. Prentice-Hall,

1995.
[101] Andrew S. Tanenbaum. Sistemas Operativos Modernos. Pearson Educación, 2003.
[102] Diane Tang. Benchmarking filesystems. Technical Report TR-19-95, Harvard University,
Cambridge, MA, USA, October 1995.
[103] Avadis Tevanian, Jr., Richard F. Rashid, David B. Golub, David L. Black, Eric Cooper,
and Michael W. Young. Mach threads and the unix kernel: The battle for control. Tech-
nical Report CMU-CS-87-149, 1987.
[104] Stephen Tweedie. Journaling the Linux ext2fs filesystem. In LinuxExpo ’98, 1998.
[105] M. Wenzel. Some aspects of unix file-system security, 2001.
[106] R. Westbrock. Flexible scheduling for linux, 1999.
[107] D. Wheeler. Secure programming for linux and unix howto.
[108] Hui Wu, Joxan Jaffar, and Roland H. C. Yap. A fast algorithm for scheduling instructions
with deadline constraints on RISC processors. In IEEE PACT, pages 281–290, 2000.
[109] Hui Wu, Joxan Jaffar, and Roland H. C. Yap. Instruction scheduling with timing cons-
traints on a single RISC processor with 0/1 latencies. In Principles and Practice of Cons-
traint Programming, pages 457–469, 2000.
[110] K. Yue and D. Lilja. Dynamic processor allocation with the Solaris operating system.
pages 392–397.
BIBLIOGRAFÍA 377
[111] Huican Zhu, Tao Yang, Qi Zheng, David Watson, Oscar H. Ibarra, and Terence R. Smith.
Adaptive load sharing for clustered digital library servers. Int. J. on Digital Libraries,
2(4):225–235, 2000.
[112] Moshe Zviran and William J. Haga. Password security: an empirical study. J. Manage.
Inf. Syst., 15(4):161–185, 1999.
Índice alfabético
véase acelerador gráfico 390 adaptador de vídeo

véase tarjeta de vídeo
abrazo mortal APM,Hércules,CGA 233
véase deadlock 110 administración
abrir un directorio, 298 costo de, 362
abstracción administración
de hardware, 26 de impresoras, 26
acceso de archivos, 28
aleatorio, 275 funciones de, 28
concurrente, 252 de dispositivos de E/S, 193
control de, 333 de recursos, 4
derecho de, 325 administración de memoria, 157
directo, 275 administración de páginas, 160
directo a memoria, 198 administrador
directo al hardware, 5 de memoria, 22, 159, 189
matriz de, 318 de recursos, 118
métodos de, 274 de tareas, 357
secuencial, 275 AGP
acceso a disco véase acelerador gráfico 196
algoritmos de planificación, 223 algoritmo
unidad de, 30 de cifrado, 345
acceso remoto, 274 RSA, 351
accesos algoritmo de búfer de páginas, 187
al sistema, 359 almacenamiento
acelerador gráfico, 234 requisitos de, 251
ACL, 294 amd, 141
acl, 326 amenazas
actividades de un intruso, 340 a los sistemas, 314
378
ÍNDICE ALFABÉTICO 379
análisis forense, 344 especiales, 258

análisis seguridad de, 292
de abajo hacia arriba, 48 servidor de, 288
de arriba hacia abajo, 48 sincronización de, 253
orientado a objetos, 48 tipos de, 258
anomalía de Belady, 185 tipos de interfaz, 265
apple, 241 área de datos, 31
applets, 328 aritmética modular, 351
apuntadores en gui, 241 arquitectura
archivo componentes, 7
apuntador de, 275 de von newman, 7
atributos en UNIX/Linux, 293 arreglos, 256
binario, 260 asignación de bloques por nodos-i, 282
de índice, 277 asignación por lista ligada de bloques, 280
de configuración, 260 asignación
de log, 358 de memoria
definición de, 252, 253, 261 primer, mejor y peor ajuste, 165
dependencias de, 57 de memoria contigua, 24
destrucción de un, 292 de memoria por páginas, 25
estructura de, 252 asignación contigua, 163
estructura del sistema de, 31 asimétrico
fin de, 276 esquema de cifrado, 346
llamadas del sistema, 253 ataque
nombres de, 257 prevención de un, 341
normal, 258 ataque a diccionario, 324
objeto, 259 ataques
oculto, 294 a los códigos cifrados, 347
operaciones sobre un, 253 ataques externos, 336
permisos de, 260 ataques internos, 334
relativo, 277 auditoría, 333
sistema de, 252 auditorías, 329
tipo de dato, 256 aunteticación
transferencia de, 266 de usuarios, 322
archivos autenticidad
administración de, 251 del cifrado, 347
de texto, 259 autentificación de usuarios, 313
380 ÍNDICE ALFABÉTICO
awstats, 359 carga de servicios, 17

cargador
bibliotecas compartidas, 171
de linux, 16
BIOS, 16
del sistema operativo, 16
bloque
carpeta
asignación contigua de, 278
definición de, 295
bloque de arranque, 273
cat, 358
bloque de disco, 30
cd
bloques de disco, 216
cambiar directorio, 266
bombas lógicas, 336
CDE, 241, 257
borrado de archivo, 254
cero lógico, 195
borrar un directorio, 298
cerrar un directorio, 298
bps(bits por segundo), 229
cerrojos, 93
break code, 237
certificado de revocación, 351
bufer
char
de controlador, 12, 208
tipo de dato, 255
de teclado véase teclado
ciclo de CPU, 123
bufer de 237
ciclo infinito, 102
búffer, 13
ciclos
bus
robo de véase robo de ciclos 207
de datos, 8
cifrado
de direcciones, 8
llave de, 346
en sistemas multiprocesador, 144
por sustitución, 349
busqueda de registros
cifrado DESS, 349
búsqueda de registros, 254
cilindro
buzones, 104
véase discos
byte, 158, 255
cilindro de 30
Código ASCII, 239 cilindro de disco, 214
caballo de troya, 334 cintas magnéticas, 274
caché, 161 clasificación de E/S, 194
tasas de acierto, 162 clave
cache de cifrado, 346
de dispositivo, 209 clave privada, 350
campo llave, 285 clavepub
campos llave, 277 clave pública, 350
caracter, 255 cliente-servidor, 241, 243
cluster, 215 copias por el sistema operativo, 300

de red, 15 coprocesador gráfico, 234
en paralelo, 15 copyleft
cluster de computadoras, 15 véase GPL 55
cluster de disco costo
definición, 30 de administración, 362
cokies, 328 de operación, 361, 362
cola de impresión, 210 inicial, 361
colisiones, 286 costo total de propiedad, 360
com1-4, 228 cpu
compactación de memoria, 165, 168 arquitectura, 7
compartición de memoria, 161 bus de datos, 8
competencia de recursos, 111 bus de direcciones, 8
comprobación de límites, 337 planificación de, 123
concurrencia, 87 planificación, 21
definición, 88 registros, 8
principios generales, 89 satélites, 26
confidencialidad unidad aritmético lógica, 8
del cifrado, 347 unidad de control, 8
configuración cracker, 316, 323
costo de, 361 creación de archivo, 253
conmutador multietapa, 149 crear un directorio, 298
consistencia del sistema de archivos , 302 criptoanálisis, 346
constraseña criptoanalizador, 348
verificación de, 333 criptografía, 345
contador de programa, 159 criptografía tradicional, 348
contraseña, 323 criptografo
débil, 342 criptógrafo, 348
difícil de adivinar, 324 cuenta de invitado, 342
control de acceso, 313 cuentas de usuario, 323
controlador de dispositivo, 195
definición, 195 datos
controlador de dispositivos, 196 confidencialidad de, 314
copia de seguridad, 300 integridad de, 314
copias de protección, 299 jerarquía de, 254
copias de respaldo, 300 pérdida de, 315
DB25, 228 flexible, 292

DB9, 228 discos, 274
deadlock, 110 bloque de, 30
derecho de acceso, 325 capacidad de almacenamiento, 10
desbordamiento cilindro de, 30
de búfer, 337 clasificación, 10
de pila, 337 duros
desempeño, 354 definición de, 213
medición de, 355 estructura lógica, 10
desligar un directorio, 298 extent, 215
detección de una intrusión, 343 formateo, 29
df magnéticos, 10
espacio libre en disco, 267 pistas de, 29
diccionario por tipo de interfaz, 10
ataque a, 324 RAM, 211
dig, 358 velociadades, 10
direcciones lógicasy físicas, 170 dispositivo
direcciones virtuales, 171 búfer de, 208
definicion2definición, 171 colas de, 209
directorio manejador de, 206
actual o de trabajo, 296 tratamiento de errores, 209
atributos de, 283 dispositivos
definición de, 295 administración de, 26
entrada de, 31, 253 características, 26
estructura de, 261 carga de controladores, 17
punto punto “..”, 297 control por interrupción, 202
punto“.”, 297 controlador de, 12
directorios de almacenamiento, 194
de dos niveles, 295 de entrada/salida, 11, 193
de un solo nivel, 295 de interfaz humana, 195
implementación de, 283, 295 de transmisión, 194
jerárquicos, 295 entrada/salida compartida, 35
operaciones sobre, 298 especializados, 195
disco sondeo de, 201
bloques básicos, 272 distribuciones
duro, 292 debian, 59
linux, 57 estructura de directorio, 253

pclinuxOS, 58 estrucutras
red hat, 58 de tipos de datos, 256
suse, 58 evento, 242
ubuntu, 58 exclusion mutua
DMA, 206 exclusión mutua, 88
DMA véase acceso exclusión mutua
directo a memoria 198 solución software, 90
DNS, 288 solución por hardware, 92
dominios, 325 extent de disco véase discos
double extent 215
tipo de dato, 255
DRAM fallos de página, 183
véase memoria falsificación
principal 9 de inicio de sesión, 335
FAT, 31
emisor-receptor véase mensajes fdisk, 219
definición 103 fetch o fetching, 137
enlace de directorio, 298 fifo
entornos multiusuario, 136 algoritmo de planificación, 75
eof, 276 fin de archivo, 276
equipo de penetración, 340 firewall, 341
escritura de archivo, 254 firma difital, 353
espacio de direcciones, 24 firma digital, 348
espacio no particionado, 218 float
especificaciones básicas de E/S, 194 tipo de dato, 255
espera activa véase dispositivos flujos
sondeo de 201 archivo de, 256
esquemas de cifrado, 346 foco, 242
estado seguro, 115 fork (crear proceso hijo), 80
estrategias de manejo de memoria, 163 formateo de disco, 29
estructura fragmentación de disco, 278
de disco, 29 fragmentación externa, 165
de un sistema operativo, 46 fragmentación externa de disco, 280
por niveles, 48 fragmentación interna, 167
única, 46 fragmentación interna, 216
frecuencia de transmisión, 229 HAL(hardware abstraction layer), 26

free BSD, 57 de windows 2003 server, 67
front-end, 257, 265 hardware
FSF, 52, 54, 55, 57 costo de, 361
ftp, 266, 288, 342 definición de, 1
función seguridad por, 321
date, 227 hilos
de archivos, 263 definición, 83
errno, 209 eliminación, 87
fclose, 264 en linux, 84
fgetc, 264 hipercubos, 146
fopen, 263 historia
fputc, 265 de órdenes, 267
fread, 263 historia de linux, 33
fwrite, 264 HNR, 134
hwclock, 227 home, 218
perror, 209 html, 259
time, 226
función íconos, 240, 268
gets(), 337 íconos en gui, 241
funciones compartidas, 171 identidad
fundación de software libre, 33 verificación de, 353
fuser, 267 inanición, 88, 95, 114
include, 269
GDI, 244
independencia de dispositivo, 200
gif
independencia de máquina, 200
formato gráfico, 328
índice de archivo, 276
gnome, 241, 257
ingeniería social, 334
GNU, 55, 57
instalación inicial
GNU/Linux, 49
costo de, 361
GPL, 55
int, 255
grupo tigre, 340
intérprete de órdenes, 260
gui, 241
integridad
ventanas,íconos,menús, 241
del cifrado, 347
gusanos, 339
intel, 33, 46, 55, 141
hacker, 316, 323, 340 interbloqueo, 95, 109
véase deadlock 110 recuperación de una, 343

condiciones, 111 intruso
detección y recuperación, 120 actividades de un, 340
evitar un, 115 intrusos, 314
prevención, 113 activos, 315
principios de, 110 pasivos, 314
técnicas de manejo, 111 invitado
intercambio cuenta de, 342
véase swap 169
área de, 29 jaula, 344
interfaces gráficas jaulas, 316
de usuario, 240 jerarquía de memoria, 161
interfaz john the ripper, 324
de usuario, 4 KDE, 257
del programador, 269 kde, 241
modo consola, 265 kernel, 55
interfaz gráfica, 268 de solaris, 53
interfaz gráfica, 265 linux distribución lógica del, 49
interfaz humana véase dispositivos HURD, 52
de interfaz humana 195 mac OS, 54
internet micro, 51
navegador de, 259 modo de, 175
interrupcion modular, 53
de hardware, 198 multihilo, 84
interrupción subsistema de E/S, 207
enmascarable, 203 keylogger, 328
con mensajes, 109 kill
de fallo de página, 178 matar procesos, 267
de hardware, 12
de software, 12 lastlog, 330
inhabilitación de, 91 lectura de archivo, 254
mecanismo de, 203 leer un directorio, 298
no enmascarable, 203 less, 358
interrupciones encadenadas, 204 LFU, 187
intrusión lib, 269
detección de una, 343 liberación de páginas, 189
librerías medio físico, 195

dinámicas, 169 medios de transmisión, 195
linus torvalds, 55 memoria
linux, 257 administración de, 22
seguridad de acceso, 293 administrador de véase administrador
lista de control de acceso, 294, 326 de memoria 159
listas enlazadas de memoria, 167 asignación contigua, 24
llamada a exit(), 82 asignación por páginas, 25
llamadas al sistema, 210 asociativa, 176
sobre archivos, 253 caché, 9, 161
llave capacidad de, 162
de cifrado, 346 compactación de, 165, 168
logs, 329, 343 compactación de, 25
archivos y procesos de, 330 compartición de, 161
logs del sistema, 358 costo por byte, 11
long de intercambio, 78
tipo de dato, 255 estática, 164
long long estrategias de manejo de véase estrategias
tipo de dato, 255 de manejo de memoria 163
física definición, 158
mach, 105 fragmentación de, 25
macOS, 62 fragmentación externa véase fragmentación
macros, 355 externa 165
man fragmentación interna, 167
ayuda UNIX/Linux, 267 funcionamiento, 22
manejador de DMA, 207 heap, 285
mapa de bits, 166, 244 importancia de la, 157
mapeo de funciones, 171 jerarquía de, 161
marcadores bélicos, 324 listas enlazadas, 167
marcos de página, 172 mapa de bits, 166
matrices, 256 marcos de, 25
matriz de acceso, 318 número de página, 173
MBR, 16, 217, 273 organización general, 158
mecanismo de interrupciones, 205 particiones fijas
mecanismos de protección, 317 véase particiones fijas de memoria 163
medición de desempeño, 355 particiones variables de, 164
principal, 9, 162 monitor

protección de, 161 definición, 99, 100, 102
protección de la, 176 monitoreo, 357
secundaria, 10 montón, 285
técnica de segmentación, 180 more, 358
tabla de marcos, 175 ms-dos, 13, 46, 65, 257
tipos de asignación véase tipos de asigna- multiprocesador
ción de memoria 168 clasificación, 142
unidad de definición de, 135
véase unidad de memoria 158 organización, 143
USB, 3, 11 ventajas, 141
violación de protección de, 176 multiprocesamiento, 135
virtual, 24, 170 asimétrico, 14, 151
desventajas, 189 conceptos, 135
ventajas, 189 definición, 140
mensajes simétrico, 14
algoritmo, 108 ventajas, 136
comunicación y sincronización, 107 mútex, 102, 107
definición, 103
netbeui, 289
denominación
netware IPX/PSX, 289
directa indirecta, 103
NFS, 289
intercambio de
nombres de archivo largos, 285
síncrono vs asíncrono, 105
NORMA, 147
longitud, 106
nslookup, 358
operaciones sobre, 103
ntop, 359
para envío de señales, 109
núcleo
menús en gui, 241
véase kernel 56
messages, 330
de windows 95, 66
MFU, 187
núcleo de linux, 56
microsoft, 33, 65, 68, 241
NULL, 285
mkdir
NUMA, 148
crear directorio, 267
numero de bloque
mkfs, 221
número de bloque relativo, 276
modo gráfico, 268
modo kernel, 175 objetos, 256
modos de direccionamiento, 159 de dominio, 326
operación tar, 257

costo de, 362 telnet, 266, 342
operación top, 267
asíncrona, 26 traceroute, 358
optimización, 354 windows
orde format, 223
top, 357 xkill, 267
orden overlays, 169
attrib(windows), 315
cat, 358 páginas compartidas, 177
cd, 266, 297 páginas virtuales, 172
df, 267 paginación
dig, 358 definición, 172
echo, 335 estructura general, 173
fdisk, 219 soluciones hardware, 175
finger, 323 paginación bajo demanda, 178
fsck, 302 paginación fija, 173
ftp, 342 paginación, 25
fuser, 267 de memoria, 170
gzip, 257 páginas de internet
history, 267 dinámicas, 291
kill, 267 estáticas, 291
less, 358 páginas de memoria, 160
man, 267 palabra
mkdir, 267 tipo de dato, 255
mkfs, 221 palabra de computadora, 158
more, 358 papelera de reciclaje, 300
nslookup, 358 paquete de servicio, 334
ping, 358 paralelismo
ps, 267, 357 definición, 137
pstree, 357 por hardware, 137
rm, 267 por software, 138
scandisk, 302 paralelización de instrucciones, 139
sftp, 342 partición
ssh, 266, 342 características, 29
sudo, 267 de disco, 29, 217
extendida, 217 134

home, 218 no apropiativa, 124
primaria, 217 primero el más corto véase SJF 132
raíz, 218 tipos de, 125
swap, 218 planificador
tmp, 218 a corto plazo, 21
usr, 218 a largo plazo, 21
var, 218 algoritmos, 21
particiones fijas de memoria, 163 de procesos, 178
particiones variables de memoria, 164 prevención de un ataque, 341
pasos en un fallo de página, 183 primos relativos
PATH, 335 números, 352
PC coontador de programa principios de hardware, 193
véase contador de programa 159 privilegio mínimo, 317
PCB (bloque de control de proceso), 79 privilegios, 313
penetración procesador
equipo de, 340 de impresora, 26
pérdida de información, 292 administración, 122
perfilado, 355 procesadores paralelizados, 138
formas de, 356 procesamiento dual, 140
permisos RWX, 294 proceso
ping, 358 colgado, 357
PIO, 206 concepto de, 74
pista de disco pid identificador de, 74
véase discos proceso de arranque, 16
pistas de 29 procesos
planificación administración, 18
apropiativa, 21, 123 administración de, 73
conceptos, 122 concepto de, 18
criterios de, 124 creación de, 20
de E/S, 207 definición, 18
de la cpu véase cpu definición de, 74
planificación de 123 del sistema, 18
de la cpu con fifo, 128 eliminación de, 82
el de menor tiempo véase SRT 133 estado de los, 19, 74
la tasa de respuesta más alta véase HNR hilos, 83
operaciones entre, 80 grafo general, 117

operaciones sobre, 20 grafos de asignación, 117
planificación, 19 reutilizables, 112
protección inter, 313 referencia de página inválida, 176
relaciones entre, 80 registro
terminación de, 20 de control, 197
transiciones de, 77 de estado, 197
programas autorreplicables, 338 de salida, 197
programas fuente, 259 registro de eventos, 358
protección, 317 registros base y límite, 160
fundamentos de, 317 registros de direcionamiento, 159
protección de la memoria, 176 registros de un controlador, 197
protección de memoria, 161 registros del procesador, 161
protección reloj
mecanismos de, 299 ciclos de, 310
prueba de seguridad relojes, 224
véase recursos de hardware, 224
asignación 118 de software, 226
ps, 357 manejador de, 226
procesos en ejecución, 267 renderización, 234
pstree, 357 rendimiento
puertas traseras, 337 análisis de, 356
puerto renombrar un directorio, 298
definición de, 341 reposicionamiento de archivo, 254
USB, 195 respaldo comprimido, 301
puerto de gráficos acelerado, 196 respaldo de información, 299
puerto paralelo, 195 respaldo físico, 301
puerto serie, 195 respaldo incremental, 299, 300
respaldo lógico, 302
ráfagas de cpu, 129 reubicación dinámica, 174
raíz, 218 revocación
reasignación de direcciones, 23 certificado de, 351
recuperación de una intrusión, 343 revocación de derechos, 319
recursos richard stallman, 55
asignación, 117 RJ-45, 228
consumibles, 112 rm
borrar archivo o dir, 267 dirección lógica, 182

robert morris, 339 tabla de, 181
robo de ciclos, 207 seguridad
roles de usuario, 331 aspectos de, 333
round robin, 130, 131 definición, 312
route, 358 física, 312, 313
RS-232, 228 lógica, 312, 314
RSA, 351 políticas y procedimientos de, 313
ruta, 296 por hardware, 321
absoluta, 296 por ocultamiento, 346
por omisión, 297 por software, 321
relativa, 296 seguridad basada en la confianza, 328
semáforo
samba, 289 binario, 96
scan code, 235 algoritmo, 98
sección crítica definición, 95
algoritmos, 90 operaciones, 95
definición de, 90 semántica, 95
sector de arranque service pack, 334
véase MBR 16 servicio
sector de disco, 214 del sistema operativo, 313
secuencias de escape, 239 disponibilidad de, 314
seek, 254 servidor
segmentación, 170, 188 de bases de datos, 288
ventajas y desventajas, 188 de nombre de dominio, 288
segmentación de memoria, 169 ftp, 288
segmento de aplicaciones, 290
de programa, 47 de bases de datos, 291
de código, 9, 169 de correo, 288
de datos, 9, 169 de impresión, 288
de pila, 9, 169 de juegos, 288
dirección base, 181 de páginas web, 291
más comunes, 181 dearchivos, 289
violación de, 23 proxy, 289
segmentos telnet, 289
dinámicos, 181 web, 289
servidor de archivos, 287 diseño de, 46

servidor de noticias, 289 en multiprocesadores, 149
servidor X, 243 estructura de un, 46
servidor X, 210 evolución, 34
sesión Funciones, 17
entrar en, 266 GNU/Linux, 55
terminar, 267 historia
sesión de trabajo, 266 de GNU/Linux, 55
setgid, 342 de windows 2003 server, 65
setuid, 331, 342 general, 31
sftp, 266, 342 introducción, 1–2
shell, 335 librerías, 5
shell seguro, 266 llamadas al sistema, 5
short maestro esclavo, 150
tipo de dato, 255 simétrico, 150
simétrico supervisores separados, 150
esquema de cifrado, 346 unix, 48
símbolo del sistema, 270 sistemas
sincronización, 88, 102 de multiprocesamiento, 73
sistema de propósito especial, 13
de cifrado de tiempo compartido, 37
características, 347 de tiempo real, 309
cifrado, 346 dedicados, 34
consistente, 312 escalables, 147
criptográfico, 346 monoprocesadores, 13
entrada al, 333 monotarea, 73
multiprocesador multiprocesadores, 13
definición, 140 arquitecturas, 14
multitarea, 89 ventajas, 14
parches de, 334 multitarea, 73
penetración al, 340 por lotes, 35
vigilancia del, 316 sitios
sistema operativo de intranet, 291
apple, 54 de internet, 291
Características, 17 SJF, 132
definición, 2, 18 SMB/CIFS, 289
sobrepaginación, 184 tareas

software de apoyo al administrador, 6
costo de, 361 del administrador, 5
seguridad por, 321 del programador, 5
software de i/o, 199 del usuario final, 4
software libre, 55 tarjeta
software para discos, 218 madre, 23
solaris, 49, 54, 60, 61, 102 multiprocesador, 140
SRT, 133, 134 tarjeta de vídeo, 196, 232
ssh, 266, 342 APM,Hércules,CGA, 233
streams, 256 EGA,VGA,SVGA, 233
subsistema de E/S, 207 tcb, 328
subsistema de entrada/salida, 193 TCP/IP, 289
sudo, 267 teclado, 235
sulog, 331 bufer de, 237
sun, 241 tipos de, 235
sun microsystems, 55 teclado
superserver, 341 manejadores de, 237
sustitución tecnologías de almacenamiento, 274
de páginas FIFO, 185 teletrabajo, 4
LRU, 186 telnet, 342
óptima de páginas, 185 termcap, 240
por contadores, 187 terminal, 239
simple de página, 184 terminales, 227
sustitución simple de páginas, 184 de hardware, 227
swap, 218 en memoria, 232
véase intercambio manejador de, 231
área de 127 PC’s como, 232
swatch, 316, 331 tipos de, 231
syslog, 330 tontas, 231
syslogd, 330 X, 232
texto cifrado, 346
tabla de asignación de páginas, 173 tiempo
tabla de marcos, 175 de búsqueda, 216
tabla de particiones, 273 de rotación, 217
tabla hash, 285 de transferencia, 217
timming, 310 usuario, 323

tipos de asignación de memoria, 168 cuentas de, 323
tipos de datos, 255 roles de, 331
tipos de entornos utmp, 330
empresariales, 3
vídeo
institucionales, 3
manejadores de, 239
personales, 3
var, 218
tipos de planificadores de cpu, 123
variables de entorno, 297
tipos de usuarios
vector de interrupciones, 203, 205
administrador, 5
velocidad
empresariales, 4
de disco, 10
finales, 4
de dispositivos, 27
programadores, 5
de memoria, 162
tmp, 218
de proceso, 135
top, 357
del bus, 23
estadísticas de procesos, 267
del procesador, 23
trampas
SCSI, 27
de acceso, 336
verificación de identidad, 353
transferencia de datos, 12
vigilancia
truncar un archivo, 254
del sistema, 316
tty1-n, 228
virus, 338
tuberías, 259 propagación de un, 339
túnel, 290 void
tipo de datos especial, 255
UART, 228
volumen de disco, 213
uart, 195
UMA, 145 widgets, 242
UNAM-CERT, 344 windows, 244
unidad de control de la cpu, 159 2003 server, 67
unidad de memoria, 158 3.1, 66
UNIX 95,98,ME,XP, 54
seguridad de acceso, 293 95, 66
unix, 48, 63, 257 2000, 257
system unix V, 56 NT, 49, 52, 54, 66
uno lógico, 195 vista, 66
usr, 218, 269 XP, 66, 102
wmf, 244
wtmp, 330
X windows system, 243

xkill, 267

Sistema So Perati Vos

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Sistema So Perati Vos

Загружено:

Авторское право:

Доступные форматы

Instituto Tecnológico de Apizaco

Departamento de Sistemas y Computación

Ingeniería en Tecnologías de la Información y Comunicaciones

M. en C. Nicolás Alonzo Gutiérrez

Apizaco Tlax. Enero del 2018

Índice de figuras XIII

1. Introducción a los Sistemas Operativos 1

1.2.3.6. Asignación de memoria por páginas . . . . . . . . . . . . . 25

2. Administración de procesos y del procesador 73

2.4.7.2. Comunicación y sincronización interprocesos con mensajes . 107

2.6.7.1. Sistemas orientados a bus. . . . . . . . . . . . . . . . . . . . 144

3. Administración de Memoria 157

3.4.3.6. Algoritmos de búfer de páginas . . . . . . . . . . . . . . . . 187

4. Administración de Entrada/Salida 193

4.5. Problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

5. Sistemas de archivos 251

5.6.2.1. Servidor de archivos . . . . . . . . . . . . . . . . . . . . . . 289

6. Protección y Seguridad 309

6.6.2. Amenazas al sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 334

Índice alfabético 378

2.1. Representación de estados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

4.1. Puertos de E/S más comunes en una PC . . . . . . . . . . . . . . . . . . . . . 197

5.1. Extensiones más comunes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

1.1. Componentes de una Arquitectura Von Newmann . . . . . . . . . . . . . . . . 7

2.1. Diagrama de estados de un proceso . . . . . . . . . . . . . . . . . . . . . . . . 76

2.12. Conexión mediante barra cruzada . . . . . . . . . . . . . . . . . . . . . . . . 146

3.1. Disposición general de la memoria física . . . . . . . . . . . . . . . . . . . . . 158

4.1. Arquitectura de bus clásica en una PC . . . . . . . . . . . . . . . . . . . . . . 196

5.1. Componentes y funciones del Sistema de archivos . . . . . . . . . . . . . . . . 262

5.13. Implementación de directorios con nodos-i . . . . . . . . . . . . . . . . . . . . 284

6.1. Matriz de acceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318

Introducción a los Sistemas Operativos

N la actualidad, la mayoría de nosotros hemos tenido contacto, de alguna u otra forma,

de controlarse para un buen lavado. Si hablamos de una computadora tenemos, el procesador, la

1.1. Definición, y concepto

1.1.1.1. Tipos de usuarios de un sistema operativo

Entornos Empresariales o institucionales. Los requerimientos empresariales o instituciona-

puede acceder desde su computadora u otras terminales en diferentes lugares, incluyendo su

Usuarios Programadores. Un programador de aplicaciones es un usuario que requiere varias

Usuarios Administradores. Un usuario administrador, root(raíz) también conocido como su-

Otras funciones incluyen la preparación de nuevas unidades de disco, creación de particio-

1.1.1.2. Arquitectura de una Computadora

Ahora describiremos una de las arquitecturas de computadora más comunes, la arquitectura

Figura 1.1: Componentes de una Arquitectura Von Newmann

Unidad Central de Proceso. La unidad central de proceso es el componente principal de un

Figura 1.2: Componentes principales de la Unidad Central de Proceso

Unidad Aritmético Lógica. Su función primordial es la de efectuar los cálculos mate-

Unidad de Control. Es un circuito encargado de decodificar una instrucción máquina en

dirección(numero) −→ bus de direcciones

memoria(bus de direcciones) −→ bus de datos

contenido(bus de datos) −→ al registro AX

Memoria principal. La memoria principal también llamada Memoria de Acceso Aleatorio

IDE/EIDE/ATA (Enhanced/Integrated Device Electronics/Advanced Technology Attach-

SCSI (Small Computer-System Interface)

Sata (Serial ATA)

Figura 1.3: Dispositivos de almacenamiento masivo

Dispositivos de Entrada/Salida. Un sistema de cómputo cuenta con muchísimos dispositi-

Sistemas monoprocesadores. La mayoría de los sistemas de computadora actuales utilizan

Sistemas multiprocesadores. Un sistema multiprocesador es aquel que cuenta con más de un

Tolerancia a fallos. Si el sistema operativo es capaz de administrar adecuadamente los proce-

En la actualidad se usan solamente dos tipos de arquitecturas de sistemas multiprocesadores:

Multiprocesamiento Asimétrico. Existe un procesador maestro que se encarga de administrar

Un ejemplo de sistema con multiprocesamiento simétrico es la versión Encore de UNIX

Sistemas cluster. Un sistema cluster se diferencía de un sistema multiprocesador en que ahora