Professional Documents
Culture Documents
ndice general
Presentacin
1. Introduccin
1.1. Qu es un sistema operativo? . . . . . . . . . . . . . . . .
1.1.1. Por qu estudiar los sistemas operativos? . . . .
1.2. Funciones y objetivos de los sistemas operativos . . . . .
1.3. Evolucin de los sistemas operativos . . . . . . . . . . . .
1.3.1. Proceso por lotes (batch processing) . . . . . . . . .
1.3.2. Sistemas en lotes con dispositivos de carga (spool)
1.3.3. Sistemas multiprogramados . . . . . . . . . . . . .
1.3.4. Sistemas de tiempo compartido . . . . . . . . . . .
1.4. Y del lado de las computadoras personales . . . . . . . .
1.4.1. Primeros sistemas para entusiastas . . . . . . . . .
1.4.2. La revolucin de los 8 bits . . . . . . . . . . . . . .
1.4.3. La computadora para fines serios: la familia PC
1.4.4. El impacto del entorno grfico (WIMP) . . . . . .
1.4.5. Convergencia de los dos grandes mercados . . . .
1.5. Dispositivos mviles . . . . . . . . . . . . . . . . . . . . .
1.5.1. Resea histrica . . . . . . . . . . . . . . . . . . . .
1.5.2. Caractersticas diferenciadoras . . . . . . . . . . .
1.6. Seguridad informtica . . . . . . . . . . . . . . . . . . . .
1.6.1. Cdigo malicioso . . . . . . . . . . . . . . . . . . .
1.7. Organizacin de los sistemas operativos . . . . . . . . . .
1.8. Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.8.1. Preguntas de autoevaluacin . . . . . . . . . . . .
1.8.2. Lecturas relacionadas . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
15
15
15
16
17
17
18
18
19
20
20
21
21
22
24
25
26
29
34
35
35
38
38
39
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
41
41
41
42
44
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
NDICE GENERAL
2.3.
2.4.
2.5.
2.6.
2.7.
2.8.
2.9.
2.10.
Terminales . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dispositivos de almacenamiento . . . . . . . . . . . . . . .
Relojes y temporizadores . . . . . . . . . . . . . . . . . . . .
Canales y puentes . . . . . . . . . . . . . . . . . . . . . . . .
2.6.1. Contencin . . . . . . . . . . . . . . . . . . . . . . .
2.6.2. Acceso directo a memoria (DMA) . . . . . . . . . .
Interfaz del Sistema Operativo: llamadas al sistema . . . .
2.7.1. Llamadas al sistema, arquitecturas y APIs . . . . . .
Referencia a los componentes . . . . . . . . . . . . . . . . .
Cuando dos cabezas piensan mejor que una . . . . . . . . .
2.9.1. Multiprocesamiento . . . . . . . . . . . . . . . . . .
2.9.2. Cmputo distribudo . . . . . . . . . . . . . . . . . .
2.9.3. Amdahl y Gustafson: qu esperar del paralelismo?
Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.10.1. Preguntas de autoevaluacin . . . . . . . . . . . . .
2.10.2. Temas de investigacin sugeridos . . . . . . . . . .
2.10.3. Lecturas relacionadas . . . . . . . . . . . . . . . . .
3. Administracin de procesos
3.1. Concepto y estados de un proceso . . . . . . .
3.1.1. Estados de un proceso . . . . . . . . . .
3.1.2. Informacin asociada a un proceso . . .
3.2. Procesos e hilos . . . . . . . . . . . . . . . . . .
3.2.1. Los hilos y el sistema operativo . . . . .
3.2.2. Patrones de trabajo con hilos . . . . . .
3.3. Concurrencia . . . . . . . . . . . . . . . . . . .
3.3.1. Introduccin . . . . . . . . . . . . . . . .
3.3.2. Problema: el jardn ornamental . . . . .
3.3.3. Mecanismos de sincronizacin . . . . .
3.3.4. Problema productor-consumidor . . . .
3.3.5. Bloqueos mutuos e inanicin . . . . . .
3.3.6. Problema de los lectores y los escritores
3.3.7. La cena de los filsofos . . . . . . . . . .
3.3.8. Los fumadores compulsivos . . . . . . .
3.3.9. Otros mecanismos . . . . . . . . . . . .
3.4. Bloqueos mutuos . . . . . . . . . . . . . . . . .
3.4.1. Prevencin de bloqueos . . . . . . . . .
3.4.2. Evasin de bloqueos . . . . . . . . . . .
3.4.3. Deteccin y recuperacin de bloqueos .
3.4.4. Algoritmo del avestruz . . . . . . . . .
3.5. Ejercicios . . . . . . . . . . . . . . . . . . . . . .
3.5.1. Preguntas de autoevaluacin . . . . . .
3.5.2. Temas de investigacin sugeridos . . .
3.5.3. Lecturas relacionadas . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
47
47
48
49
49
51
52
53
55
56
56
60
61
64
64
65
66
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
67
67
67
68
69
70
70
73
73
74
84
92
95
95
98
100
103
108
110
113
118
122
124
124
126
127
NDICE GENERAL
4. Planificacin de procesos
4.1. Tipos de planificacin . . . . . . . . . . . . . . . . . .
4.1.1. Tipos de proceso . . . . . . . . . . . . . . . .
4.1.2. Midiendo la respuesta . . . . . . . . . . . . .
4.2. Algoritmos de planificacin . . . . . . . . . . . . . .
4.2.1. Objetivos de la planificacin . . . . . . . . .
4.2.2. Primero llegado, primero servido (FCFS) . .
4.2.3. Ronda (Round Robin) . . . . . . . . . . . . . .
4.2.4. El proceso ms corto a continuacin (SPN) .
4.2.5. Ronda egosta (SRR) . . . . . . . . . . . . . .
4.2.6. Retroalimentacin multinivel (FB) . . . . . .
4.2.7. Lotera . . . . . . . . . . . . . . . . . . . . . .
4.2.8. Esquemas hbridos . . . . . . . . . . . . . . .
4.2.9. Resumiendo . . . . . . . . . . . . . . . . . . .
4.3. Planificacin de hilos . . . . . . . . . . . . . . . . . .
4.3.1. Los hilos POSIX (pthreads) . . . . . . . . .
4.4. Planificacin de multiprocesadores . . . . . . . . . .
4.4.1. Afinidad a procesador . . . . . . . . . . . . .
4.4.2. Balanceo de cargas . . . . . . . . . . . . . . .
4.4.3. Colas de procesos: una o varias? . . . . . . .
4.4.4. Procesadores con soporte a hilos hardware . .
4.5. Tiempo real . . . . . . . . . . . . . . . . . . . . . . .
4.5.1. Tiempo real duro y suave . . . . . . . . . . .
4.5.2. Sistema operativo interrumpible (prevenible)
4.5.3. Inversin de prioridades . . . . . . . . . . . .
4.6. Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . .
4.6.1. Preguntas de autoevaluacin . . . . . . . . .
4.6.2. Temas de investigacin sugeridos . . . . . .
4.6.3. Lecturas relacionadas . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
129
129
131
132
135
136
137
138
140
142
143
146
147
149
152
153
154
154
155
156
156
158
159
160
160
161
161
162
163
5. Administracin de memoria
5.1. Funciones y operaciones del administrador de memoria . . .
5.1.1. Espacio de direccionamiento . . . . . . . . . . . . . .
5.1.2. Hardware: la unidad de manejo de memoria (MMU)
5.1.3. La memoria cach . . . . . . . . . . . . . . . . . . . . .
5.1.4. El espacio en memoria de un proceso . . . . . . . . .
5.1.5. Resolucin de direcciones . . . . . . . . . . . . . . . .
5.2. Asignacin de memoria contigua . . . . . . . . . . . . . . . .
5.2.1. Particin de la memoria . . . . . . . . . . . . . . . . .
5.3. Segmentacin . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.1. Permisos . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.2. Intercambio parcial . . . . . . . . . . . . . . . . . . . .
5.3.3. Ejemplificando . . . . . . . . . . . . . . . . . . . . . .
5.4. Paginacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
165
165
165
166
167
170
170
172
173
176
177
178
179
180
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
NDICE GENERAL
5.4.1. Tamao de la pgina . . . . . . . . . . . . . .
5.4.2. Almacenamiento de la tabla de pginas . . .
5.4.3. Memoria compartida . . . . . . . . . . . . . .
5.5. Memoria virtual . . . . . . . . . . . . . . . . . . . . .
5.5.1. Paginacin sobre demanda . . . . . . . . . .
5.5.2. Rendimiento . . . . . . . . . . . . . . . . . . .
5.5.3. Reemplazo de pginas . . . . . . . . . . . . .
5.5.4. Asignacin de marcos . . . . . . . . . . . . .
5.5.5. Hiperpaginacin . . . . . . . . . . . . . . . .
5.6. Consideraciones de seguridad . . . . . . . . . . . . .
5.6.1. Desbordamientos de buffer (buffer overflows)
5.6.2. Ligado esttico y dinmico de bibliotecas . .
5.7. Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . .
5.7.1. Preguntas de autoevaluacin . . . . . . . . .
5.7.2. Temas de investigacin sugeridos . . . . . .
5.7.3. Lecturas relacionadas . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
182
183
187
189
191
193
194
202
205
208
208
216
218
218
220
222
6. Organizacin de archivos
6.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2. Concepto de archivo . . . . . . . . . . . . . . . . . . . . . . . .
6.2.1. Operaciones con archivos . . . . . . . . . . . . . . . . .
6.2.2. Tablas de archivos abiertos . . . . . . . . . . . . . . . .
6.2.3. Acceso concurrente: bloqueo de archivos . . . . . . . .
6.2.4. Tipos de archivo . . . . . . . . . . . . . . . . . . . . . .
6.2.5. Estructura de los archivos y mtodos de acceso . . . . .
6.2.6. Archivos especiales . . . . . . . . . . . . . . . . . . . . .
6.2.7. Transferencias orientadas a bloques . . . . . . . . . . .
6.3. Organizacin de archivos . . . . . . . . . . . . . . . . . . . . .
6.3.1. Evolucin del concepto de directorio . . . . . . . . . . .
6.3.2. Operaciones con directorios . . . . . . . . . . . . . . . .
6.3.3. Montaje de directorios . . . . . . . . . . . . . . . . . . .
6.4. Control de acceso . . . . . . . . . . . . . . . . . . . . . . . . . .
6.4.1. Sistemas FAT . . . . . . . . . . . . . . . . . . . . . . . .
6.4.2. Modelo tradicional Unix . . . . . . . . . . . . . . . . . .
6.4.3. Listas de control de acceso . . . . . . . . . . . . . . . . .
6.5. Sistemas de archivos remotos . . . . . . . . . . . . . . . . . . .
6.5.1. Network File System (NFS) . . . . . . . . . . . . . . . .
6.5.2. Common Internet File System (CIFS) . . . . . . . . . .
6.5.3. Sistemas de archivos distribudos: Andrew File System
6.6. Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.6.1. Preguntas de autoevaluacin . . . . . . . . . . . . . . .
6.6.2. Temas de investigacin sugeridos . . . . . . . . . . . .
6.6.3. Lecturas relacionadas . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
225
225
227
227
229
230
231
233
236
237
238
238
244
247
248
249
250
252
253
254
255
256
258
258
259
259
NDICE GENERAL
7. Sistemas de archivos
7.1. Plasmando la estructura en el dispositivo . . . . . . .
7.1.1. Conceptos para la organizacin . . . . . . . . .
7.1.2. Diferentes sistemas de archivos . . . . . . . . .
7.1.3. El volumen . . . . . . . . . . . . . . . . . . . .
7.1.4. El directorio y los i-nodos . . . . . . . . . . . .
7.1.5. Compresin y desduplicacin . . . . . . . . . . .
7.1.6. Sistemas de archivos virtuales . . . . . . . . .
7.2. Esquemas de asignacin de espacio . . . . . . . . . . .
7.2.1. Asignacin contigua . . . . . . . . . . . . . . .
7.2.2. Asignacin ligada . . . . . . . . . . . . . . . . .
7.2.3. Asignacin indexada . . . . . . . . . . . . . . .
7.2.4. Las tablas en FAT . . . . . . . . . . . . . . . . .
7.3. Fallos y recuperacin . . . . . . . . . . . . . . . . . . .
7.3.1. Datos y metadatos . . . . . . . . . . . . . . . .
7.3.2. Verificacin de la integridad . . . . . . . . . . .
7.3.3. Actualizaciones suaves . . . . . . . . . . . . . .
7.3.4. Sistemas de archivo con bitcora . . . . . . . .
7.3.5. Sistemas de archivos estructurados en bitcora
7.4. Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . .
7.4.1. Preguntas de autoevaluacin . . . . . . . . . .
7.4.2. Temas de investigacin sugeridos . . . . . . .
7.4.3. Lecturas relacionadas . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
261
261
261
263
264
265
271
274
276
276
277
278
281
283
285
286
286
288
289
290
290
291
291
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
295
295
295
296
297
298
300
301
303
304
304
.
.
.
.
.
.
.
307
307
308
309
311
312
313
314
B. Virtualizacin
B.1. Introduccin . . . . . . . . . . . . . . . . . .
B.2. Emulacin . . . . . . . . . . . . . . . . . . .
B.2.1. Emulando arquitecturas inexistentes
B.2.2. De lo abstracto a lo concreto . . . . .
B.2.3. Emulacin o simulacin? . . . . . .
B.3. Virtualizacin asistida por hardware . . . .
B.3.1. El hipervisor . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
NDICE GENERAL
B.3.2. Virtualizacin asistida por hardware en x86 .
B.4. Paravirtualizacin . . . . . . . . . . . . . . . . . . . .
B.4.1. Paravirtualizacin y software libre . . . . . .
B.4.2. Paravirtualizacin de dispositivos . . . . . .
B.5. Contenedores . . . . . . . . . . . . . . . . . . . . . .
B.6. Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . .
B.6.1. Preguntas de autoevaluacin . . . . . . . . .
B.6.2. Temas de investigacin sugeridos . . . . . .
B.6.3. Lecturas relacionadas . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
314
316
317
317
318
320
320
322
322
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
325
325
325
333
337
338
339
340
340
342
343
344
345
346
347
347
347
347
Presentacin
Acerca del libro
Este libro busca brindar a estudiantes y docentes de las carreras de Ingeniera en Computacin, Informtica, Ciencias de la Computacin y similares un material completo, general y autocontenido sobre la materia de Sistemas Operativos. No se asume conocimiento previo sobre la temtica, aunque se utilizarn
conceptos de estructuras de datos y algoritmos bsicos.
Justificacin
Actualmente existe vasta bibliografa sobre Sistemas Operativos, sin embargo la gran mayora est escrita en ingls, y cuando estn disponibles en
castellano, su traduccin deja mucho que desear, llevando a conceptos confusos y difciles de comprender. La intencin de los autores es que el presente
texto provea un material redactado originalmente en castellano, revisado por
docentes latinoamericanos utilizando la terminologa ms adecuada para los
alumnos de la regin y eliminando muchos de los errores de traduccin.
Generalmente el material de cursos de Sistemas Operativos est compuesto
por partes de distintos libros, artculos de investigacin, recursos en linea, software, ejercitacin, etc. Por ello, el alumno debe recurrir a distintas fuentes durante el curso. El presente libro pretende ser de utilidad tanto para alumnos como para docentes como una nica publicacin autocontenida. Cabe remarcar
tambin que el material bibliogrfico generalmente est protegido por derecho
de autor, es costoso y en muchos casos de dificil acceso (sobre todo las publicaciones en ingls).
Los contenidos de la bibliografa clsica de Sistemas Operativos estn
basadas en re-ediciones y compendio de libros de hace varias dcadas que incluyen temas obsoletos o desactualizados. Existen tambin desarrollos y tendencias nuevas en el rea que aun no han sido integradas en la bibliografa
clsica, y mucho menos a las traducciones. El presente libro pretende tambin
revisar y actualizar los conceptos clsicos de sistemas operativos inlcuyendo
material de publicacin reciente.
9
10
CAPTULO 0. PRESENTACIN
Este libro se desarroll dentro del marco del Proyecto LATIn, enfocado a la
creacin de libros de texto con un esquema de licenciamiento libre, derivados
de la creacin y colaboracin de grupos de trabajo multinacionales, para la
regin latinoamericana.
Pblico objetivo
Este libro est apuntado tanto a estudiantes de carreras de informtica,
computacin e ingenieras como a los aficionados de la computadora interesados en conocer un poco ms de lo que realmente ocurre dentro de un sistema
de cmputo y el rol que cumple el sistema operativo.
Al finalizar el libro se espera que el lector haya adquirido conocimientos y
habilidades como:
Administrar, disear y desarrollar un sistema operativo.
Conociendo el funcionamiento general de los sistemas operativos, poder
sacar mejor provecho de la computadora
Conocer y saber aprovechar no slo los sistemas, sino las metodologas y
principales formas de interaccin del software libre
Se asume tambin que el lector est familiarizado con algn lenguaje de
programacin de alto nivel, y al menos a nivel bsico con C. Aunque los
ejemplos de cdigo estn dados en diversos lenguajes de programacin (Bash,
Perl, c, PascalFC, Python, Ruby, Ensamblador, entre otros), stos son tan sencillos que pueden ser fcilmente escritos en el lenguaje de eleccin del lector sin
mayor esfuerzo.
Resultar muy conveniente que tener acceso a una computadora con sistema operativo Linux (GNU) u otro Unix libre.
Estructura temtica
El texto comprende los siguientes captulos:
1. Introduccin Para comenzar a hablar de sistemas operativos, es necesario
en primer trmino enmarcar qu es un sistema operativo y cules son
sus funciones principales. Tambin es importante detallar algunos puntos que, contrario a la percepcin comn, no pueden considerarse parte de
sus funciones.
Este tema se presenta apoyado de la evolucin histrica del cmputo, haciendo nfasis en por qu este proceso evolutivo en particular desemboc
en los sistemas operativos que existen hoy en da.
11
2. Relacin con el hardware Partiendo de que una de las principales tareas del
sistema operativo es presentar una abstraccin regular del hardware a los
procesos que se ejecuten, resulta importante presentar cmo ste est estructurado, y cmo el sistema operativo puede comunicarse con l.
Este captulo aborda la jerarqua de almacenamiento, el mecanismo de interrupciones y excepciones y el papel que juegan para las llamadas al sistema,
las caractersticas base de diversos tipos de dispositivo del sistema, el
concepto de canales (o buses) de comunicacin, el mecanismo de acceso directo a memoria, y una introduccin a lo que puede ser visto como tema
conductor a lo largo de todo el libro: La importancia y complejidad de la
concurrencia, y su relacin con el paralelismo y multiprocesamiento.
3. Administracin de procesos La entidad principal con la que interacta un
sistema operativo (sea para brindarle servicios o para imponerle restricciones) es el proceso. Este captulo inicia presentando los diferentes estados de los procesos y la relacin entre stas y sus hermanos menores (los
hilos), y los principales modelos empleados para el multiprocesamiento.
Todos los sistemas operativos modernos tienen que enfrentar a la concurrencia: La incertidumbre del ordenamiento en el tiempo entre eventos
relativos a los diferentes procesos e hilos. La parte medular de este captulo presenta a las primitivas de sincronizacin: Mutexes, semforos y monitores. Para ilustrarlas, se emplean los patrones y problemas clsicos que
se han seguido a lo largo de su desarrollo histrico.
Pero las primitivas pueden slamente utilizarse entre procesos que cooperan deliberadamente entre s. Un sistema operativo debe implementar
proteccin y separacin incluso entre procesos que compiten o que sencillamente no saben el uno acerca del otro. Por ello, la ltima seccin de
este captulo aborda los diferentes mecanismos que existen para evitar
las situaciones de bloqueo mutuo.
4. Planificacin de procesos Para que varios procesos coexistan en un sistema
de cmputo, el primer recurso que el sistema operativo debe multiplexar o
repartir entre todos ellos es el tiempo de cmputo: el uso del procesador.
Este captulo presenta los diferentes niveles de planificador que forman
parte de un sistema operativo, y analiza al planificador a corto plazo (tambin conocido como despachador). Se presentan los principales algoritmos,
y se ilustra cmo los sistemas operativos modernos van empleando tcnicas mixtas de varios de ellos.
Por ltimo, se abordan tres temas brevemente: nos diferentes modelos
de planificacin de hilos y su relacin con los procesos, las particularidades de la planificacin en un entorno con multiprocesadores reales, y
las necesidades de planificacin de tiempo real.
12
CAPTULO 0. PRESENTACIN
5. Administracin de memoria Los programas slo se vuelven procesos cuando se les asigna memoria y tiempo de cmputo: cuando dejan de ser el
resultado de una compilacin guardada estticamente para convertirse
en una entidad dinmica. Este captulo presenta en primer lugar la visin
desde dentro de la memoria por parte de cada uno de los procesos: el espacio de direccionamiento y el acomodo clsico de las regiones de un
proceso en la memoria que le es asignada.
Para que los distintos procesos compartan la memoria del sistema, a lo
largo de la historia se han presentado diferentes esquemas. Se presentan someramente los esquemas de particin contigua fija y variable, para
profundizar posteriormente en los que ofrecen mayor flexibilidad al sistema operativo y se mantienen en uso al da de hoy: la segmentacin y la
paginacin. De esta ltima, se contina para presentar la abstraccin que
ha liberado a los sistemas operativos para sobrecomprometer la memoria
de forma eficiente y prcticamente transparente: la memoria virtual.
Al manejar la memoria de un proceso surgen puntos importantes a tomar
en cuenta en lo relativo a la seguridad en cmputo; la parte final de
este captulo presenta la vulnerabilidad conocida como desbordamiento de
buffer (buffer overflow), y algunas estrategias de mitigacin que se han implementado con el paso de los aos para mitigar su peligrosidad.
6. Organizacin de archivos De cara al usuario, probablemente la principal
abstraccin implementada por el sistema operativo es la organizacin
de la informacin sobre un medio persistente. Hoy en da, la norma es
que esta organizacin se realice en archivos estructurados sobre una estructura jerrquica llamada directorio. Este captulo se centra en explicar
esta abstraccin, sin entrar an en detalles respecto a cmo se llega a un
respaldo fsico de la misma.
Estos conceptos parecen tan pervasivos y universales que podra pensarse que no requieren mayor anlisis. Sin embargo, resulta importante
abordar las diferencias semnticas derivadas del desarrollo histrico de
distintos sistemas. En este captulo se presentan varios conceptos cuya
implementacin en un medio que asegure la persistencia se describir en
el siguiente captulo.
Por ltimo, en este captulo se incluye un breve repaso de distintos tipos
de sistemas de archivos en red, enfatizando nuevamente en los cambios
semnticos derivados de la distinta historia de cada implementacin.
7. Sistemas de archivos Este captulo presenta la contraparte obligada del anterior: cmo se estructuran los dispositivos de almacenamiento a largo
plazo, a los cuales se hace referencia genricamente como discos? Cmo
se van plasmando las estructuras mediante las cuales el usuario organiza la informacin en bloques dentro de un dispositivo? Qu problemas
13
pueden derivar del uso de estos sistemas de archivos, y qu mtodos para
evitarlos o resolverlos se han implementado?
La parte central de este captulo se centra en un sistema de archivos bastante viejo y simple, pero an en muy amplio uso en el cmputo moderno: la familia FAT.
Los siguientes temas resultan muy importantes para la comprensin y para
el desarrollo futuro de la materia, pero dado que son empleados por el sistema
operativo (y no necesariamente son parte integral del mismo), se presentan como apndices
A. Software libre y licenciamiento Estudiar sistemas operativos cruza necesariamente la temtica del software libre. Uno de los principios fundamentales del desarrollo histrico es la libertad de aprender, esto es, todo
software que se diga libre debe permitir a sus usuarios comprender sus
estructuras bsicas, la relacin entre ellas, y la lgica general de su programacin.
Hoy en da existe una gran cantidad de sistemas operativos libres, tanto de propsito general como enfocados a un nicho. El movimiento ideolgico del software libre, contrario a cualquier pronstico que pudiera
haberse hecho al iniciarse en 1984, claramente ha cambiado el desarrollo
del cmputo. Todos los sistemas operativos que pueden ser estudiados de
primera mano, constatando la implementacin de sus principios son necesariamente (aunque con una definicin ligeramente laxa) software libre.
Hacia el ao 2000 se fue haciendo claro que estas ideas no pueden aplicarse nicamente al software. Poco a poco fue definindose una nocin
mucho ms amplia, la de los bienes culturales libres. El presente libro busca
ser una contribucin a esta ltima categora.
El primer apndice aborda brevemente estos temas, as como los principales modelos de licenciamiento libre utilizados.
B. Virtualizacin La virtualizacin es una herramienta muy til, y cada vez
ms al alcance de todos, para el aprendizaje de los sistemas operativos.
Hay una gran cantidad de recursos para comprender desde los primeros
momentos del arranque de la computadora. Empleando imgenes de
mquinas virtuales, pueden comprenderse y desmenuzarse los distintos
elementos del sistema operativo, e incluso observar el resultado de realizar modificaciones sobre un sistema operativo real. Es, por tanto, una
herramienta muy importante para acompaar al aprendizaje de esta materia.
La virtualizacin es tambin una tecnologa que permea cada vez ms
aspectos del uso profesional del cmputo, y comprenderlo ayudar al
lector a elegir las herramientas especficas a emplear.
14
CAPTULO 0. PRESENTACIN
Pero hablar de la virtualizacin como un todo ignorara aspectos fundamentales de la riqueza que presenta este campo. Al igual que con los
conceptos presentados a lo largo del libro, la virtualizacin es presentada a partir de su perspectiva histrica, y detallando hacia las distintas
modalidades que se han desarrollado al paso del tiempo.
Licenciamiento
Este libro fue desarrollado como parte del Proyecto LATIn, que busca la
creacin de libros de texto libres para nivel universitario, y enfocado a Latinoamrica.
Cualquier porcin de este libro puede ser reproducido y utilizado para todo
fin, bajo los trminos de la licencia Creative Commons-Atribucin-CompartirIgual
(CC-BY-SA) versin 4.0.
Este modelo de licenciamiento se presenta y explica en la seccin A.2.1.
Captulo 1
Introduccin
1.1.
Qu es un sistema operativo?
El sistema operativo es el principal programa que se ejecuta en toda computadora de propsito general.
Hay sistemas operativos de todo tipo, desde muy simples hasta terriblemente complejos, y entre ms casos de uso hay para el cmputo en la vida
diaria, ms variedad habr en ellos.
A lo largo del presente texto, no se hace referencia al sistema operativo como lo ve o usa el usuario final, o como lo vende la mercadotecnia el ambiente
grfico, los programas que se ejecutan en ste, los lenguajes de programacin
en que estn desarrollados y en que ms fcilmente se puede desarrollar para
ellos, e incluso el conjunto bsico de funciones que las bibliotecas base ofrecen
son principalmente clientes del sistema operativo se ejecutan sobre l, y ofrecen su implementacin a sus usuarios (includos, claro, los desarrolladores). La
diferencia en el uso son slo y si mucho consecuencias del diseo de un sistema operativo. Ms an, con el mismo sistema operativo como pueden constatarlo comparando dos distribuciones de Linux, o incluso la forma de trabajo
de dos usuarios en la misma computadora es posible tener entornos operativos
completamente dismiles.
1.1.1.
16
CAPTULO 1. INTRODUCCIN
1.2.
17
1.3.
No se puede comenzar a abordar el tema de los sistemas operativos sin revisar brevemente su desarrollo histrico. Esto no slo permitir comprender
por qu fueron apareciendo determinadas caractersticas y patrones de diseo
que se siguen empleando dcadas ms tarde, sino (como resulta particularmente bien ejemplificado en el discurso de recepcin del premio Turing de
Fernando Corbat en 1990, On building systems that will fail), adecuar un sistema existente a un entorno cambiante, por mejor diseado que ste estuviera,
lleva casi inevitablemente a abrir espacios de comportamiento no previsto
el espacio ms propicio para que florezcan los fallos. Conocer los factores que
motivaron a los distintos desarrollos puede ayudar a prever y prevenir problemas.
1.3.1.
18
CAPTULO 1. INTRODUCCIN
quienes las alimentaban a los dispositivos lectores, que lo cargaban en memoria en un tiempo razonable, iniciaban y monitoreaban la ejecucin, y producan
los resultados.
En esta primer poca en que las computadoras se especializaban en tareas
de clculo intensivo y los dispositivos que interactuaban con medios externos
eran prcticamente desconocidos, el rol del sistema monitor o de control era bsicamente asistir al operador en la carga de los programas y las bibliotecas requeridas, la notificacin de resultados y la contabilidad de recursos empleados
para su cobro.
Los sistemas monitores se fueron sofisticando al implementar protecciones
que evitaran la corrupcin de otros trabajos (por ejemplo, lanzar errneamente
la instruccin leer siguiente tarjeta causara que el siguiente trabajo encolado
perdiera sus primeros caracteres, corrompindolo e impidiendo su ejecucin),
o que entraran en un ciclo infinito, estableciendo alarmas (timers) que interrumpiran la ejecucin de un proceso si ste duraba ms all del tiempo estipulado. Estos monitores implicaban la modificacin del hardware para contemplar
dichas caractersticas de seguridad y ah se puede hablar ya de la caracterstica bsica de gestin de recursos que identifica a los sistemas operativos.
Cabe aadir que el tiempo de carga y puesta a punto de una tarea segua
representando una parte importante del tiempo que la computadora dedicaba
al procesamiento: un lector de cintas rpido procesaba del orden de cientos de
caracteres por minuto, y a pesar de la lentitud relativa de las computadoras de
los 50 ante los estndares de hoy (se mediran por miles de instrucciones por
segundo, KHz, en vez de miles de millones como se hace hoy, GHz), esperar
cinco o diez minutos con el sistema completamente detenido por la carga de
un programa moderadadamente extenso resulta a todas luces un desperdicio.
1.3.2.
Una mejora natural a este ltimo punto fue la invencin del spool: un
mecanismo de entrada/salida que permita que una computadora de propsito especfico, mucho ms econmica y limitada, leyera las tarjetas y las fuera
convirtiendo a cinta magntica, un medio mucho ms rpido, tenindola lista
para que la computadora central la cargara cuando terminara con el trabajo anterior. Del mismo modo, la computadora central guardarba sus resultados en
cinta para que equipos especializados la leyeran e imprimieran para el usuario
solicitante.
La palabra spool (bobina) se tom como acrnimo inverso hacia Simultaneous
Peripherial Operations On-Line, operacin simultnea de perifricos en lnea.
1.3.3.
Sistemas multiprogramados
19
1.3.4.
20
CAPTULO 1. INTRODUCCIN
1.4.
1.4.1.
Las primeras computadoras personales eran distribudas sin sistemas operativos o lenguajes de programacin; la interfaz primaria para programarlas era
a travs de llaves (switches), y para recibir sus resultados, se utilizaban bancos
de LEDs. Claro est, esto requera conocimientos especializados, y las computadoras personales eran an vistas slo como juguetes caros.
21
Figura 1.1: La microcomputadora Altair 8800, primer computadora personal con distribucin masiva, a la venta a partir de 1975. (Imagen de la Wikipedia: Altair 8800)
1.4.2.
La verdadera revolucin apareci cuando poco tiempo ms tarde, comenzaron a venderse computadoras personales con salida de video (tpicamente a
travs de una televisin) y entrada a travs de un teclado. Estas computadoras
popularizaron el lenguaje de programacin BASIC, diseado para usuarios novatos en los 60, y para permitir a los usuarios gestionar sus recursos (unidades
de cinta, pantalla posicionable, unidades de disco, impresoras, modem, etc.)
llevaban un software mnimo de sistema nuevamente, un proto-sistema operativo.
Figura 1.2: La Commodore Pet 2001, en el mercado desde 1977, una de las primeras
con intrprete de BASIC. (Imagen de la Wikipedia: Commodore PET)
1.4.3.
22
CAPTULO 1. INTRODUCCIN
Figura 1.3: La computadora IBM PC modelo 5150 (1981), iniciadora de la arquitectura predominantemente en uso hasta el da de hoy. (Imagen de la Wikipedia: IBM
Personal Computer)
Ante las aplicaciones, el sistema operativo (PC-DOS, en las versiones distribudas directamente por IBM, o el que se populariz ms, MS-DOS, en los
clones) ofreca la ya conocida serie de interfaces y abstracciones para administrar los archivos y la entrada/salida a travs de sus puertos. Cabe destacar que,
particularmente en sus primeros aos, muchos programas se ejecutaban directamente sobre el hardware, arrancando desde el BIOS y sin emplear el sistema
operativo.
1.4.4.
Hacia mediados de los 80 comenzaron a aparecer computadoras con interfaces usuario grficas (Graphical User Interfaces, GUIs) basadas en el paradigma WIMP (Windows, Icons, Menus, Pointer; Ventanas, Iconos, Menes, Apuntador), que permitan la interaccin con varios programas al mismo tiempo.
Esto no necesariamente significa que sean sistemas multitarea por ejemplo,
la primer interfaz de MacOS permita visualizar varias ventanas abiertas simultneamente, pero slo el proceso activo se ejecutaba.
23
Figura 1.4: Apple Macintosh (1984), populariz la interfaz usuario grfica (GUI).
(Imagen de la Wikipedia: Macintosh)
24
CAPTULO 1. INTRODUCCIN
Figura 1.5: Commodore Amiga 500 (1987), la computadora ms popular de la familia Amiga, con amplias capacidades multimedia y multitarea apropiativa; una
verdadera maravilla para su momento. (Imagen de la Wikipedia: Amiga)
1.4.5.
25
Y otro importante jugador que entr en escena durante los 90 fue el software libre, por medio de varias implementaciones distintas de sistemas tipo
Unix principalmente, Linux y los *BSD (FreeBSD, NetBSD, OpenBSD). Estos sistemas implementaron, colaborativamente y a escala mundial, software
compatible tanto con las PC como con el que se ejecutaba en las estaciones de
trabajo a gran escala, con alta confiabilidad, y cerrando por fin la divergencia
del rbol del desarrollo de la computacin en fierros grandes y fierros chicos.
Al da de hoy, la arquitectura derivada de Intel (y la PC) es el claro ganador
de este proceso de 35 aos, habiendo conquistado casi la totalidad de los casos
de uso, incluso las mquinas Apple. Hoy en da, la arquitectura Intel ejecuta
desde subporttiles hasta supercomputadoras y centros de datos; el sistema
operativo especfico vara segn el uso, yendo mayoritariamente hacia Windows, con los diferentes Unixes concentrados en los equipos servidores.
En el frente de los dispositivos embebidos (las computadoras ms pequeas,
desde microcontroladores hasta telfonos y tabletas), la norma es la arquitectura ARM, tambin bajo versiones especficas de sistemas operativos Unix y
Windows (en ese orden).
1.5.
Dispositivos mviles
En los ltimos aos, buena parte del desarrollo en el mundo del cmputo se
ha volcado hacia el modelo de cmputo representado, genricamente, por los
dispositivos mviles. Dado el inters que estas plataformas han despertado, se
torna necesario abordar el tema, aunque sea ms para anotar similitudes que
diferencias con el resto de los equipos de cmputo. Para hacer esto, sin embargo, es necesario primero abordar la definicin: En qu consiste un dispositivo
mvil? Cules son los lmites de su definicin? Qu fronteras se le pueden
definir?
Es dificil encontrar lmites claros y duros para lo que este concepto abarca;
en el transcurso de esta seccin se abordan las caractersticas de las computadoras diseadas no slo a nivel hardware sino que de interfaz usuario para
que su propietario las cargue consigo y las convierta en un asistente para sus
actividades cotidianas, para la organizacin de su vida diaria. Partiendo de esta definicin se tiene que un telfono inteligente ser tratado como dispositivo
mvil, pero una computadora porttil no, puesto que su interfaz es la misma
de una computadora estndar.
Claro, esta definicin indudablemente rpida e imperfecta deja una gran
rea gris, y permite cierta ambigedad. Por ejemplo, las ms recientes versiones de algunos entornos de usuario (notablemente, la interfaz primaria de
Windows 8, o los entornos GNOME y Unity de Linux) buscan unificar la experiencia, incorporando conceptos del multitouch a los escritorios y acercando los
casos de uso. Tmense, pues, estos lineamientos como meramente indicativos.
26
CAPTULO 1. INTRODUCCIN
1.5.1.
Resea histrica
Figura 1.6: Psion Organiser, anunciada como la primer computadora de bolsillo prctica
del mundo en 1984. En la imagen, un dispositivo de su segunda generacin. (Imagen
de la Wikipedia: Psion Organiser)
El hardware del Organiser original era, claro est, muy limitado. Con slo
4KB de ROM y 2KB de RAM no inclua un sistema operativo, y el lenguaje de
programacin disponible al usuario era meramente un ensamblador. No tener
27
un sistema operativo significa que, en vez de hacer las llamadas al sistema necesarias para realizar transferencias (como se ver en la seccin 2.7 y en el captulo 7), el programador tena que avanzar y transferir byte por byte. Dos aos
ms tarde, la segunda generacin del Organiser sali al mercado con un sistema
operativo monotarea y mucho mayor espacio de almacenamiento. Varias generaciones ms tarde, este sistema operativo es el que hacia 1998 se convirti en
Symbian, que fuera el sistema operativo dominante del mercado de celulares
durante la mayor parte de la dcada del 2000.
Figura 1.7: Sharp ZQ-770, diseo bajo uno de los formatos de PDA (Asistente Personal Digital) ms popularizados de la dcada de los 90. (Imagen de la Wikipedia:
Sharp Wizard)
Siguiendo los pasos del Organiser, muchas otras empresas fueron creando
pequeos equipos con aproximadamente la misma funcionalidad bsica (lista
de contactos, notas y agenda) e interfaz usuario, definiendo el trmino de Asistente Digital Personal (Personal Digital Assistant, PDA). Hubo diferentes hitos
durante la dcada de los 90, aunque destaca particularmente la plataforma
Palm. Esta fue la primer plataforma exitosa en incorporar una interfaz usuario
tctil con escritura basada en reconocimiento de la letra (que era trazada por
medio de una pluma especial, o stylus, en la pantalla).
El siguiente paso natural fue unir la funcionalidad del cada vez ms popular telfono celular con la del PDA. Ya desde 1996 se comercializaron equipos
ofreciendo la funcionalidad integrada, y el trmino smartphone (telfono inteligente) se emple por primera vez en 1998. Como se ver en la seccin 1.5.2,
el reto de mantener la sealizacin estable signific que muchos de estos telfonos resultaban en una suerte de Frankenstein, con dos personalidades claramente diferenciadas.
En el ao 2007, Apple present su hoy icnico iPhone. Visto desde un punto
de vista tcnico, la principal inovacin de este equipo fue una nueva interfaz
grfica denominada multitouch (multitoque), que permite al usuario interactuar
directamente con sus dedos (por medio de toques combinados o gestos y ya no
requiriendo de un stylus) e incluso de la inclinacin del dispositivo. Y si bien el
telfono mismo no represent un salto en las capacidades del hardware, Apple
logr disear una interfaz inovadora como ya lo haba hecho en 1984 con la
28
CAPTULO 1. INTRODUCCIN
29
Android Diseado por la compaa Google, basa la mayor parte de su operacin en software libre (un ncleo Linux, mquina virtual Java, y
muchas de las bibliotecas de sistema comunes en sistemas Linux), agregando una capa de servicios propietarios. La estrategia de Google ha sido
inversa a la de Apple: En vez de fabricar sus propios dispositivos, otorga
licencias para el uso de este sistema operativo a prcticamente todos los
fabricantes de hardware, con lo que la amplia mayora de los modelos de
telfonos inteligentes y tabletas corren sobre Android.
Windows Phone Microsoft ofrece una versin de su sistema operativo, compatible a nivel API con el Windows de escritorio, pero compilado para
procesador ARM. Este sistema operativo no ha logrado conquistar gran
popularidad, en claro contraste con su dominacin en el cmputo tradicional de escritorio; el principal fabricante que vende equipos con Windows Phone es Nokia (que, despus de haber sido la compaa lder en
telefona, fue adquirida por Microsoft mismo).
Symbian Si bien este sistema operativo ya est declarado como oficialmente
muerto, su impacto en el desarrollo temprano del segmento fue fundamental, y no puede ser ignorado. Symbian fue la plataforma principal
para Nokia en su poca de gloria, as como para muchos otros fabricantes.
Casi todas las empresas que antiguamente operaban con Symbian han
mudado su oferta a sistemas Android.
Firefox OS La fundacin Mozilla, responsable del navegador Firefox (y heredera del histrico Netscape) est intentando entrar al mercado mbil con
este sistema, basado (al igual que Android) en el ncleo de Linux, pero
orientado a ofrecer una interfaz de programacin completamente basada
en los estndares y lenguajes en uso para la Web. Esta plataforma hace
una apuesta mucho ms agresiva que las dems a un esquema de conexin permanente a la red de datos.
1.5.2.
Caractersticas diferenciadoras
30
CAPTULO 1. INTRODUCCIN
31
32
CAPTULO 1. INTRODUCCIN
33
configuracin de consumo energtico. Las interfaces y direcciones de red son tpicamente estables, y si hubiera un problema de seal, la reparacin o reubicacin se hara en la infraestructura de red, no en el equipo cliente. El formato
de la pantalla, claro est, es tambin estable.
Uno de los cambios ms difciles de implementar en el software del sistema
fue precisamente el de brindar la plasticidad necesaria en estos diferentes aspectos: El dispositivo mvil debe ser ms agresivo en sus cambios de perfil de
energa, respondiendo a un entorno cambiante. Puede aumentar o disminuir
la luminosidad de la pantalla dependiendo de la luminosidad circundante, o
desactivar determinada funcionalidad si est ya en niveles crticos de carga.
Con respecto a la red, debe poder aprovechar las conexiones fugaces mientras
el usuario se desplaza, iniciando eventos como el de sincronizacin. Y encargndose de detener (tan limpiamente como sea posible) a los procesos que van
dejando de responder. Y por ltimo, claro, la interfaz usuario: Los dispositivos
mviles no tienen una orientacin nica natural, como s la tienen las computadoras. Las interfaces usuario deben pensarse para que se puedan reconfigurar
gilmente ante la rotacin de la pantalla.
El jardn amurallado
Una consecuencia indirecta (y no tcnica) del nacimiento de las plataformas mviles es la popularizacin de un modelo de distribucin de software
conocido como jardn amurallado o, lo que es lo mismo, una plataforma cerrada.
Partiendo de que los telfonos inteligentes, en un primer momento, y las
tabletas y dispositivos similares posteriormente buscan satisfacer a un mercado
mucho mayor al de los entusiastas del cmputo,4 Apple anunci en julio del
2008 (un ao despus del lanzamiento del iPhone) su tienda de aplicaciones o
app store. La peculiaridad de esta tienda en relacin al modelo de cmputo
que ha imperado histricamente es que, si bien cualquier desarrollador puede
crear una aplicacin y enviarla, Apple se reserva el derecho de aprobarla, o
eliminarla en cualquier momento. Esto es, este modelo le permite erigirse en
juez, determinando qu puede ejecutar un usuario y qu no.
Este mismo modelo fue adoptado por Google para su sistema Android, en
un principio bajo el nombre Mercado Android, y desde el 2012 como Google Play.
Microsoft hizo lo propio con su Windows Phone Store.
Este modelo de autorizacin y distribucin de software, sin embargo,
rompe con lo que Jonathan Zittrain (2008) define como la generatividad de los
equipos de cmputo y de la red en general. Para ampliar el debate en este
entido, el libro de Zittrain se ha vuelto referencia obligada, y est disponible
completo en lnea.
4 Y tambin como respuesta a que algunos usuarios encontraron cmo romper la proteccin y
poder desarrollar e instalar aplicaciones extraoficiales en esta plataforma, diseada originalmente
para slo correr software de Apple.
34
1.6.
CAPTULO 1. INTRODUCCIN
Seguridad informtica
35
1.6.1.
Cdigo malicioso
Los sistemas operativos, al igual que todo programa de cmputo, presentan imperfecciones, errores u omisiones, tanto en su diseo como en su implementacin. El cdigo malicioso (tambin conocido como malware) consiste en
programas diseados para aprovechar a dichas vulnerabilidades para adquirir
privilegios de ejecucin o acceso a datos que de otro modo no habran logrado.
Si la vulnerabilidad que aprovecha el cdigo malicioso es resultado de un
error en la implementacin, el desarrollador del sistema operativo tpicamente
podr corregirla y poner esta correccin (coloquialmente denominada parche) a
disposicin de los usuarios; en los sistemas operativos modernos, la instalacin
de estas correcciones se efecta de forma automatizada. Por otro lado, si la
vulnerabilidad es consecuencia de una debilidad en el diseo, su correccin
puede ser mucho ms compleja Incluso puede ser imposible de resolver,
como el caso presentado en la seccin 5.6.1.5
Cabe mencionar que una gran cantidad de cdigo malicioso atacan a una
capa particularmente dbil de todo sistema de cmputo: Al usuario. Un aspecto frecuente (y de muy difcil solucin) de estos programas es que engaan al
usuario presentndose como cdigo legtimo, y si ste reacciona como el cdigo malicioso busca, le permitir la ejecucin en el sistema con sus privilegios.
El cdigo malicioso tiende a agruparse y clasificarse de acuerdo a su comportamiento, particularmente de cara al usuario: Virus, gusanos, caballos de troya,
exploits, y muchos ms. Sin embargo, y dado que sus diferencias radican particularmente en su diferente comportamiento ante el usuario o como programa en
ejecucin (y se comportan en lneas generales del mismo modo ante el sistema
operativo), se determin que entrar en detalles al respecto resultara fuera del
mbito de la presente obra.
1.7.
36
CAPTULO 1. INTRODUCCIN
el uso de uno con otro (fuera de hacerlo con fines de explicar diferentes implementaciones).
Al nivel que se estudiar, un sistema operativo es ms bien un gran programa, que ejecuta otros programas y les provee un conjunto de interfaces para
que puedan aprovechar los recursos de cmputo. Hay dos formas primarias
de organizacin interna del sistema operativo: los sistemas monolticos y los
sistemas microkernel. Y si bien no se puede marcar una lnea clara a rajatabla
que indique en qu clasificiacin cae cada sistema, no es dificil encontrar lneas
bases.
Monolticos La mayor parte de los sistemas operativos histricamente han sido monolticos esto significa que hay un slo proceso privilegiado (justamente el sistema operativo) que opera en modo supervisor, y dentro del
cual se encuentran todas las rutinas para las diversas tareas que realiza el
sistema operativo.
Microkernel El ncleo del sistema operativo se mantiene en el mnimo posible de funcionalidad, descargando en procesos especiales sin privilegios las
tareas que implementan el acceso a dispositivos y las diversas polticas
de uso del sistema.
La principal ventaja de disear un sistema siguiendo un esquema monoltico es la simplificacin de una gran cantidad de mecanismos de comunicacin,
que lleva a una mayor velocidad de ejecucin (al requerir menos cambios de
contexto para cualquier operacin realizada). Adems, al manejarse la comunicacin directa como paso de estructuras en memoria, el mayor acoplamiento
permite ms flexibilidad al adecuarse para nuevos requisitos (al no tener que
modificar no slo al ncleo y a los procesos especiales, sino tambin la interfaz
pblica entre ellos).
37
Sistemas con concepciones hbridas No se puede hablar de concepciones nicas ni de verdades absolutas. A lo largo del libro se vern ejemplos de
concepciones hbridas en este sentido sistemas que son mayormente
monolticos pero manejan algunos procesos que pareceran centrales a
travs de procesos de nivel usuario como los microkernel (por ejemplo,
los sistemas de archivos en espacio de usuario, FUSE, en Linux).
38
CAPTULO 1. INTRODUCCIN
1.8.
Ejercicios
1.8.1.
Preguntas de autoevaluacin
1.8. EJERCICIOS
39
c) Discos
d) Impresora
4. Un programa tpicamente pasa por varias etapas en su ejecucin, algunas
de las cuales estn limitadas por el procesador, mientras que las otras
estn limitadas por la entrada/salida. Los componentes del sistema que
estn ocupados en cada caso son distintos.
Qu tipo de sistemas nacieron para responder a esta necesidad?
5. Se present que un sistema microkernel se basa en la simplificacin de
los mecanismos de comunicacin y un esquema ms claro de comunicacin entre componentes. Sin embargo, los sistemas monolticos siempre
fueron ms simples de implementar, razn por la cual muchos sistemas
microkernel se han reducido a ejercicios acadmicos. Explique esta tensin.
6. De los sistemas operativos ampliamente utilizados que conozca, cules
son microkernel? cules son monolticos?
7. Si bien los sistemas operativos empleados para dispositivos mviles son
los mismos que los que utilizan las computadoras personales. Sin embargo, hay reas particulares, como la interfaz al usuario o el manejo de la
energa, que son claramente distintos. Cmo puede verse la influencia
en el sentido inverso? Esto es, qu tanto ha infludo la popularizacin
de los dispositivos mviles en el camino de los sistemas operativos en
general?
1.8.2.
Lecturas relacionadas
Michael Kerrisk (2013); Linux Weekly News: explica algunas de las limitantes de la semntica POSIX como la falta de granularidad en el reporte
de mensajes de error (EPERM) y errno global por hilo.
Biculturalism
http://www.joelonsoftware.com/articles/Biculturalism.html
40
CAPTULO 1. INTRODUCCIN
The future of the Internet and how to stop it
http://futureoftheinternet.org/
Captulo 2
Introduccin
Todos los sistemas de cmputo estn compuestos por al menos una unidad
de proceso junto con dispositivos que permiten ingresar datos (teclado, mouse,
micrfono, etc.) y otros que permiten obtener resultados (pantalla, impresora, parlantes, etc.). Como se vio anteriormente, una de las funciones del sistema operativo es la de abstraer el hardware de la computadora y presentar al
usuario una versin unificada y simplificada de los dispositivos. En este captulo se ver la relacin que mantiene el sistema operativo con el hardware,
las funciones que cumplen y algunas abstracciones comunes utilizadas en sistemas operativos modernos.
2.2.
Unidad de Procesamiento
La unidad de procesamiento es la parte fundamental de todo sistema de cmputo. Es la encargada de ejecutar tanto los programas del usuario como el sistema operativo en s mismo. La funciones del sistema operativo respecto a la
unidad de procesamiento son:
Inicializacin Luego de ser cargado el sistema operativo debe realizar varias
tareas de inicializacin como habilitar las interrupciones de hardware y
software (excepciones y trampas), configurar el sistema de memoria virtual (paginacin, segmentacin), etc.
Atender las interrupciones y excepciones Como se ver ms adelante, la unidad
de procesamiento puede encontrar una situacin que no puede resolver
por s misma (una instruccin o direccin invlida, una divisin por cero,
etc.) ante lo cual le pasa el control al sistema operativo para que ste trate
o resuelva la situacin.
41
42
Multiplexacin En un sistema multiproceso, el sistema operativo es el encargado de administrar la unidad de procesamiento dando la ilusin a los
procesos que estn ejecutando de forma exclusiva.
2.2.1.
Jerarqua de almacenamiento
Las computadoras que siguen la arquitectura von Neumann, esto es, prcticamente la totalidad hoy en da1 podran resumir su operacin general a alimentar a una unidad de proceso (CPU) con los datos e instrucciones almacenados en memoria, que pueden incluir llamadas a servicio (y respuestas a eventos)
originados en medios externos.
Una computadora von Neumann significa bsicamente que es una computadora de programa almacenado en la memoria primaria esto es, se usa el
mismo almacenamiento para el programa que est siendo ejecutado y para sus
datos, sirvindose de un registro especial para indicar al CPU cul es la direccin en memoria de la siguiente instruccin a ejecutar.
La arquitectura von Neumann fue planteada, obviamente, sin considerar
la posterior diferencia entre la velocidad que adquirira el CPU y la memoria.
En 1977, John Backus present al recibir el premio Turing un artculo describiendo el cuello de botella de von Neumann. Los procesadores son cada vez ms
rpidos (se logr un aumento de 1000 veces tanto entre 1975 y 2000 tan slo
en el reloj del sistema), pero la memoria aument su velocidad a un ritmo mucho menor aproximadamente un factor de 50 para la tecnologa en un nivel
costo-beneficio suficiente para usarse como memoria primaria.
Una respuesta parcial a este problema es la creacin de una jerarqua de almacenamiento, yendo de una pequea rea de memoria mucho ms cara pero
extremadamente rpida y hasta un gran espacio de memoria muy econmica,
aunque mucho ms lenta, como lo ilustran la figura 2.1 y el cuadro 2.1. En particular, la relacin entre las capas superiores est administrada por hardware
especializado de modo que su existencia resulta transparente al programador.
Ahora bien, si bien la relacin entre estos medios de almacenamiento puede
parecer natural, para una computadora tiene una realidad completamente distinta: los registros son parte integral del procesador, y la memoria est a slo
un paso de distancia (el procesador puede referirse a ella directamente, de forma transparente, indicando la direccin desde un programa). El cach no existe
para efectos prcticos: el procesador no hace referencia directa a l, sino que es
manejado por los controladores de acceso a memoria. Y por ltimo, el acceso o
modificacin de cualquier dato almacenado en disco requiere en primer trmino de la transferencia a memoria, y slamente cuando sta haya finalizado, el
1 Algunos argumentarn que muchas de las computadoras en uso hoy en da siguen la arquitectura Harvard modificada, dado que empleando distintos bancos de memoria cach, un procesador
puede tanto referirse a la siguiente instruccin como iniciar una transferencia de memoria primaria. Esta distincin no tiene mayor relevancia para este tema, la referencia se incluye nicamente
por no llevar a confusin.
43
llamado a las rutinas que son presentadas en la seccin 2.4, y analizadas en los
captulos 6 y 7.
Como se ver, el sistema operativo es el encargado de mantener la informacin almacenada en todos estos tipos de memoria de forma consistente, y de
realizar las transferencias entre unas y otras.
Registros
La memoria ms rpida de la computadora son los registros, ubicados dentro de cada uno de los ncleos de cada uno de los CPU. Las arquitecturas tipo
RISC (Reduced Instruction Set Computer) slo contemplan la ejecucin de instrucciones entre registros (excepto, claro, las de carga y almacenamiento a
memoria primaria).
Los primeros CPU trabajaban con pocos registros, muchos de ellos de
propsito especfico trabajaban ms bien con una lgica de registro acumulador. Por ejemplo, el MOS 6502 (en el cual se basaron las principales computadoras de 8 bits) tena un acumulador de 8 bits (A), dos registros ndice de 8
bits (X e Y), un registro de estado del procesador de 8 bits (P), un apuntador
al stack de 8 bits (S), y un apuntador al programa de 16 bits (PC). El otro gran
44
Nivel
Nombre
Tamao
Tecnologa
Acceso (ns)
Transferencia
Gestionado por
1
Registros
<1KB
Multipuerto,
CMOS
0.25-0.5
20-100 GB/s
Compilador
2
Cache
<16MB
CMOS
SRAM
0.5-25
5-10 GB/s
Hardware
Respaldado en
Cache
Memoria
3
Memoria
<64GB
CMOS
DRAM
80-250
1-5 GB/s
Sistema
Operativo
Disco
4
Disco
>100GB
Magntica
5,000,000
20-150 MB/s
Sistema
Operativo
CD, cinta
2.2.2.
Interrupciones y excepciones
La ejecucin de los procesos podra seguir siempre linealmente, atendiendo a las instrucciones de los programas tal como fueron escritas, pero en el
modelo de uso de cmputo actual, eso no servira de mucho: para que un proceso acepte interaccin, su ejecucin debe poder responder a los eventos que
2 A veces asistido por instrucciones explticas por parte del programador, pero muchas veces
como resultado del anlisis del cdigo.
45
ocurran alrededor del sistema. Y los eventos son manejados a travs de las
interrupciones y excepciones (o trampas).
Cuando ocurre algn evento que requiera la atencin del sistema operativo, el hardware encargado de procesarlo escribe directamente a una ubicacin
predeterminada de memoria la naturaleza de la solicitud (el vector de interrupcin) y, levantando una solicitud de interrupcin, detiene el proceso que estaba
siendo ejecutado. El sistema operativo entonces ejecuta su rutina de manejo de
interrupciones (tpicamente comienza grabando el estado de los registros del
CPU y otra informacin relativa al estado del proceso desplazado) y posteriormente la atiende.
Las interrupciones pueden organizarse por prioridades, de modo que una
interrupcin de menor jerarqua no interrumpa a una ms importante dado que las interrupciones muchas veces indican que hay datos disponibles en
algn buffer, el no atenderlas a tiempo podra llevar a la prdida de datos.
Hay un nmero limitado de interrupciones definidas para cada arquitectura, mucho ms limitado que el nmero de dispositivos que tiene un equipo
de cmputo actual. Las interrupciones son, por tanto, generadas por el controlador del canal en que son producidas. Si bien esto resuelve la escasez de interrupciones, dificulta su priorizacin con canales de uso tan variado como el
USB3 , una interrupcin puede indicar que hay desde un teclazo para ser ledo
hasta un paquete de red esperando a ser procesado y si bien demorar la
3 Algunas arquitecturas, particularmente de sistemas embebidos y por un criterio altamente
econmico, estn estructuradas ntegramente alrededor de un bus USB.
46
2.3. TERMINALES
47
2.3.
Terminales
2.4.
Dispositivos de almacenamiento
El almacenamiento en memoria primaria es voltil, esto es, se pierde al interrumpirse el suministro elctrico. Esto no era muy importante en la poca
definitoria de los conceptos que se presentan en esta seccin, dado que el tiempo total de vida de un conjunto de datos en almacenamiento bajo el control
48
2.5.
Relojes y temporizadores
2.6.
49
Canales y puentes
2.6.1.
Contencin
Una de las principales razones de la existencia de tantos canales (buses) distintos en un mismo sistema es a la frecuencia acorde a los dispositivos para los
cuales est diseado: la cantidad de datos que tiene que viajar entre el procesador y la memoria a lo largo de la operacin del sistema es muy superior que
la que tiene que transferirse desde los discos, y a su vez, esta es mucho mayor
que la que enviarse a la impresora, o la que se recibe del teclado. Claro est,
los dems dispositivos podran incrementar su frecuencia para participar en
un canal ms rpido, aunque su costo se incrementara, dado que haran falta componentes capaces de sostener un reloj varios rdenes de magnitud ms
rpido.
Pero incluso obviando la diferencia econmica: cuando el sistema requiere
transferir datos de o hacia varios dispositivos de la misma categora, es fre5 Los chips que forman parte de un equipo, casi siempre provistos por el mismo fabricante que
el procesador mismo.
6 La separacin aqu descrita ha sido caracterstica de las computadoras x86 de los ltimos 20
aos, aunque la tendencia apunta a que se abandone paulatinamente para dar paso a procesadores
que integren en un slo paquete todos estos componentes. Sin embargo, el acomodo funcional
electrnico, al menos hasta el momento, sigue basado en estos puntos.
50
Figura 2.3: Diagrama de la comunicacin entre componentes de un sistema de cmputo basado en puente norte y puente sur. Imagen de la Wikipedia: Puente Norte
cuente que ocurra contencin: puede saturarse el ancho de banda mximo que
alcanza uno de los canales y, an si los dispositivos tienen informacin lista,
tendrn que esperar a que los dems dispositivos desocupen el canal.
En la figura 2.4 se puede ver el diseo general del chipset Intel 875, introducido en el 2003, incluyendo el ancho de banda de cada uno de los canales del
sistema. Hay que recordar que hay canales como el USB que permiten la conexin de mltiples dispositivos, los cuales debern compartir el ancho de banda
total permitido por el canal: en la figura se presentan dos discos duros sobre el
canal SATA y dos unidades pticas en el ATA paralelo; el canal USB permite el
uso de un mximo de 127 unidades por canal, por lo cual la contencin puede
ser muy alta.
51
Figura 2.4: Esquema simplificado del chipset Intel 875 (para el procesador Pentium
4) ilustrando la velocidad de cada uno de los canales
2.6.2.
La operacin de dispositivos de entrada/salida puede ser altamente ineficiente. Cuando un proceso est en una seccin limitada por entrada-salida (esto es, donde la actividad principal es la transferencia de informacin entre la
memoria principal y cualquier otra rea del sistema), si el procesador tiene que
encargarse de la transferencia de toda la informacin7 , se creara un cuello de
botella por la cantidad y frecuencia de interrupciones. Hoy en da, para evitar
que el sistema se demore cada vez que hay una transferencia grande de datos,
todas las computadoras implementan controladores de acceso directo a memoria
(DMA) en uno o ms de sus subsistemas.
El DMA se emplea principalmente al tratar con dispositivos con un gran
ancho de banda, como unidades de disco, subsistemas multimedia, tarjetas de
red, e incluso para transferir informacin entre niveles del cach.
Las transferencias DMA se hacen en bloques preestablecidos; en vez de que
el procesador reciba una interrupcin cada vez que hay una palabra lista para
ser almacenada en la memoria, el procesador indica al controlador DMA la direccin fsica base de memoria en la cual operar, la cantidad de datos a transferir, el sentido en que se efectuar la operacin (del dispositivo a memoria o de
memoria al dispositivo), y el puerto del dispositivo en cuestin; el controlador
DMA efectuar la transferencia solicitada, y slo una vez terminada sta (o
en caso de encontrar algn error en el proceso) lanzar una interrupcin al sistema; el procesador queda libre para realizar otras tareas, sin ms limitante que
la posible contencin que tendr que enfrentar en el bus de acceso a la memoria.
7 Este
52
Coherencia de cache
Cuando se realiza una transferencia DMA de un dispositivo a la memoria,
puede haber pginas de la memoria en cuestin que estn en alguno de los niveles de la memoria cach; dado que el cach est uno o ms niveles por encima
de la memoria principal, es posible que la informacin haya ya cambiado pero
el cach retenga la informacin anterior.
Los sistemas de cach coherente implementan mecanismos en hardware que
notifican a los controladores de cach que las pginas que alojan estn sucias
y deben ser vueltas a cargar para ser empleadas, los sistemas no coherentes
requieren que el subsistema de memoria del sistema operativo haga esta operacin.
Los procesadores actuales implementan normalmente varios niveles de
cach, estando algunos dentro del mismo CPU, por lo que tpicamente se encuentran sistemas hbridos, en los que los cachs de nivel superiores son coherentes, pero los de nivel 1 no, y las inconsistencias que ste podra producir
deben ser esperadas y resueltas por el software.8
2.7.
53
Comunicaciones Establecer una comunicacin con determinado proceso (local o remoto), aceptar una solicitud de comunicacin de otro proceso,
intercambiar informacin sobre un canal establecido.
Proteccin Consultar o modificar la informacin relativa al acceso de objetos
en el disco, otros procesos, o la misma sesin de usuario.
Cada sistema operativo expone una serie de llamadas al sistema. Estas son,
a su vez, expuestas al programador a travs de las interfaces de aplicacin al
programador (API), que se alnean de forma cercana (pero no exacta). Del mismo
modo que cada sistema operativo ofrece un conjunto de llamadas al sistema
distinto, cada implementacin de un lenguaje de programacin puede ofrecer
un API ligeramente distinto de otros.
Figura 2.5: Transicin del flujo entre espacio usuario y espacio ncleo en una llamada al sistema
2.7.1.
54
14
15
16
17
18
19
$ strace pwd
execve("/bin/pwd", ["pwd"], [/* 43 vars */]) = 0
brk(0)
= 0x8414000
access("/etc/ld.so.nohwcap", F_OK)
= -1 ENOENT (No such
file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb773d000
access("/etc/ld.so.preload", R_OK)
= -1 ENOENT (No such
file or directory)
open("/etc/ld.so.cache", O_RDONLY)
= 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=78233, ...}) = 0
mmap2(NULL, 78233, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7729000
close(3)
= 0
access("/etc/ld.so.nohwcap", F_OK)
= -1 ENOENT (No such
file or directory)
open("/lib/i386-linux-gnu/libc.so.6", O_RDONLY) = 3
read(3,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0po\1\0004\0\0\0"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1351816, ...}) = 0
mmap2(NULL, 1366328, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb75db000
mprotect(0xb7722000, 4096, PROT_NONE)
= 0
mmap2(0xb7723000, 12288, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x147) = 0xb7723000
mmap2(0xb7726000, 10552, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7726000
close(3)
= 0
9 Se denomina portar el hacer las adecuaciones necesarias para que una herramienta diseada
para determinado entorno pueda emplearse en otros distintos.
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
55
2.8.
Si bien el sistema operativo tiene por misin abstraer y ocultar los detalles
de los dispositivos, tambin debe exponer una interfaz para poder emplearlos
y administrarlos.
Unix introdujo el concepto de que todo es un archivo: en el sistema Unix original, todos los dispositivos podan ser controlados a travs de un archivo especial
que, en vez de almacenar informacin, apunta a estructuras en el sistema que
controlan a cada dispositivo. Este concepto sobrevive en los sistemas derivados
de Unix al da de hoy, aunque varias clases de dispositivo rompen esta lgica.
El sistema operativo Plan9 de Bell Labs mantiene y ampla este concepto e introduce los espacios de nombres mutables, que presenta con interfaz de archivo
prcticamente cualquier objeto empleado por el sistema.
Las principales estructuras relacionadas de este tipo10 que existen en un
10 Hay varios otros tipos de archivo definidos en su semntica, como las tuberas nombradas, los
sockets, e incluso los mismos directorios. Estos sern cubiertos en la seccin 6.2.6.
56
2.9.
2.9.1.
Multiprocesamiento
57
Figura 2.6: Esquema de la ejecucin de tres procesos en un sistema secuencial, multiprogramado, multiprocesado, e hbrido
En la figura 2.6, el primer diagrama ilustra una ejecucin estrictamente secuencial: cada uno de los procesos que demandan atencin del sistema es ejecutado hasta que termina; el segundo muestra cmo se comportara un sistema
multiprogramado, alternando entre los tres procesos, de modo que el usuario
vea que los tres avanzan de forma simultnea; el tercero corresponde a un sistema de multitarea pura: cada proceso es ejecutado por un procesador distinto,
y avanzan en su ejecucin de forma simultnea. El cuarto caso, un esquema
hbrido, presenta cmo reaccionara un equipo con capacidad de atender a dos
procesos al mismo tiempo, pero con tres procesos solicitando ser atendidos.
Este ltimo esquema es el que ms comunmente se encuentra en equipos de
uso general hoy en da.
Probablemente el tema que se aborda ms recurrentemente a lo largo de
este texto ser precisamente la complejidad que proviene de la multiprogramacin; se la desarrollar particularmente en los captulos 3 y 4. Valga la nota
en este momento nicamente para aclarar la diferencia entre los dos conceptos.
El multiprocesamiento se emplea ampliamente desde los sesenta en los en11 O poco ms que eso, al grado de que rara vez se emplea el trmino multiprogramacin, mucho
ms acorde a los equipos que se emplean da a da.
58
tornos de cmputo de alto rendimiento, pero por muchos aos se vio como
el rea de especializacin de muy pocos las computadoras con ms de un
procesador eran prohibitivamente caras, y para muchos sistemas, ignorar el
problema resultaba una opcin vlida. Muchos sistemas operativos ni siquiera
detectaban la existencia de procesadores adicionales, y en presencia de stos,
ejecutaban en uno slo.
Figura 2.7: La Ley de Moore, en su artculo publicado en 1965, prediciendo la miniaturizacin por diez aos
59
60
2.9.2.
Cmputo distribudo
61
Infraestructura como servicio El proveedor ofrece computadoras completas (en hardware real o mquinas virtuales); la principal ventaja
de esta modalidad es que los usuarios, si bien retienen la capacidad plena de administracin sobre sus granjas, tienen mucho mayor
flexibilidad para aumentar o reducir el consumo de recursos (y por
tanto, el pago) segn la demanda que alcancen.
El tema del cmputo en la nube va muy de la mano de la virtualizacin,
que se abordar en el apndice B.
2.9.3.
t s + t p (1)
T (1)
=
t (1)
T ( P)
t s + pP
Esta observacin, conocida como la Ley de Amdahl, llev a que por varias
dcadas el cmputo paralelo fuera relegado al cmputo de propsito especfico, para necesidades muy focalizadas en soluciones altamente paralelizables,
como el cmputo cientfico.
En trminos del ejemplo presentado en la figura 2.9, se ve un programa que,
ejecutado secuencialmente, resulta en T = 500. Este programa est dividido en
tres secciones secuenciales, de t = 100 cada una, y dos secciones paralelizables,
12 Validity of the Single Processor Approach to Achieving Large Scale Computing Capabilities,
Amdahl, 1967
62
(a) Procesadores: 1,
t = 500
(b) Procesadores: 2, t =
400, ganancia: 1.25x
Figura 2.9: Ley de Amdahl: ejecucin de un programa con 500 unidades de tiempo
total de trabajo con uno, dos y cuatro procesadores.
totalizando t = 100 cada una, como se puede ver al representar una ejecucin
estrictamente secuencial (2.9(a)).
Al agregar un procesador adicional (2.9(b)), se obtiene una ganancia de
1.25x la ejecucin se completa en T = 400 (con g = 1,25). Las secciones
paralelizables slo toman un tiempo externo de 50 cada una, dado que la carga
fue repartida entre dos unidades de ejecucin. Al ejecutar con cuatro procesadores (2.9(c)), si bien se sigue notando mejora, esta apenas lleva a T = 350,
con g = 1,4.
Si el cdigo fuera infinitamente paralelizable, y se ejecutase este programa
en una computadora con un nmero infinito de procesadores, este programa
no podra ejecutarse en menos de T = 300, lo cual presentara una ganancia de
apenas g = 1,66. Esto es, al agregar procesadores adicionales, rpidamente se
llegara a un crecimiento asinttico el comportamiento descrito por la Ley de
Amdahl es frecuentemente visto como una demostracin de que el desarrollo
de sistemas masivamente paralelos presenta rendimientos decrecientes.
Si bien el ejemplo que se acaba de presentar resulta poco optimizado, con
slo un 40 % de cdigo paralelizable, se puede ver en la grfica 2.10 que el
panorama no cambia tan fuertemente con cargas tpicas. Un programa relativamente bien optimizado, con 80 % de ejecucin paralela, presenta un crecimiento atractivo en la regin de hasta 20 procesadores, y se estaciona apenas arriba
de una ganancia de 4.5 a partir de los 40.13 Incluso el hipottico 95 % llega a un
13 De
63
15 Reevaluating
de 1988
64
2.10.
Ejercicios
2.10.1.
Preguntas de autoevaluacin
2.10. EJERCICIOS
65
2.10.2.
66
2.10.3.
Lecturas relacionadas
Can programming be liberated from the von Neumann style?: a functional style
and its algebra of programs
https://dl.acm.org/citation.cfm?doid=359576.359579
(Intel, 2003)
Captulo 3
Administracin de procesos
3.1.
3.1.1.
Estados de un proceso
Un proceso, a lo largo de su vida, alterna entre diferentes estados de ejecucin. Estos son:
67
68
3.1.2.
69
3.2.
Procesos e hilos
70
Pero visto desde la perspectiva del proceso hay una gran diferencia: si bien
el sistema operativo se encarga de que cada proceso tenga una visin de virtual
exclusividad sobre la computadora, todos los hilos de un proceso comparten
un slo espacio de direccionamiento en memoria y los archivos y dispositivos
abiertos. Cada uno de los hilos se ejecuta de forma (aparentemente) secuencial y maneja su propio contador de programa y pila (y algunas estructuras
adicionales, aunque mucho ms ligeras que el PCB).
3.2.1.
3.2.2.
Hay tres patrones en los que caen generalmente los modelos de hilos; se
puede emplear ms de uno de estos patrones en diferentes reas de cada apli-
71
cacin, e incluso se pueden anidar (esto es, se podra tener una lnea de ensamblado dentro de la cual uno de los pasos sea un equipo de trabajo):
Jefe / trabajador Un hilo tiene una tarea distinta de todos los dems: el hilo
jefe genera o recopila tareas para realizar, las separa y se las entrega a los
hilos trabajadores.
Este modelo es el ms comn para procesos que implementan servidores
(es el modelo clsico del servidor Web Apache) y para aplicaciones grficas (GUIs), en que hay una porcin del programa (el hilo jefe) esperando
a que ocurran eventos externos. El jefe realiza poco trabajo, se limita a invocar a los trabajadores para que hagan el trabajo de verdad; como mucho,
puede llevar contabilidad de los trabajos realizados.
Tpicamente, los hilos trabajadores realizan su operacin, posiblemente
notifican al jefe de su trabajo, y finalizan su ejecucin.
72
Lnea de ensamblado si una tarea larga puede dividirse en pasos sobre bloques de la informacin total a procesar, cada hilo puede enfocarse a hacer
slo un paso y pasarle los datos a otro hilo conforme vaya terminando.
Una de las principales ventajas de este modelo es que ayuda a mantener
rutinas simples de comprender, y permite que el procesamiento de datos
contine incluso si parte del programa est bloqueado esperando E/S.
Un punto importante a tener en cuenta en una lnea de ensamblado es
que, si bien los hilos trabajan de forma secuencial, pueden estar ejecutndose paralelamente sobre bloques consecutivos de informacin, eventos,
etc.
Este patrn es claramente distinto de los dos anteriormente presentados;
si bien en los anteriores los diferentes hilos (a excepcin del hilo jefe) eran casi siempre idnticos -aunque operando sobre distintos conjuntos de
datos-, en este caso son todos completamente distintos.
3.3. CONCURRENCIA
3.3.
Concurrencia
3.3.1.
Introduccin
73
74
3.3.2.
int cuenta;
proceso torniquete1() {
int i;
for(i=0;i<20;i++) {
cuenta = cuenta + 1;
}
}
proceso torniquete2() {
int i;
for(i=0;i<20;i++) {
cuenta = cuenta + 1;
}
}
main() {
cuenta = 0;
/* Lanzar ambos procesos concurrentemente*/
concurrentemente { //
torniquete1();
3 Se utiliza una versin ficticia del lenguaje C para el ejemplo, evitando entrar en los detalles de
sintxis de un lenguaje concurrente.
3.3. CONCURRENCIA
22
23
24
25
26
27
28
75
torniquete2();
}
/* Esperar a que ambos finalicen */
esperar(torniquete1);
esperar(torniquete2);
printf("Cuenta: %d\n", cuenta);
}
76
Se puede ver que ambos procesos realizaron sus instrucciones para incrementar el contador en 1 y el resultado final fue que la cuenta se increment en
dos unidades.
Pero, tambin puede darse la siguiente secuencia de eventos durante la ejecucin de estas instrucciones:
1. cuenta = 0
2. torniquete1: LEER (resultado: rax de p1 = 0, cuenta = 0)
3. torniquete1: INC (resultado: rax de p1 = 1, cuenta = 0)
4. El sistema operativo decide cambiar de tarea, suspende torniquete1 y
contina con torniquete2.
5. torniquete2: LEER (resultado: rax de p2 = 1, cuenta = 1)
6. torniquete2: INC (resultado: rax de p2 = 2, cuenta = 1)
7. torniquete2: GUARDAR (resultado: rax de p2 = 2, cuenta = 2)
8. El sistema operativo decide cambiar de tarea, suspende torniquete2 y
continua con torniquete1.
9. torniquete1: GUARDAR (resultado: rax de p1 = 1, cuenta = 1)
Nuevamente ambos procesos ejecutaron sus instrucciones para incrementar
en 1 el contador. Sin embargo, en este caso cuenta tiene el valor 1!. A este
problema tambin se lo conoce como problema de las actualizaciones mltiples.
Esto parece muy especfico Si bien este anlisis parece muy especfico es fcil ver que la misma circustancia podra darse en un sistema de reserva
de vuelos (p. ej.: puede que dos operadores vean un asiento vaco en su
copia local de los asientos y ambos marquen el mismo asiento como ocupado) o con dos procesos que decidan cambiar simultneamente datos en
un archivo. Aqu las operaciones ya no son necesariamente operaciones
internas de la mquina.
3.3. CONCURRENCIA
77
Pero no es muy poco probable? Por otro lado, uno podra pensar (con cierta cuota de razn) que la secuencia de eventos propuesta es muy poco
probable: usualmente un sistema operativo ejecuta miles de instrucciones
antes de cambiar de un proceso a otro. De hecho, en la prctica este problema es muy frecuentemente ignorado y los programas funcionan muy
bien la mayora de las veces. Esto permite ver una caracterstica importante de los programas concurrentes: es muy usual que un programa funcione perfectamente la mayor parte del tiempo, pero de vez en cuando
puede fallar. Subsecuentes ejecuciones con los mismos argumentos producen nuevamente el resultado correcto. Esto hace que los problemas de
concurrencia sean muy difciles de detectar y ms aun de corregir. Es importante (y mucho ms efectivo) realizar un buen diseo inicial de un
programa concurrente en lugar de intentar arreglarlo cuando se detecta
alguna falla. Tambin es interesante notar que dependiendo del sistema,
puede ser que alguna de las instrucciones sea muy lenta, en el caso de un
sistema de reserva de asientos de aviones, las operaciones pueden durar
un tiempo importante (p. ej.: desde que el operador muestra los asientos disponibles hasta que el cliente elige el asiento) haciendo mucho ms
probable que ocurra una secuencia no deseada.
Vale la pena preocuparse? A modo de ilustracin de la gravedad del problema, estos son algunos valores para el resultado final de la variable
cuenta cuando se ejecuta el programa anterior en Pascal-FC4 : 25 29 31
20 21 26 27 18 31 35. Notes que incluso uno de los valores es menor que
20 (que es lo mnimo que cuenta cada torniquete). Es un ejercicio interesante pensar qu secuencia de eventos podra producir tal valor y cul es
el mnimo valor posible.
Pero tenemos muchos ncleos Otra cuestin que puede parecer artificiosa es
que en el ejemplo hay un solo procesador o ncleo. Sin embargo, tener ms de un procesador no slo no soluciona el problema sino que lo
empeora: ahora las operaciones de lectura o escritura pueden ejecutarse
directamente en paralelo y aparecen nuevos problemas de coherencia de
cach. En la siguiente discusin muchas veces se presupone que hay un
solo procesador, sin que eso invalide la discusin para equipos multiprocesadores.
Algunos conceptos de concurrencia
Antes de abordar posibles soluciones al problema presentado, se presentan
las definiciones de algunos conceptos importantes.
Operacin atmica Operacin que requiere la garanta de que se ejecutar como una sla unidad de ejecucin, o fallar completamente, sin resultados
4 http://www-users.cs.york.ac.uk/burns/pf.html
78
Condicin de carrera (En ingls, Race condition) Categora de errores de programacin que involucra a dos procesos que fallan al comunicarse su
estado mutuo, llevando a resultados inconsistentes. Es uno de los problemas ms frecuentes y difciles de depurar, y ocurre tpicamente por no
considerar la no atomicidad de una operacin
Seccin (o regin) crtica El rea de cdigo que requiere ser protegida de accesos simultneos, donde se realiza la modificiacin de datos compartidos.
Recurso compartido Un recurso que puede ser accedido desde ms de un
proceso. En muchos escenarios esto es un variable en memoria (como
cuenta en el jardn ornamental), pero podran ser archivos, perifricos,
etc. . .
Dado que el sistema no tiene forma de saber cules instrucciones (o reas
del cdigo) deben funcionar de forma atmica, el programador debe asegurar
la atomicidad de forma explcita, mediante la sincronizacin de los procesos.
El sistema no debe permitir la ejecucin de parte de esa rea en dos procesos
de forma simultnea (slo puede haber un proceso en la seccin crtica en un
momento dado).
Y qu tiene que ver esto con el problema del Jardn Ornamental?
En el problema hay claramente un recurso compartido que es la cuenta,
as la seccin que modifica la cuenta es una seccin crtica y la operacin
cuenta = cuenta + 1 debe ser una operacin atmica. La secuencia
de eventos que se mostr es una condicin de carrera: el segundo torniquete presume un estado (cuenta = 0) que no es el mismo que conoce
el torniquete1 (cuenta = 1).
Soluciones posibles (y no tanto)
El planteamiento del problema del jardn ornamental busca llevar al lector
a ir encontrando, a travs de sucesivos refinamientos, los mecanismos principales que se emplean para resolver en general los problemas que implican el
acceso concurrente a una seccin crtica. Se presentan a continuacin, pues, los
sucesivos intentos.
Intento 1: No utilizar multitarea En este sencillo ejemplo una posible solucin es utilizar una sola entrada (o torniquete). Esto podra ser una solucin en tanto que no haya mucha gente que haga cola para entrar. Sin
embargo, en un sistema anlogo de reserva de pasajes aereos no parece
3.3. CONCURRENCIA
79
tener mucho sentido que todos los pasajeros deban ir a Japn a sacar su
pasaje. Por otro lado, ya deberan ser claras las ventajas de la multitarea
y el poseer distintos ncleos.
Intento 2: Suspender la multitarea durante la seccin crtica Una versin ms
relajada de la alternativa anterior es suspender la multitarea durante la
ejecucin de la seccin crtica. As, un torniquete deber hacer:
1
2
3
Torniquete1 */
... */
(bandera) wait;
Aqu bandera=0 */
80
9
10
11
if (bandera) wait;
bandera = 1
Intento 4: Manejar la bandera con instrucciones atmicas Algunas arquitecturas de computadoras permiten realizar determinadas operaciones sencillas (como actualizar una bandera) de forma atmica (p. ej.: VAX tiene
la instruccin test_and_set y el i386 tiene la instruccin INC.
Usando esto, la solucin es:
1
2
3
4
5
6
7
8
9
3.3. CONCURRENCIA
1
2
3
81
while (++bandera!=1) {
bandera--;
}
De hecho, si el sistema operativo decide darle alta prioridad a este proceso es posible que est un tiempo infinito en este ciclo, impidiendo que
otro proceso decremente la bandera. Y an cuando el sistema operativo
decida cambiar de proceso en el siguiente tic de reloj, es evidente que se
podra aprovechar el procesador para hacer algo til durante ese tiempo
y que suspender el proceso de otra manera le da ms posibilidad a otros
procesos para que cambien la bandera. A esto se lo conoce como espera
activa o espera ocupada (busy waiting en ingls) y es una situacin que se
desea evitar.
El otro problema tiene que ver con el hardware: determinadas arquitecturas no permiten instrucciones que lean y actualicen en una nica operacin una direccin de memoria (se requiere una operacin para leer
y otra para escribir). En particular, ninguna arquitectura RISC lo permite
(p. ej.: SPARC, RS 6000, . . . ).
Intento 5: Utilizar turnos Una alternativa para evitar el problema de la actualizacin mltiple a una bandera es utilizar turnos
1
while (turno != 1) {
esperar(); /* Otro proceso? */
}
/* Seccin crtica */
cuenta = cuenta + 1;
turno = 2;
while (turno != 2) {
esperar();
}
/* Seccin crtica */
cuenta = cuenta + 1;
turno = 1;
Esto garantiza que no hay dos procesos en seccin crtica. Pero ntese
que hacer esto equivale a tener un solo torniquete: slo podr haber una
82
Intento 6: Indicar la intencin de entrar a la seccin crtica Para paliar los efectos de la solucin anterior se puede intentar indicar si el otro proceso
tambin est queriendo entrar en la seccin crtica. El cdigo sera:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Proceso 1: */
... */
= 1;
(b2) {
esperar();
}
/* Seccin crtica */
cuenta = cuenta + 1;
b1 = 0;
/* ... */
/* Proceso 2: */
/* ... */
b2 = 1;
if (b1) {
esperar();
}
/* Seccin crtica */
cuenta = cuenta + 1;
b2 = 0;
/* ... */
3.3. CONCURRENCIA
83
La solucin est basada en una combinacin de los intentos anteriores: utilizar banderas para indicar qu proceso puede entrar, pero adems usa un
turno para desempatar en caso de que ambos procesos busquen entrar a la vez.
En cierto modo es un algoritmo amable: si un proceso detecta que el otro proceso fue el primero en actualizar el turno, entonces lo deja pasar:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
84
Solucin para ms procesos El algoritmo de Peterson sirve nicamente cuando hay dos procesos que compiten para acceder a una regin crtica. Qu
se puede hacer si hay ms de dos entradas al jardn, o si hay ms de
dos puntos de venta de pasajes aereos? La solucin a este problema ms
general fue propuesta por Dijkstra en 1968 y posteriormente Eisenberg y
McGuire en 1972 y Lamport en 1974 presentaron distintas soluciones.
La ms ampliamente utilizada y sencilla de entender es la propuesta por
Lamport, tambin conocida como el algoritmo de la panadera por su semejanza con el sistema de turnos utilizado para atender a los clientes en una
panadera.
Solucin para equipos multiprocesadores Esta solucin (y tambin la de Lamport y todos los autores mencionadas hasta ahora) falla en equipos multiprocesadores, pues aparecen problemas de coherencia de cach. Se necesitan precauciones especiales en equipos con ms de un procesador.
3.3.3.
Mecanismos de sincronizacin
3.3. CONCURRENCIA
85
Figura 3.5: Sincronizacin: la exclusin de las secciones crticas entre varios procesos
se protegen por medio de regiones de exclusin mutua. La figura ilustra a varios
procesos que requieren de una misma seccin crtica; las flechas punteadas representan el tiempo que un proceso est a la espera de que otro libere el paso para
dicha seccin, y las punteadas verticales indican la transferencia del candado.
Como se vio en el ejemplo anterior, para que un mutex sea efectivo tiene que
ser implementado a travs de una primitiva a un nivel inferior5 , implicando al
planificador.
El problema de la actualizacin mltiple que surge en el caso de la venta de
pasajes aereos podra reescribirse de la siguiente manera empleando un mutex:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
86
asigna_asiento() {
lockfile /tmp/asigna_asiento.lock
PROX=$(cat /tmp/proximo_asiento || echo 0)
CAP=$(cat /etc/capacidad || echo 40)
if [ $PROX -lt $CAP ]
then
ASIG=$PROX
echo $(($PROX+1)) > /tmp/proximo_asiento
echo "Asiento asignado: $ASIG"
else
echo "No hay asientos disponibles"
return 1;
fi
rm -f /tmp/asigna_asiento.lock
}
3.3. CONCURRENCIA
87
Un mutex es, pues, una herramienta muy sencilla, y podra verse como la
pieza bsica para la sincronizacin entre procesos. Lo fundamental para emplearlos es identificar las regiones crticas del cdigo, y proteger el acceso con
un mecanismo apto de sincronizacin, que garantice atomicidad.
Semforos
La interfaz ofrecida por los mutexes es muy sencilla, pero no permite resolver algunos problemas de sincronizacin. Edsger Dijkstra, en 1968, propuso
los semforos.6
Un semforo es una variable de tipo entero que tiene definida la siguiente
interfaz:
Inicializacin Se puede inicializar el semforo a cualquier valor entero, pero
despus de esto, su valor no puede ya ser ledo. Un semforo es una
estructura abstracta, y su valor es tomado como opaco (invisible) al programador.
Decrementar Cuando un hilo decrementa el semforo, si el valor es negativo,
el hilo se bloquea y no puede continuar hasta que otro hilo incremente el
semforo. Segn la implementacin, esta operacin puede denominarse
wait, down, acquire o incluso P (por ser la inicial de proberen te verlagen,
intentar decrementar en holands, del planteamiento original en el artculo
de Dijkstra).
Incrementar Cuando un hilo incrementa el semforo, si hay hilos esperando,
uno de ellos es despertado. Los nombres que recibe esta operacin son
signal, up, release, post o V (de verhogen, incrementar).
La interfaz de hilos POSIX (pthreads) presenta esas primitivas con la
siguiente definicin:
1
2
3
4
int
int
int
int
La variable pshared indica si el semforo puede ser compartido entre procesos o nicamente entre hilos. sem_trywait extiende la intefaz sugerida por
Dijkstra: verifica si el semforo puede ser decrementado y, en caso de que no,
en vez de bloquearse, indica al proceso que no puede continuar. El proceso
debe tener la lgica necesaria para no entrar en las secciones crticas (p. ej.,
intentar otra estrategia) en ese caso.
6 El smil presentado por Dijkstra no es del semforo vial, con una luz roja y una luz verde (dicho
esquema se asemeja al del mutex). La referencia es a la del semforo de tren, que permite el paso
estando arriba, e indica espera estando abajo.
88
No importa si prepara_conexion() termina primero en el momento en que termine, senal valdr 1 y envia_datos() podr proceder.
Rendezvous As se denomina en francs (y ha sido adoptado al ingls) a
quedar en una cita. Este patrn busca que dos hilos se esperen mutuamente en cierto punto para continuar en conjunto por ejemplo, en una
aplicacin GUI, un hilo prepara la interfaz grfica y actualiza sus eventos
mientras otro efecta clculos para mostrar. Se desea presentar al usuario
la simulacin desde el principio, as que no debe empezar a calcular antes
de que el GUI est listo, pero preparar los datos del clculo toma tiempo, y no se quiere esperar doblemente. Para esto, se implementan dos
semforos sealizndose mutuamente:
1
2
3
4
5
6
7
8
9
10
11
12
guiListo = Semaphore(0)
calculoListo = Semaphore(0)
threading.Thread(target=maneja_gui, args=[]).start()
threading.Thread(target=maneja_calculo, args=[]).start()
def maneja_gui():
inicializa_gui()
guiListo.release()
calculoListo.acquire()
recibe_eventos()
3.3. CONCURRENCIA
13
14
15
16
17
89
def maneja_calculo():
inicializa_datos()
calculoListo.release()
guiListo.acquire()
procesa_calculo()
mutex = Semaphore(1)
# ...Inicializar estado y lanzar hilos
mutex.acquire()
# Aqu se est en la region de exclusin mutua
x = x + 1
mutex.release()
# Contina la ejecucion paralela
torniquete = Semaphore(0)
# (...)
if alguna_condicion():
torniquete.release()
# (...)
torniquete.acquire()
torniquete.release()
En este caso, se ve primero una sealizacin que hace que todos los
procesos esperen frente al torniquete hasta que alguno marque que
alguna_condicion() se ha cumplido y libere el paso. Posteriormente,
los procesos que esperan pasarn ordenadamente por el torniquete.
El torniquete por s slo no es tan til, pero su funcin se har clara a
continuacin.
90
Apagador Cuando se tiene una situacin de exclusin categrica (basada en categoras y no en procesos individuales varios procesos de la misma categora pueden entrar a la seccin crtica, pero procesos de dos categoras
distintas deben tenerlo prohibido), un apagador permite evitar la inanicin de una de las categoras ante un flujo constante de procesos de la
otra.
El apagador usa, como uno de sus componentes, a un torniquete. Para
ver una implementacin ejemplo de un apagador, referirse a la solucin
presentado a continuacin para el problema de los lectores y los escritores
(seccin 3.3.6).
Barrera Una barrera es una generalizacin de rendezvous que permite la sincronizacin entre varios hilos (no slo dos), y no requiere que el rol de
cada uno de los hilos sea distinto.
Esta construccin busca que ninguno de los hilos contine ejecutando
hasta que todos hayan llegado a un punto dado.
Para implementar una barrera, es necesario que sta guarde algo de informacin adicional adems del semforo, particularmente, el nmero de
hilos que se han lanzado (para esperarlos a todos). Esta ser una variable
compartida y, por tanto, requiere de un mutex. La inicializacin (que se
ejecuta antes de iniciar los hilos) ser:
1
2
3
4
5
require random
n = random.randint(1,10) # Nmero de hilos
cuenta = 0
mutex = Semaphore(1)
barrera = Semaphore(0)
Ahora, suponiendo que todos los hilos tienen que realizar, por separado, la inicializacin de su estado, y ninguno de ellos debe comenzar el
procesamiento hasta que todos hayan efectuado su inicializacin:
1
2
3
4
5
6
7
8
9
10
11
12
13
inicializa_estado()
mutex.acquire()
cuenta = cuenta + 1
mutex.release()
if cuenta == n:
barrera.release()
barrera.acquire()
barrera.release()
procesamiento()
3.3. CONCURRENCIA
91
Las barreras son una construccin suficientemente til como para que sea
comn encontrarlas prefabricadas. En los hilos POSIX (pthreads),
por ejemplo, la interfaz bsica es:
1
2
3
4
5
Cola Se emplea una cola cuando se tienen dos clases de hilos que deben proceder en pares. Este patrn es a veces referido como baile de saln: para
que una pareja baile, hace falta que haya un lder y un seguidor. Cuando
llega una persona al saln, verifica si hay uno de la otra clase esperando
bailar. En caso de haberlo, bailan, y en caso contrario, espera a que llegue
su contraparte.
El cdigo para implementar esto es muy simple:
1
2
3
4
5
6
7
8
9
10
11
colaLideres = Semaphore(0)
colaSeguidores = Semaphore(0)
# (...)
def lider():
colaSeguidores.release()
colaLideres.acquire()
baila()
def seguidor():
colaLideres.release()
colaSeguidores.acquire()
baila()
El patrn debe resultar ya familiar: es un rendezvous. La distincin es meramente semntica: en el rendezvous se necesitan dos hilos explcitamente,
aqu se habla de dos clases de hilos.
Sobre este patrn base se pueden refinar muchos comportamientos. Por
ejemplo, asegurar que slo una pareja est bailando al mismo tiempo,
o asegurar que los hilos en espera vayan bailando en el orden en que
llegaron.
Variables de condicin
Las variables de condicin presentan una extensin sobre el comportamiento de los mutexes, buscando darles la inteligencia de responder ante determinados eventos. Una variable de condicin siempre opera en conjunto con un
92
mutex, y en algunas implementaciones es necesario indicar cul ser dicho mutex desde la misma inicializacin del objeto.7
Una variable de condicin presenta las siguientes operaciones:
Espera Se le indica una condicin y un mutex. El mutex tiene que haber sido ya
adquirido. Esta operacin libera al mutex, y se bloquea hasta recibir una
notificacin de otro hilo o proceso. Una vez que la notificacin es recibida,
y antes de devolver la ejecucin al hilo, re-adquiere el mutex.
Espera medida Tiene una semntica igual a la de la espera, pero recibe un argumento adicional, indicando el tiempo de expiracin. Si pasado el tiempo de expiracin no ha sido notificado, despierta al hilo regresndole un
error (y sin re-adquirir el mutex).
Sealiza Requiere que el mutex ya haya sido adquirido. Despierta (sealiza) a
uno o ms hilos (algunas implementaciones permiten indicar como argumento a cuntos hilos) de los que estn bloqueados en la espera asociada.
No libera el mutex esto significa que el flujo de ejecucin se mantiene en
el invocante, quien tiene que salir de su seccin crtica (entregar el mutex)
antes de que otro de los hilos contine ejecutando.
Sealiza a todos Indica a todos los hilos que estn esperando a esta condicin.
La interfaz de hilos POSIX (pthreads) presenta la siguiente definicin:
1
2
3
4
5
6
7
3.3.4.
Problema productor-consumidor
Planteamiento
En un entorno multihilos es comn que haya una divisin de tareas tipo
lnea de ensamblado, que se puede generalizar a que un grupo de hilos van produciendo ciertas estructuras, a ser consumidas por otro grupo.
7 Mientras que otras implementaciones permiten que se declaren por separado, pero siempre
que se invoca a una variable de condicin, debe indicrsele qu mutex estar empleando.
3.3. CONCURRENCIA
93
import threading
buffer = []
threading.Thread(target=productor,args=[]).start()
threading.Thread(target=consumidor,args=[]).start()
def productor():
while True:
event = genera_evento()
buffer.append(event)
def consumidor():
while True:
event = buffer.pop()
procesa(event)
Pero el acceso a buffer no est protegido para garantizar la exclusin mutua, y podra quedar en un estado inconsistente si append() y pop() intentan
manipular sus estructuras al mismo tiempo. Adems, si bien en este ejemplo
se asumi que hay un slo hilo productor y un slo hilo consumidor, se puede
extender el programa para que haya varios hilos en cualquiera de estos roles.
En este caso, la variable event no requiere de proteccin, dado que es local
a cada hilo.
Solucin
Para resolver este problema se usarn dos semforos: mutex, que protege el
acceso a la seccin crtica, y elementos. El valor almacenado en elementos
indica, cuando es positivo, cuntos eventos pendientes hay por procesar, y
cuando es negativo, cuntos consumidores estn listos y esperando un evento.
Una solucin a este problema puede ser:
94
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
import threading
mutex = threading.Semaphore(1)
elementos = threading.Semaphore(0)
buffer = []
threading.Thread(target=productor, args=[]).start()
threading.Thread(target=consumidor, args=[]).start()
def productor():
while True:
event = genera_evento()
mutex.acquire()
buffer.append(event)
mutex.release()
elementos.release()
def consumidor():
while True:
elementos.acquire()
mutex.acquire()
event = buffer.pop()
mutex.release()
event.process()
Se puede ver que la misma construccin, un semforo, es utilizada de forma muy distinta por mutex y elementos. mutex implementa una exclusin
mutua clsica, delimitando tanto como es posible (a una sla lnea en este caso) al rea crtica, y siempre apareando un acquire() con un release().
elementos, en cambio, es empleado como un verdadero semforo: como
una estructura para la sincronizacin. Slo los hilos productores incrementan
(sueltan) el semforo, y slo los consumidores lo decrementan (adquieren). Esto es, ambos semforos comunican al planificador cundo es posible despertar a
algn consumidor.
Si se supone que genera_evento() es eficiente y no utiliza espera activa,
esta implementacin es ptima: deja en manos del planificador toda la espera
necesaria, y no desperdicia recursos de cmputo esperando a que el siguiente
elemento est listo.
Como nota al pie, la semntica del mdulo threading de Python incluye
la declaracin de contexto with. Todo objeto de threading que implemente
acquire() y release() puede ser envuelto en un bloque with, aumentando la legibilidad y con exactamente la misma semntica; no se utiliz en este
ejemplo para ilustrar el uso tradicional de los semforos para implementar regiones de exclusin mutua, sin embargo y slo para concluir con el ejemplo, la
funcin consumidor() final podra escribirse as, y ser semnticamente idntica:
3.3. CONCURRENCIA
1
2
3
4
5
6
95
def consumidor():
while True:
elementos.acquire()
with mutex:
event = buffer.pop()
event.process()
A pesar de ser ms clara, no se emplear en este texto esta notacin por dos
razones. La primera es para mantener la conciencia de la semntica de las operaciones acquire() y release(), y la segunda es mantener la consistencia
a travs de las distintas implementaciones, ya que se encontrarn varios casos
en que no es el mismo hilo el que adquiere un semforo y el que lo libera (esto
es, los semforos no siempre son empleados como mutexes).
3.3.5.
Cuando hay concurrencia, adems de asegurar la atomicidad de ciertas operaciones, se debe evitar dos problemas que son consecuencia natural de la
existencia de la asignacin de recursos de forma exclusiva:
Bloqueo mutuo (o interbloqueo; en ingls, deadlock) Situacin que ocurre cuando dos o ms procesos poseen determinados recursos, y cada uno queda
detenido, a la espera de alguno de los que tiene el otro. El sistema puede
seguir operando normalmente, pero ninguno de los procesos involucrados podrn avanzar.
Inanicin (en ingls resource starvation) Situacin en que un proceso no puede
avanzar en su ejecucin dado que necesita recursos que estn (alternativamente) asignados a otros procesos.
El que se presenten estos conceptos aqu no significa que estn exclusivamente relacionados con este tema: son conceptos que se enfrentan una y otra
vez al hablar de asignacin exclusiva de recursos temtica recurrente en el
campo de los sistemas operativos.
3.3.6.
Planteamiento
Una estructura de datos puede ser accedida simultneamente por muchos
procesos lectores, pero si algn proceso est escribiendo, se debe evitar que
cualquier otro lea (dado que podra encontrarse con los datos en un estado
inconsistente). Los requisitos de sincronizacin son
Cualquier cantidad de lectores puede estar leyendo al mismo tiempo.
96
Discusin
Este problema puede ser generalizado como una exclusin mutua categrica:
se debe separar el uso de un recurso segn la categora del proceso. La presencia de un proceso en la seccin crtica no lleva a la exclusin de otros, pero
s hay categoras de procesos que tienen distintas reglas para los escritores s
hace falta una exclusin mutua completa.
Primera aproximacin
Un primer acercamiento a este problema permite una resolucin libre de
bloqueos mutuos, empleando slo tres estructuras globales: un contador que
indica cuntos lectores hay en la seccin crtica, un mutex protegiendo a dicho
contador, y otro mutex indicando que no hay lectores ni escritores accediendo
al buffer (o cuarto). Se implementan los mutexes con semforos.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
import threading
lectores = 0
mutex = threading.Semaphore(1)
cuarto_vacio = threading.Semaphore(1)
def escritor():
cuarto_vacio.acquire()
escribe()
cuarto_vacio.release()
def lector():
mutex.acquire()
lectores = lectores + 1
if lectores == 1:
cuarto_vacio.acquire()
mutex.release()
lee()
mutex.acquire()
lectores = lectores - 1
if lectores == 0:
cuarto_vacio.release()
mutex.release()
3.3. CONCURRENCIA
97
import threading
lectores = 0
mutex = threading.Semaphore(1)
cuarto_vacio = threading.Semaphore(1)
torniquete = threading.Semaphore(1)
def escritor():
torniquete.acquire()
cuarto_vacio.acquire()
escribe()
cuarto_vacio.release()
torniquete.release()
def lector():
global lectores
torniquete.acquire()
torniquete.release()
mutex.acquire()
lectores = lectores + 1
if lectores == 1:
cuarto_vacio.acquire()
mutex.release()
lee()
mutex.acquire()
lectores = lectores - 1
if lectores == 0:
cuarto_vacio.release()
98
31
En la implementacin de los escritores, esto puede parecer intil: nicamente se agreg un mutex redundante alrededor de lo que ya se tena. Sin
embargo, al hacer que el lector pase por un torniquete antes de actualizar
lectores, obligando a que se mantenga encendida la luz, se lo fuerza a esperar a que el escritor suelte este mutex exterior. Nuevamente se puede ver cmo
la misma estructura es tratada de dos diferentes maneras: para el lector es un
torniquete, y para el escritor es un mutex.
3.3.7.
Planteamiento
Cinco filsofos se dan cita para comer arroz en una mesa redonda. En la
mesa, cada uno de ellos se sienta frente a un plato. A su derecha, tiene un
palito chino, y a su izquierda tiene otro.
Los filsofos slo saben pensar() y comer(). Cada uno de ellos va a
pensar() un tiempo arbitrario, hasta que le da hambre. El hambre es mala
consejera, por lo que intenta comer(). Los requisitos son:
Slo un filsofo puede sostener determinado palito a la vez, esto es los
palitos son recursos de acceso exclusivo.
Debe ser imposible que un filsofo muera de inanicin estando a la espera de un palito.
Debe ser imposible que se presente un bloqueo mutuo.
Debe ser posible que ms de un filsofo pueda comer al mismo tiempo.
Discusin
En este caso, el peligro no es, como en el ejemplo anterior, que una estructura de datos sea sobreescrita por ser accedida por dos hilos al mismo tiempo,
sino que se presenten situaciones en el curso normal de la operacin que lleven
a un bloqueo mutuo.
A diferencia del caso antes descripto, ahora se utilizarn los semforos no
como una herramienta para indicar al planificador cundo despertar a uno de
los hilos, sino como una herramienta de comunicacin entre los propios hilos.
Primer acercamiento
Se puede representar a los palillos como un arreglo de semforos, asegurando la exclusin mutua (esto es, slo un filsofo puede sostener un palillo al
mismo tiempo), pero eso no evita el bloqueo mutuo. Por ejemplo, si la solucin
fuera:
3.3. CONCURRENCIA
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
99
import threading
num = 5
palillos = [threading.Semaphore(1) for i in range(num)]
filosofos = [threading.Thread(target=filosofo,
args=[i]).start() for i in range(num)]
def filosofo(id):
while True:
piensa(id)
levanta_palillos(id)
come(id)
suelta_palillos(id)
def piensa(id):
# (...)
print " %d - Tengo hambre..." % id
def levanta_palillos(id):
palillos[(id+1) % num].acquire()
print " %d - Tengo el palillo derecho" % id
palillos[id].acquire()
print " %d - Tengo ambos palillos" % id
def suelta_palillos(id):
palillos[(id+1) % num].release()
palillos[id].release()
print " %d - Sigamos pensando..." % id
def come(id):
print " %d - A comer!" % id
# (...)
Podra pasar que todos los filsofos quieran comer al mismo tiempo, y el
planificador dejara suspendidos a todos con el palillo derecho en la mano.
Solucin
Ahora, qu pasa si se hace que algunos filsofos sean zurdos? Esto es, que
levanten primero el palillo izquierdo y luego el derecho:
1
2
3
4
5
6
7
def levanta_palillos(id):
if (id % 2 == 0): # Zurdo
palillo1 = palillos[id]
palillo2 = palillos[(id+1) % num]
else: # Diestro
palillo1 = paltos[(id+1) % num]
palillo2 = palillos[id]
100
8
9
10
11
palillo1.acquire()
print " %d - Tengo el primer palillo" % id
palillo2.acquire()
print " %d - Tengo ambos palillos" % id
Al asegurar que dos filsofos contiguos no intenten levantar el mismo palillo, se tiene la certeza de que no se producirn bloqueos mutuos. De hecho, incluso si slo uno de los filsofos es zurdo, se puede demostrar que no habr
bloqueos:
1
2
3
4
5
6
7
8
9
10
def levanta_palillos(id):
if id == 0: # Zurdo
palillos[id].acquire()
print " %d - Tengo el palillo izquierdo" % id
palillos[(id+1) % num].acquire()
else: # Diestro
palillos[(id+1) % num].acquire()
print " %d - Tengo el palillo derecho" % id
palillos[id].acquire()
print " %d - Tengo ambos palillos" % id
3.3.8.
Planteamiento
Hay tres fumadores empedernidos y un agente que, de tiempo en tiempo,
consigue ciertos insumos. Los ingredientes necesarios para fumar son tabaco,
papel y cerillos. Cada uno de los fumadores tiene una cantidad infinita de alguno de los ingredientes, pero no les gusta compartir. Afortunadamente, del
mismo modo que no comparten, no son acaparadores8 .
De tiempo en tiempo, el agente consigue una dosis de dos de los ingredientes por ejemplo, si deja en la mesa un papel y tabaco, el que trae los cerillos
educadamente tomar los ingredientes, se har un cigarro, y lo fumar.
Suhas Patil (1971) plante este problema buscando demostrar que hay
situaciones que no se pueden resolver con el uso de semforos. Las condiciones
planteadas son
No se puede modificar el cdigo del agente. Si el agente es un sistema
operativo, tiene sentido la restriccin de no tenerle que notificar acerca
de los flujos a cada uno de los programas que ejecuta!
8 Esto es, no buscan obtener y conservar los recursos preventivamente, sino que los toman slo
cuando satisfacen por completo sus necesidades.
3.3. CONCURRENCIA
101
El planteamiento original de Patil menciona que no debe emplearse arreglos de semforos o usar condicionales en el flujo. Esta segunda restriccin hara efectivamente irresoluble al problema, por lo que se ignorar.
Primer acercamiento
Al haber tres distintos ingredientes, tiene sentido que se empleen tres distintos semforos, para sealizar a los fumadores respecto a cada uno de los
ingredientes. Un primer acercamiento podra ser:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
import random
import threading
ingredientes = [tabaco, papel, cerillo]
semaforos = {}
semaforo_agente = threading.Semaphore(1)
for i in ingredientes:
semaforos[i] = threading.Semaphore(0)
threading.Thread(target=agente, args=[]).start()
fumadores = [threading.Thread(target=fumador,
args=[i]).start() for i in ingredientes]
def agente():
while True:
semaforo_agente.acquire()
mis_ingr = ingredientes[:]
mis_ingr.remove(random.choice(mis_ingr))
for i in mis_ingr:
print "Proveyendo %s" % i
semaforos[i].release()
def fumador(ingr):
mis_semaf = []
for i in semaforos.keys():
if i != ingr:
mis_semaf.append(semaforos[i])
while True:
for i in mis_semaf:
i.acquire()
fuma(ingr)
semaforo_agente.release()
def fuma(ingr):
print Fumador con %s echando humo... % ingr
El problema en este caso es que, al tener que cubrir un nmero de ingredientes mayor a uno, utilizar slo un semforo ya no funciona: si agente() de-
102
que_tengo = {}
semaforos_interm = {}
for i in ingredientes:
que_tengo[i] = False
semaforos_interm[i] = threading.Semaphore(0)
interm_mutex = threading.Semaphore(1)
intermediarios = [threading.Thread(target=intermediario,
args=[i]).start() for i in ingredientes]
def fumador(ingr):
while True:
semaforos_interm[ingr].acquire()
fuma(ingr)
semaforo_agente.release()
def intermediario(ingr):
otros_ingr = ingredientes[:]
otros_ingr.remove(ingr)
while True:
semaforos[ingr].acquire()
interm_mutex.acquire()
for i in otros_ingr:
if que_tengo[i]:
que_tengo[i] = False
semaforos_interm[i].release()
break
que_tengo[i] = True
interm_mutex.release()
3.3. CONCURRENCIA
103
los tres intermediarios se sincronizarn empleando al arreglo que_tengo (protegido por interm_mutex), y de este modo cada hilo (independientemente
del orden en que fue invocado) sealizar a los otros intermediarios qu ingredientes hay en la mesa, y una vez que sepa a qu fumador notificar, dejar el
estado listo para recibir una nueva notificacin.
3.3.9.
Otros mecanismos
while (sem_trywait(semaforo) != 0) {}
seccion_critica();
sem_post(semaforo);
El cdigo presentado es absolutamente vlido pero cae en una espera activa que desperdicia innecesariamente y constantemente tiempo de procesador
(y no tiene garanta de tener ms xito que una espera pasiva, como sera el
caso con un sem_wait()).
Por otro lado, algn programador puede creer que su cdigo ejecutar suficientemente rpido y con suficientemente baja frecuencia para que la probabilidad de que usar la seccin crtica le cause problemas sea muy baja. Es frecuente
ver ejemplos como el siguiente:
1
2
Los perjuicios causados por este programador resultan obvios. Sin embargo, es comn ver casos como este.
104
Los monitores son estructuras provistas por el lenguaje o entorno de desarrollo que encapsulan tanto a los datos como a las funciones que los pueden manipular, e impiden el acceso directo a las funciones potencialmente peligrosas
en otras palabras, son tipos de datos abstractos (ADTs), clases de objetos, y exponen
una serie de mtodos pblicos, adems de poseer mtodos privados que emplean
internamente.
Al no presentar al usuario/programador una interfaz que puedan subvertir,
el monitor mantiene todo el cdigo necesario para asegurar el acceso concurrente a los datos en un slo lugar.
Un monitor puede implementarse utilizando cualquiera de los mecanismos
de sincronizacin presentados anteriormente la diferencia radica en que esto
se hace en un solo lugar. Los programas que quieran emplear el recurso protegido lo hacen incluyendo el cdigo del monitor como mdulo / biblioteca, lo
cual fomenta la reutilizacin de cdigo.
Como ejemplo, el lenguaje de programacin Java implementa sincronizacin
va monitores entre hilos como una propiedad de la declaracin de mtodo, y
lo implementa directamente en la JVM. Si se declara un mtodo de la siguiente
manera:
1
2
3
4
5
6
7
Y se inicializa a un SimpleClass sc = new SimpleClass(), cuando se llame a sc.metodoSeguro(), la mquina virtual verificar si ningn
otro proceso est ejecutando metodoseguro(); en caso de que no sea as,
le permitir la ejecucin obteniendo el candado, y en caso de s haberlo, el
hilo se bloquear hasta que el candado sea liberado esto es, la propiedad
synchronized hace que todo acceso al mtodo en cuestin sea protegido por
una mutex.
El modelo de sincronizacin basado en monitores no slo provee la exclusin mutua. A travs de variables de condicin (VCs) se puede tambin emplear una semntica parecida (aunque no igual) a la de los semforos, con
los mtodos var.wait() y var.signal(). En el caso de los monitores,
var.wait() suspende al hilo hasta que otro hilo ejecute var.signal(); en
caso de no haber ningn proceso esperando, var.signal() no tiene ningn
efecto (no cambia el estado de var, a diferencia de lo que ocurre con los semforos)
Aqu se presenta, a modo de ilustracin, la resolucin del problema de la
3.3. CONCURRENCIA
105
cena de los filsofos en C9 . Esto demuestra, adems, que si bien se utiliza semntica de orientacin a objetos, no slo los lenguajes clsicamente relacionados
con la programacin orientada a objetos permiten emplear monitores.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
106
42
43
44
45
46
47
48
49
50
51
52
53
3.3. CONCURRENCIA
10
11
12
13
14
15
16
17
18
19
20
107
int main() {
int i;
pthread_t th[5]; /* IDs de los hilos filsofos */
pthread_attr_t attr = NULL;
palillos_init();
for (i=0; i<5; i++)
pthread_create(&th[i], attr, filosofo, (int*) &i);
for (i=0; i<5; i++)
pthread_join(th[i],NULL);
}
do {
begin_transaction();
var1 = var2 * var3;
var3 = var2 - var1;
var2 = var1 / var2;
} while (! commit_transaction());
108
casos en que, sin embargo, esta tcnica puede an llevar a resultados inconsistentes (particularmente si un proceso lector puede recibir los valores que van
cambiando en el tiempo por parte de un segundo proceso), y el costo computacional de dichas operaciones es elevado, sin embargo, es una construccin muy
poderosa.
3.4.
Bloqueos mutuos
109
Figura 3.6: Esquema clsico de un bloqueo mutuo simple: los procesos A y B esperan mutuamente para el acceso a las unidades de cinta 1 y 2.
110
3.4.1.
Prevencin de bloqueos
111
un acceso directo del proceso al disco), pero slo uno podra obtener recursos
de forma exclusiva al mismo tiempo. Este mecanismo sera la serializacin, y la
situacin antes descripta se resolvera de la siguiente manera:
1. A solicita una unidad de cinta y se bloquea
2. B solicita una unidad de cinta y se bloquea
3. El sistema operativo otorga la unidad 1 a A y lo vuelve a poner en ejecucin
4. A contina procesando; termina su periodo de ejecucin
5. El sistema operativo mantiene bloqueado a B, dado que A tiene un recurso
6. A solicita otra unidad de cinta y se bloquea
7. El sistema operativo otorga la unidad 2 a A y lo vuelve a poner en ejecucin
8. A libera la unidad de cinta 1
9. A libera la unidad de cinta 2 (y con ello, el bloqueo de uso de recursos)
10. El sistema operativo otorga la unidad 1 a B y lo vuelve a poner en ejecucin
11. B solicita otra unidad de cinta y se bloquea
12. El sistema operativo otorga la unidad 2 a B y lo vuelve a poner en ejecucin
13. B libera la unidad de cinta 1
14. B libera la unidad de cinta 2
Si bien la serializacin resuelve la situacin aqu mencionada, el mecanismo
empleado es subptimo dado que puede haber hasta n-1 procesos esperando a
que uno libere los recursos.
Un sistema que implementa una poltica de asignacin de recursos basada
en la serializacin, si bien no caer en bloqueos mutuos, s tiene un peligro
fuerte de caer en inanicin.
112
113
arriesgarse a soltarla, pues podra ser entregada a otro proceso y corromperse el resultado.
Asignacin jerrquica
Otro mecanismo de evasin es la asignacin jerrquica de recursos. Bajo este
mecanismo, se asigna una prioridad o nivel jerrquico a cada recurso o clase de
recursos.10 La condicin bsica es que, una vez que un proceso obtiene un recurso de determinado nivel, slo puede solicitar recursos adicionales de niveles superiores. En caso de requerir dos dispositivos ubicados al mismo nivel,
tiene que hacerse de forma atmica.
De este modo, si las unidades de cinta tienen asignada la prioridad x, P1
slo puede solicitar dos unidades de cinta por medio de una sla operacin. En
caso de tambin requerir dos unidades de cinta el proceso P2 al mismo tiempo,
al ser atmicas las solicitudes, stas le sern otorgadas a slo un de los dos
procesos, por lo cual no se presentar bloqueo.
Adems, el crear una jerarqua de recursos permitira ubicar los recursos
ms escasos o peleados en la cima de la jerarqua, reduciendo las situaciones
de contencin en que varios procesos compiten por dichos recursos slo
llegaran a solicitarlos aquellos procesos que ya tienen asegurado el acceso a los
dems recursos que vayan a emplear.
Sin embargo, este ordenamiento es demasiado estricto para muchas situaciones del mundo real. El tener que renunciar a ciertos recursos para adquirir
uno de menor prioridad y volver a competir por ellos, adems de resultar contraintuitivo para un programador, resulta en esperas frustrantes. Este mecanismo llevara a los procesos a acaparar recursos de baja prioridad, para evitar
tener que ceder y re-adquirir recursos ms altos, por lo que conduce a una alta
inanicin.
3.4.2.
Evasin de bloqueos
114
115
espera si t A 2 cuando 2 t B 6.
La regin marcada como inalcanzable en color amarillo, no representa
ningn peligro: slo indica aquellos estados en que resulta imposible entrar. Incluso una vez evadido el bloqueo (por ejemplo, si B fue suspendido en t B = 1,8
y A avanza hasta pasar t A = 7, si el sistema operativo vuelve a dar la ejecucin
a B, este slo podr avanzar hasta t B = 2, punto en que B solicita la impresora. Para que B contine, es necesario avanzar hasta t A > 7,5 para que B siga
avanzando.
Este mecanismo proveera una mejor respuesta que los vistos en el apartado
de prevencin de bloqueos, pero es todava ms dificil de aplicar en situaciones
reales. Para poder implementar un sistema con evasin de bloqueos, tendra
que ser posible hacer un anlisis esttico previo del cdigo a ejecutar, y tener
un listado total de recursos esttico. Estos mecanismos podran ser efectivos
en sistemas de uso especializado, pero no en sistemas operativos (o planificadores) genricos.
Algoritmo del banquero
Edsger Dijkstra propuso un algoritmo de asignacin de recursos orientado
a la evasin de bloqueos a ser empleado para el sistema operativo THE (desarrollado entre 1965 y 1968 en la Escuela Superior Tcnica de Eindhoven, Technische Hogeschool Eindhoven), un sistema multiprogramado organizado en
anillos de privilegios. El nombre de este algoritmo proviene de que busca que
el sistema opere cuidando de tener siempre la liquidez (nunca entrar a estados
inseguros) para satisfacer los prstamos (recursos) solicitados por sus clientes
(quienes a su vez tienen una lnea de crdito pre-autorizada por el banco).
Este algoritmo permite que el conjunto de recursos solicitado por los procesos en ejecucin en el sistema sea mayor a los recursos fsicamente disponibles,
pero a travs de un monitoreo y control en su asignacin, logra este nivel de
sobre-compromiso sin poner en riesgo la operacin correcta del sistema.
Este algoritmo debe ejecutarse cada vez que un proceso solicita recursos;
el sistema evita caer en situaciones conducentes a un bloqueo mutuo ya sea
denegando o posponiendo la solicitud. El requisito particular es que, al iniciar,
cada proceso debe anunciar su reclamo mximo (llamese claim()) al sistema:
el nmero mximo de recursos de cada tipo que va a emplear a lo largo de su
ejecucin esto sera implementado como una llamada al sistema. Una vez
que un proceso present su reclamo mximo de recursos, cualquier llamada
subsecuente a claim() falla. Claro est, si el proceso anuncia una necesidad
mayor al nmero existente de recursos de algn tipo, tambin falla dado que
el sistema no ser capaz de cumplirlo.
Para el algoritmo del banquero:
Estado matrices de recursos disponibles, reclamos mximos y asignacin de
recursos a los procesos en un momento dado.
116
Estado seguro un estado en el cual todos los procesos pueden ejecutar hasta
el final sin encontrar un bloqueo mutuo.
Estado inseguro todo estado que no garantice que todos los procesos puedan
ejecutar hasta el final sin encontrar un bloqueo mutuo.
Este algoritmo tpicamente trabaja basado en diferentes categoras de recursos, y los reclamos mximos anunciados por los procesos son por cada una de
las categoras.
El estado est compuesto, por clase de recursos y por proceso, por:
Reclamado nmero de instancias de este recurso que han sido reclamadas.
Asignado nmero de instancias de este recurso actualmente asignadas a procesos en ejecucin.
Solicitado nmero de instancias de este recurso actualmente pendientes de
asignar (solicitudes hechas y no cumplidas).
Adems de esto, el sistema mantiene globalmente, por clase de recursos:
Disponibles nmero total de instancias de este recurso disponibles al sistema.
Libres nmero de instancias de este recurso que no estn actualmente asignadas a ningn proceso.
Cada vez que un proceso solicita recursos, se calcula cul sera el estado
resultante de otorgar dicha solicitud, y se otorga siempre que:
No haya reclamo por ms recursos que los disponibles.
Ningn proceso solicite (o tenga asignados) recursos por encima de su
reclamo.
La suma de los recursos asignados por cada categora no sea mayor a la
cantidad de recursos disponibles en el sistema para dicha categora.
Formalmente, y volviendo a la definicin de un estado seguro: un estado es
seguro cuando hay una secuencia de procesos (denominada secuencia segura) tal
que:
1. Un proceso j puede necesariamente terminar su ejecucin, incluso si solicitara todos los recursos que permite su reclamo, dado que hay suficientes recursos libres para satisfacerlo.
2. Un segundo proceso k de la secuencia puede terminar si j termina y libera
todos los recursos que tiene, porque sumado a los recursos disponibles
ahora, con aquellos que liberara j, hay suficientes recursos libres para
satisfacerlo.
117
3. El i-simo proceso puede terminar si todos los procesos anteriores terminan y liberan sus recursos.
En el peor de los casos, esta secuencia segura llevara a bloquear todas las
solicitudes excepto las del nico proceso que puede avanzar sin peligro en el
orden presentado.
Se presnta un ejemplo simplificando, asumiendo slo una clase de procesos,
e iniciando con 2 instancias libres:
Proceso
A
B
C
Asignado
4
4
2
Reclamando
6
11
7
A puede terminar porque slo requiere de 2 instancias adicionales para llegar a las 6 que indica en su reclamo. Una vez que termine, liberar sus 6 instancias. Se le asignan entonces las 5 que solicita a C, para llegar a 7. Al terminar
ste, habr 8 disponibles, y asignndole 7 a B se garantiza poder terminar. La
secuencia (A, C, B) es una secuencia segura.
Sin embargo, el siguiente estado es inseguro (asumiendo tambin dos instancias libres):
Proceso
A
B
C
Asignado
4
4
2
Reclamado
6
11
9
118
6
7
8
9
10
libres += asignado[p]
l.delete(p)
s.push(p)
end
puts "La secuencia segura encontrada es: %s" % s
Hay refinamientos sobre este algoritmo que logran resultados similares, reduciendo su costo de ejecucin (se debe recordar que es un procedimiento que
puede ser llamado con muy alta frecuencia), como el desarrollado por Habermann (ref: Finkel, p.136).
El algoritmo del banquero es un algoritmo conservador, dado que evita entrar en un estado inseguro a pesar de que dicho estado no lleve con certeza a
un bloqueo mutuo. Sin embargo, su poltica es la ms liberal que permite asegurar que no se caer en bloqueos mutuos, sin conocer el orden y tiempo en que
cada uno de los procesos requerira los recursos.
Una desventaja fuerte de todos los mecanismos de evasin de bloqueos es
que requieren saber por anticipado los reclamos mximos de cada proceso, lo
cual puede no ser conocido en el momento de su ejecucin.
3.4.3.
119
Figura 3.10: Situacin en que se presenta espera circular, incluso empleando categoras de recursos
Si se tiene una representacin completa de los procesos y recursos en el sistema, la estrategia es reducir la grfica retirando los elementos que no brinden
informacin imprescindible, siguiendo la siguiente lgica (recordar que repre-
120
121
posibilidad de hacerlo. Los procesos que estan esperando por recursos retenidos
por un proceso pueden sufrir inanicin an por un tiempo indeterminado.
Una vez que un bloqueo es diagnosticado, dado que los procesos no podrn
terminar por s mismos (pues estn precisamente bloqueados, su ejecucin no
avanzar ms), hay varias estrategias para la recuperacin:
Terminar a todos los procesos bloqueados. Esta es la tcnica ms sencilla
y, de cierto modo, ms justa todos los procesos implicados en el bloqueo pueden ser relanzados, pero todo el estado del cmputo que han
realizado hasta este momento se perder.
Retroceder a los procesos implicados hasta el ltimo punto de control (checkpoint) seguro conocido. Esto es posible nicamente cuando el sistema implementa esta funcionalidad, que tiene un elevado costo adicional. Cuando el estado de uno de los procesos depende de factores externos a ste,
es imposible implementar fielmente los puntos de control.
Podra parecer que retroceder a un punto previo llevara indefectiblemente a que se repita la situacin pero los bloqueos mutuos requieren
de un orden de ejecucin especfico para aparecer. Muy probablemente,
una ejecucin posterior lograr salvar el bloqueo y en caso contrario,
puede repetirse este paso.
Terminar, uno por uno y no en bloque, a cada uno de los procesos bloqueados. Una vez que se termina uno, se evala la situacin para verificar
si logr romperse la situacin de bloqueo, en cuyo caso la ejecucin de los
restantes contina sin interrupcin.
Para esto, si bien podra elegirse un proceso al azar de entre los bloqueados, tpicamente se consideran elementos adicionales como:
Los procesos que demandan garantas de tiempo real son los ms
sensibles para detener y relanzar
La menor cantidad de tiempo de procesador consumido hasta el
momento. Dado que el proceso probablemente tenga que ser relanzado (re-ejecutado), puede ser conveniente apostarle a un proceso
que haya hecho poco clculo (para que el tiempo que tenga que invertir para volver al punto actual sea mnimo).
Mayor tiempo restante estimado. Si se puede estimar cunto tiempo
de procesamiento queda pendiente, conviene terminar al proceso que
ms le falte por hacer.
Menor nmero de recursos asignados hasta el momento. Un poco
como criterio de justicia, y un poco partiendo de que es un proceso
que est haciendo menor uso del sistema.
122
Un punto importante a considerar es cada cunto debe realizarse la verificacin de bloqueos. Podra hacerse:
Cada vez que un proceso solicite un recurso. pero esto llevara a un gasto
de tiempo en este anlisis demasiado frecuente.
Con una periodicidad fija, pero esto arriesga a que los procesos pasen
ms tiempo bloqueados.
Cuando el nivel del uso del CPU baje de cierto porcentaje. Esto indicara
que hay un nivel elevado de procesos en espera.
Una estrategia combinada.
Por ltimo, si bien los dispositivos aqu mencionados requieren bloqueo exclusivo, otra estragegia es la apropiacin temporal: tomar un recurso asignado a
determinado proceso para otorgrselo temporalmente a otro. Esto no siempre es
posible, claro, y depende fuertemente de la naturaleza del mismo pero podra, por ejemplo, interrumpirse un proceso que tiene asignada (pero inactiva)
a una impresora para otorgrsela temporalmente a otro que tiene un trabajo corto pendiente. Esto ltimo, sin embargo, es tan sensible a detalles de cada
clase de recursos que rara vez puede hacerlo el sistema operativo es normalmente hecho de acuerdo entre los procesos competidores, por medio de algn
protocolo pre-establecido.
3.4.4.
Una cuarta lnea (que, por increble que parezca, es la ms comn, empleada en todos los sistemas operativos de propsito general) es el llamado algoritmo del avestruz: ignorar las situaciones de bloqueo (escondindose de ellas
como avestruz que esconde la cabeza bajo la tierra), esperando que su ocurrencia sea suficientemente poco frecuente, o si ocurre, que su impacto no afecte al
sistema.
123
124
recuperarse).
De avestruces, ingenieros y matemticos
Esta misma contraposicin puede leerse, hasta cierto punto en tono de broma, como un sntoma de la tensin que caracteriza al cmputo como profesin:
la computacin naci como ciencia dentro de los departamentos de matemticas en diversas facultades, sin embargo, al pasar de los aos ha ido integrando
cada vez ms a la ingeniera. Y el campo, una de las reas ms jvenes pero al
mismo tiempo ms prolficas del conocimiento humano, est en una constante
discusin y definicin: Cmo puede describirse mejor a sus profesionales?
Como matemticos, ingenieros, o. . . alguna otra cosa?
La asignacin de recursos, pues, puede verse desde el punto de vista
matemtico: es un problema con un planteamiento de origen, y hay varias
estrategias distintas (los mecanismos y algoritmos descritos en esta seccin).
Pueden no ser perfectos, pero el problema no ha demostrado ser intratable. Y un
bloqueo es claramente un error una situacin de excepcin, inaceptable. Los
matemticos del rbol genealgico acadmico llaman a no ignorar este problema, a resolverlo sin importar la complejidad computacional.
Los ingenieros, ms aterrizados en el mundo real, tienen como parte bsica de su formacin, s, el evitar defectos nocivos pero tambin contemplan
el clculo de costos, la probabilidad de impacto, los umbrales de tolerancia. . .
Para un ingeniero, si un sistema tpico corre riesgo de caer en un bloqueo mutuo
con una probabilidad p > 0, dejando inservibles a dos procesos en un sistema,
pero debe tambin considerar no slo las fallas en hardware y en los diferentes
componentes del sistema operativo, sino que en todos los dems programas
que ejecutan en espacio de usuario, y considerando que prevenir el bloqueo
conlleva un costo adicional en complejidad para el desarrollo o en rendimiento
del sistema (dado que perder tiempo llevando a cabo las verificaciones ante
cualquier nueva solicitud de recursos), no debe sorprender a nadie que los ingenieros se inclinen por adoptar la estrategia del avestruz claro est, siempre
que no haya opcin razonable.
3.5.
Ejercicios
3.5.1.
Preguntas de autoevaluacin
3.5. EJERCICIOS
125
126
6. Los bloqueos mutuos no slo ocurren en el campo del cmputo. Identifique, basndose en las condiciones de Coffman, situaciones de la vida real
que (de no ser por el ingenio o la impredictibilidad humana) constituiran
bloqueos mutuos. Describa por qu considera que se cumple cada una de
las condiciones.
7. Suponga un sistema con 14 dispositivos del mismo tipo, que requieren
acceso exclusivo. En este sistema se ejecutarn de forma simultnea cinco procesos de larga duracin, cada uno de los cuales requerir el uso de
cinco de estos dispositivos Tres de ellos desde temprano en la ejecucin del proceso, y los dos restantes, apenas por unos segundos y cerca
del fin de su ejecucin.
Si el sistema implementa una poltica muy conservadora de asignacin de recursos (Serializacin), cuntos dispositivos estarn ociosos
como mnimo y como mximo mientras se mantengan los cinco procesos en ejecucin?
Si el sistema implementa una poltica basada en el Algoritmo del banquero, cul ser el mximo de procesos que puedan avanzar al mismo tiempo? Cuntos dispositivos estarn ociosos como mnimo y
como mximo mientras se mantengan los cinco procesos en ejecucin?
3.5.2.
Sistemas de arranque modernos en sistemas tipo Unix Un tema no directamente relacionado con el expuesto en este captulo, pero que puede ligarse con varios de los conceptos aqu abordados, es la gestin del arranque del sistema: Una vez que el ncleo carga y hace un recorrido
bsico del hardware crendose un mapa de cmo es el sistema en que
est corriendo, tiene que llevar el equipo a un estado funcional para sus
usuarios. Cmo ocurre esto?
Tradicionalmente, los sistemas Unix se dividan entre dos filosofas de arranque (los sistemas SysV y los sistemas BSD). Pero la realidad del cmputo ha cambiado con el tiempo. Tras una etapa de largas discusiones al
respecto, la mayor parte de las distribuciones estn migrando a systemd,
desarrollado originalmente por RedHat.
Cules son los planteamientos bsicos de los arranques tipo SysV y tipo
BSD? A qu tipo de cambios en la realidad es que se hace referenciarefiero? Por qu los esquemas tradicionales ya no son suficientes para los
sistemas actuales? En qu se parecen y en qu se diferencian los sistemas
clsicos y systemd? Qu ventajas y desventajas conllevan?
3.5. EJERCICIOS
127
3.5.3.
Lecturas relacionadas
128
Captulo 4
Planificacin de procesos
4.1.
Tipos de planificacin
129
130
A mediano plazo Decide cules procesos es conveniente bloquear en determinado momento, sea por escasez/saturacin de algn recurso (como la
memoria primaria) o porque estn realizando alguna solicitud que no
puede satisfacerse momentaneamente; se encarga de tomar decisiones
respecto a los procesos conforme entran y salen del estado de bloqueado
(esto es, tpicamente, estn a la espera de algn evento externo o de la
finalizacin de transferencia de datos con algn dispositivo).
En algunos textos, al planificador a mediano plazo se le llama agendador
(scheduler).
A corto plazo Decide cmo compartir momento a momento al equipo entre todos los procesos que requieren de sus recursos, especialmente el procesador. La planificacin a corto plazo se lleva a cabo decenas de veces por
segundo (razn por la cual debe ser cdigo muy simple, eficiente y rpido); es el encargado de planificar los procesos que estn listos para ejecucin.
El planificador a corto plazo es tambin frecuentemente denominado despachador
(dispatcher).
131
4.1.1.
Tipos de proceso
Como ya se ha visto, los procesos tpicamente alternan entre rfagas (periodos, en ingls bursts) en que realizan principalmente cmputo interno (estn limitados por CPU, CPU-bound) y otras en que la atencin est puesta en
132
transmitir los datos desde o hacia dispositivos externos (estn limitados por
entrada-salida, I/O-bound). Dado que cuando un proceso se suspende para realizar entrada-salida deja de estar listo (y pasa a estar bloqueado), y desaparece
de la atencin del planificador a corto plazo, en todo momento los procesos
que estn en ejecucin y listos pueden separarse en:
Procesos largos Aquellos que por mucho tiempo1 han estado en listos o en ejecucin, esto es, procesos que estn en una larga rfaga limitada por CPU.
Procesos cortos Aquellos que, ya sea que en este momento2 estn en una rfaga
limitada por entrada-salida y requieran atencin meramente ocasional
del procesador, o tienden a estar bloqueados esperando a eventos (como
los procesos interactivos).
Por lo general se busca dar un tratamiento preferente a los procesos cortos,
en particular a los interactivos. Cuando un usuario est interactuando con un
proceso, si no tiene una respuesta inmediata a su interaccin con el equipo (sea
proporcionar comandos, recibir la respuesta a un teclazo o mover el puntero en
el GUI) su percepcin ser la de una respuesta degradada.
4.1.2.
Midiendo la respuesta
Resulta intuitivo que cada patrn de uso del sistema debe seguir polticas
de planificacin distintas. Por ejemplo, en el caso de un proceso interactivo,
se buscar ubicar al proceso en una cola preferente (para obtener un tiempo
de respuesta ms gil, para mejorar la percepcin del usuario), pero en caso
de sufrir demoras, es preferible buscar dar una respuesta consistente, an si
la respuesta promedio es ms lenta. Esto es, si a todas las operaciones sigue
una demora de un segundo, el usuario sentir menos falta de control si en
promedio tardan medio segundo, pero ocasionalmente hay picos de cinco.
Para este tema, en vez de emplear unidades temporales formales (p. ej.
fracciones de segundo), es comn emplear ticks y quantums. Esto es en buena medida porque, si bien en el campo del cmputo las velocidades de acceso y uso efectivo cambian constantemente, los conceptos y las definiciones
permanecen. Adems, al ser ambos parmetros ajustables, una misma implementacin puede sobrevivir ajustndose a la evolucin del hardware.
Tick Una fraccin de tiempo durante la cual se puede realizar trabajo til - Esto
es, usar la CPU sin interrupcin3 . El tiempo correspondiente a un tick
est determinado por una seal (interrupcin) peridica, emitida por el
temporizador (timer). La frecuencia con que ocurre esta seal se establece
1 Cunto
133
134
Ticks
7
3
12
4
Llegada
0
2
6
20
Figura 4.5: Ejecucin de cuatro procesos con quantums de 5 ticks y cambios de contexto de 2 ticks
5 Este
135
t
7
3
12
4
6.5
6
6.4
T
18
7
26
9
15
32
18.4
E
11
4
14
5
8.50
26
12.00
P
2.57
2.33
2.17
2.25
2.31
5.33
2.88
R
0.389
0.429
0.462
0.444
0.433
0.188
0.348
4.2.
Algoritmos de planificacin
El planificador a corto plazo puede ser invocado cuando un proceso se encuentra en algunas de las cuatro siguientes circunstancias:
1. Pasa de estar ejecutando a estar en espera (por ejemplo, por solicitar una
operacin de E/S, esperar a la sincronizacin con otro proceso, etc.)
2. Pasa de estar ejecutando a estar listo (por ejemplo, al ocurrir la interrupcin
del temporizador, o de algn evento externo)
3. Deja de estar en espera a estar listo (por ejemplo, al finalizar la operacin
de E/S que solicit)
4. Finaliza su ejecucin, y pasa de ejecutando a terminado
6 Normalmente no se considera al ncleo al hacer este clculo, dado que en este mbito todo el
trabajo que hace puede verse como burocracia ante los resultados deseados del sistema
136
En el primer y cuarto casos, el sistema operativo siempre tomar el control7 ; un sistema que opera bajo multitarea apropiativa implementar tambin el
segundo y tercer casos, mientras que uno que opera bajo multitarea cooperativa
no necesariamente reconocer dichos estados.
Ahora, para los algoritmos a continuacin, cabe recordar que se trata nicamente del despachador. Un proceso siempre abandonar la cola de procesos
listos al requerir de un servicio del sistema.
Para todos los ejemplos a continuacin, los tiempos estn dados en ticks; no
es relevante a cunto tiempo de reloj estos equivalen, sino el rendimiento relativo
del sistema entero ante una carga dada.
La presente seccin est basada fuertemente en el captulo 2 de An operating
systems vade mecum (Raphael Finkel, 1988).
4.2.1.
Objetivos de la planificacin
137
Favorecer el uso esperado del sistema En un sistema con usuarios interactivos, maximizar la prioridad de los procesos que sirvan a solicitudes
iniciadas por ste (an a cambio de penalizar a los procesos de sistema )
Dar preferencia a los procesos que podran causar bloqueo Si un proceso de
baja prioridad est empleando un recurso del sistema por el cual ms
procesos estn esperando, favorecer que ste termine de emplearlo ms
rpido
Favorecer a los procesos con un comportamiento deseable Si un proceso causa
muchas demoras (por ejemplo, atraviesa una rfaga de entrada/salida
que le requiere hacer muchas llamadas a sistema o interrupciones), se le
puede penaliza porque degrada el rendimiento global del sistema
Degradarse suavemente Si bien el nivel ideal de utilizacin del procesador
es al 100 %, es imposible mantenerse siempre a este nivel. Un algoritmo
puede buscar responder con la menor penalizacin a los procesos preexistentes al momento de exceder este umbral.
4.2.2.
Tiempo de
Llegada
0
1
3
9
12
Inicio
Fin
3
5
2
5
5
4
0
3
8
10
15
3
8
10
15
20
3
7
7
6
8
6.2
0
2
5
1
3
2.2
1
1.4
3.5
1.2
1.6
1.74
138
4.2.3.
El esquema ronda busca dar una relacin de respuesta buena tanto para procesos largos como para los cortos. La principal diferencia entre la ronda y FCFS
es que en este caso s emplea multitarea apropiativa: cada proceso que est en
la lista de procesos listos puede ejecutarse por un slo quantum (q). Si un proceso no ha terminado de ejecutar al final de su quantum, ser interrumpido y
puesto al final de la lista de procesos listos, para que espere a su turno nuevamente. Los procesos que sean despertados por los planificadores a mediano o
largo plazo se agregarn tambin al final de esta lista.
Con la misma tabla de procesos presentada en el caso anterior (y, por ahora,
ignorando la sobrecarga administrativa provocada por los cambios de contexto) se obtienen los siguientes resultados:
Proceso
A
B
C
D
E
Promedio
Tiempo de
Llegada
0
1
3
9
12
Inicio
Fin
3
5
2
5
5
4
0
1
4
9
12
6
11
8
18
20
6
10
5
9
8
7.6
3
5
3
4
3
3.6
2.0
2.0
2.5
1.8
1.6
1.98
139
notar las rfagas de atencin que ste le da (avance rpido durante un periodo
corto seguido de un periodo sin avance). Claro est, el procesador simulado
sera cada vez ms lento, dada la fuerte penalizacin que ira agregando la sobrecarga administrativa.
Finkel (1988, p.35) se refiere a esto como el principio de la histresis: hay que
resistirse al cambio. Como ya lo se mencion, FCFS mantiene al mnimo posible
la sobrecarga administrativa, y aunque sea marginalmente resulta en mejor
rendimiento global.
Si se repite el anlisis anterior bajo este mismo mecanismo, pero con un
quantum de 4 ticks, el resultado es:
Proceso
A
B
C
D
E
Promedio
Tiempo de
Llegada
0
1
3
9
12
Inicio
Fin
3
5
2
5
5
4
0
3
7
10
14
3
10
9
19
20
3
9
6
10
8
7.2
0
4
4
5
3
3.2
1.0
1.8
3.0
2.0
1.6
1.88
Si bien aumentar el quantum mejora los tiempos promedio de respuesta, aumentarlo hasta convertirlo en un FCFS efectivo degenera en una penalizacin
140
4.2.4.
Tiempo de
Llegada
0
1
3
9
12
Inicio
Fin
3
5
2
5
5
4
0
5
3
10
15
3
10
5
15
20
3
9
2
6
8
5.6
0
4
0
1
3
1.6
1.0
1.8
1.0
1.2
1.6
1.32
9 Cabe recordar que todos estos mecanismos se aplican al planificador a corto plazo. Cuando un
proceso se bloquea esperando una operacin de E/S, sigue en ejecucin, y la informacin de contabilidad del mismo sigue alimentndose. SPN se nutre precisamente de dicha informacin de
contabilidad.
141
Como era de esperarse, SPN favorece a los procesos cortos. Sin embargo,
un proceso largo puede esperar mucho tiempo antes de ser atendido, especialmente con valores de cercanos o superiores a 1 un proceso ms largo que
el promedio est predispuesto a sufrir inanicin.
142
ora de los procesos. Incluso para procesos muy largos, PSPN no los penaliza mucho ms all de lo que lo hara la ronda, y obtiene mejores promedios
de forma consistente porque, al despachar primero a los procesos ms cortos,
mantiene la lista de procesos pendientes corta, lo que lleva naturalmente a
menores ndices de penalizacin.
4.2.5.
Tiempo de
Llegada
0
1
3
9
12
143
Inicio
Fin
3
5
2
5
5
4
0
2
6
10
15
4
10
9
15
20
4
9
6
6
8
6.6
1
4
4
1
3
2.6
1.3
1.8
3.0
1.2
1.6
1.79
Mientras ba < 1, la prioridad de un proceso entrante eventualmente alcanzar a la de los procesos aceptados, y comenzar a ejecutarse. Mientras el control va alternando entre dos o ms procesos, la prioridad de todos ellos ser la
misma (esto es, son despachados efectivamente por una simple ronda).
Incluso cuando ba 1, el proceso en ejecucin terminar, y B ser aceptado.
En este caso, este esquema se convierte en FCFS.
Si ba = 0 (esto es, si b = 0), los procesos recin llegados sern aceptados
inmediatamente, con lo cual se convierte en una ronda. Mientras 0 < ba < 1, la
ronda ser relativamente egosta, dndole entrada a los nuevos procesos incluso
si los que llevan mucho tiempo ejecutando son muy largos (y por tanto, su
prioridad es muy alta).
4.2.6.
(Multilevel Feedback)
El mecanismo descrito en la seccin anterior, la ronda egosta, introdujo el
concepto de tener no una sino que varias colas de procesos, que recibirn diferente tratamiento. Este mecanismo es muy poderoso, y se emplea en prcticamente todos los planificadores en uso hoy en da. Antes de abordar al esquema
de retroalimentacin multinivel, conviene presentar cmo opera un sistema
con mltiples colas de prioridad.
La figura 4.12 ilustra cmo se presentara una situacin bajo esta lgica: el
sistema hipottico tiene cinco colas de prioridad, y siete procesos listos para
144
Figura 4.12: Representacin de un sistema con cinco colas de prioridad y siete procesos listos
ser puestos en ejecucin. Puede haber colas vacas, como en este caso la 3. Dado que la cola de mayor prioridad es la 0, el planificador elegir nicamente
entre los procesos que estn formados en ella: F o C. Slo cuando estos procesos
terminen (o sean enviados a alguna otra cola), el planificador continuar con
aquellos que estn en las siguientes colas.
La retroalimentacin multinivel basa su operacin en ms de una cola pero
en este caso, todas ellas tendrn el mismo tratamiento general, distinguindose
slo por su nivel de prioridad, C0 a Cn . El despachador elegir para su ejecucin
al proceso que est al frente de la cola de mayor prioridad que tenga algn proceso esperando Ci , y tras un nmero predeterminado de ejecuciones, lo degrada
a la cola de prioridad inmediata inferior Ci+1 .
El mecanismo de retroalimentacin multinivel favorece a los procesos cortos, dado que terminarn sus tareas sin haber sido marcados como de prioridades inferiores.
La ejecucin del juego de datos con que han sido presentados los algoritmos
anteriores bajo este esquema da los siguientes resultados:
Proceso
A
B
C
D
E
Promedio
Tiempo de
Llegada
0
1
3
9
12
Inicio
Fin
3
5
2
5
5
4
0
1
3
9
12
7
18
6
19
20
7
17
3
10
8
9
4
12
1
5
3
5
1.7
3.4
1.5
2.0
1.6
2.04
Dado que ahora hay que representar la cola en la que est cada uno de los
procesos, en la figura 4.13 se presenta sobre cada una de las lneas de proceso
la prioridad de la cola en que se encuentra antes del quantum a iniciar:
Llama la atencin que prcticamente todos los nmeros apuntan a que esta
145
es una peor estrategia que las presentadas anteriormente los nicos procesos beneficiados en esta ocasin son los recin llegados, que podrn avanzar
al principio, mientras los procesos ms largos sern castigados y podrn eventualmente (a mayor ) enfrentar inanicin.
Sin embargo, esta estrategia permite ajustar dos variables: una es la cantidad de veces que un proceso debe ser ejecutado antes de ser degradado a la
prioridad inferior, y la otra es la duracin del quantum asignado a las colas
subsecuentes.
Otro fenmeno digno a comentar es el que se presenta a los ticks 8, 10,
11, 13 y 14: El despachador interrumpe la ejecucin del proceso activo, para
volver a cedrsela. Esto ocurre porque, efectivamente, concluy su quantum
idealmente, el despachador se dar cuenta de esta situacin de inmediato y no
iniciar un cambio de contexto al mismo proceso. En caso contrario, el trabajo
perdido por gasto administrativo se vuelve innecesariamente alto.
El panorama cambia al ajustar estas variables: si se elige un quantum de 2n q,
donde n es el identificador de cola y q la longitud del quantum base, un proceso
largo ser detenido por un cambio de contexto al llegar a q, 3q, 7q, 15q, etc. lo
t( p)
que llevar al nmero total de cambios de contexto a log( q ), lo cual resulta
t( p)
Tiempo de
Llegada
0
1
3
9
12
Inicio
Fin
3
5
2
5
5
4
0
1
4
10
13
4
10
8
18
20
4
9
5
9
8
7
1
4
3
4
3
3
1.3
1.8
2.5
1.8
1.6
1.8
146
4.2.7.
Lotera
Los mecanismos hasta aqu descritos vienen con largas dcadas de desarrollo. Uno de los ltimos algoritmos que ha sido ampliamente difundido en
unirse a esta lista es el de planificacin por lotera, publicado por Carl Waldspurger y William Weihl (1994).
Bajo el esquema de la lotera, cada proceso tiene un nmero determinado
de boletos, y cada boleto le representa una oportunidad de jugar a la lotera.
Cada vez que el planificador tiene que elegir el siguiente proceso a poner en
ejecucin, elige un nmero al azar10 , y otorga el siguiente quantum al proceso
10 Si bien operar un generador de nmeros aleatorios en estricto sentido sera demasiado caro
para un proceso que se ejecuta decenas o cientos de veces por segundo, para jugar a la lotera
es suficiente emplear un generador dbil pseudoaleatorio. El artculo en que este mecanismo fue
presentado presenta la implementacin del algoritmo Park-Miller, S0 = ( A S)mod(231 1) con
A = 16807, implementado en 12 instrucciones de procesador RISC.
147
que tenga el boleto ganador. El boleto ganador no es retirado, esto es, la probabilidad de que determinado proceso sea puesto en ejecucin no vara entre
invocaciones sucesivas del planificador.
Las prioridades pueden representarse en este esquema de forma muy sencilla: un proceso al que se le quiere dar mayor prioridad simplemente tendr
ms boletos; si el proceso A tiene 20 boletos y el proceso B tiene 60, ser tres
veces ms probable que el siguiente turno toque a B que a A.
El esquema de planificacin por lotera contempla que los procesos puedan
cooperar entre s: si B estuviera esperando un resultado de A, podra transferirle sus boletos para aumentar la probabilidad de que sea puesto en ejecucin.
A pesar de su simplicidad, el esquema de planificacin por lotera resulta justo tanto a procesos cortos como a largos, y presenta una degradacin
muy suave incluso en entornos de saturacin. Claro, al derivar de un proceso aleatorio, resulta imposible presentar una comparacin de este mecanismo
abordados previamente.
4.2.8.
Esquemas hbridos
En lneas generales, los siete algoritmos presentados pueden clasificarse sobre dos discriminadores primarios: si estn pensados para emplearse en multitarea cooperativa o apropiativa, y si emplean informacin intrnseca a los procesos evaluados o no lo hacen, esto es, si un proceso es tratado de distinta
forma dependiendo de su historial de ejecucin.
Cuadro 4.1: Caracterizacin de los mecanismos de planificacin a corto plazo
Cooperativa
Preventiva
No considera
intrnseca
Primero llegado
primero servido
(FCFS)
Ronda (RR)
Lotera
Considera
intrnseca
Proceso ms
corto (SPN),
Proceso ms
penalizado (HPRN)
Proceso ms corto
apropiativo (PSPN),
Retroalimentacin (FB),
Ronda egosta (SRR)
Ahora bien, estas caractersticas primarias pueden ser empleadas en conjunto, empleando diferentes algoritmos a diferentes niveles, o cambindolos
segn el patrn de uso del sistema, aprovechando de mejor manera sus bondades y logrando evitar sus deficiencias. A continuacin, algunos ejemplos de
esquemas hbridos.
148
149
Peor servicio a continuacin (WSN, Worst Service Next). Es una generalizacin sobre varios de los mecanismos mencionados; su principal diferencia respecto a HPRN es que no slo se considera penalizacin el tiempo
que ha pasado esperando en la cola, sino que se considera el nmero de
veces que ha sido interrumpido por el temporizador o su prioridad externa, y se considera (puede ser a favor o en contra) el tiempo que ha tenido
que esperar por E/S u otros recursos. El proceso que ha sufrido del peor
servicio es seleccionado para su ejecucin, y si varios empatan, se elige
uno en ronda.
La principal desventaja de WSN es que, al considerar tantos factores, el
tiempo requerido por un lado para recopilar todos estos datos, y por otro
lado calcular el peso que darn a cada uno de los procesos implicados,
puede impactar en el tiempo global de ejecucin. Es posible acudir a
WSN peridicamente (y no cada vez que el despachador es invocado)
para que reordene las colas segn criterios generales, y abanzar sobre
dichas colas con algoritmos ms simples, aunque esto reduce la velocidad de reaccin ante cambios de comportamiento.
Algunas versiones histricas de Unix manejaban un esquema en que la
prioridad especificada por el usuario11 era matizada y re-evaluada en el
transcurso de su ejecucin.
Peridicamente, para cada proceso se calcula una prioridad interna, que
depende de la prioridad externa (especificada por el usuario) y el tiempo consumido recientemente por el proceso. Conforme el proceso recibe
mayor tiempo de procesador, esta ltima cantidad decrece, y aumenta
conforme el proceso espera (sea por decisin del despachador o por estar
en alguna espera).
Esta prioridad interna depende tambin del tamao de la lista de procesos listos para su ejecucin: entre ms procesos haya pendientes, ms
fuerte ser la modificacin que efecte.
El despachador ejecutar al proceso que tenga una mayor prioridad despus de realizar estos pesos, decidiendo por ronda en caso de haber empates. Claro est, este algoritmo resulta sensiblemente ms caro computacionalmente, aunque ms justo, que aquellos sobre los cuales construye.
4.2.9.
Resumiendo
150
Figura 4.15: Proporcin de penalizacin registrada por cada proceso contra el porcentaje del tiempo que ste requiere (Finkel, p.33)
151
Figura 4.16: Tiempo perdido contra porcentaje de tiempo requerido por proceso
(Finkel, p.34)
parte, qu tan corto tiene sentido que sea un quantum? Con el hardware y las
estructuras requeridas por los sistemas operativos de uso general disponibles
hoy en da, un cambio de contexto requiere del orden de 10 microsegundos
(Silberschatz, p.187), por lo que incluso con el quantum de 10ms (el ms corto
que manejan tanto Linux como Windows), representa apenas la milsima parte
del tiempo efectivo de proceso.
Una estrategia empleada por Control Data Corporation para la CDC6600
(comercializada a partir de 1964, y diseada por Seymour Cray) fue emplear
hardware especializado que permitiera efectivamente compartir el procesador:
un slo procesador tena 10 juegos de registros, permitindole alternar entre 10
procesos con un quantum efectivo igual a la velocidad del reloj. A cada paso
del reloj, el procesador cambiaba el juego de registros. De este modo, un slo
procesador de muy alta velocidad para su momento (1 MHz) apareca ante las
aplicaciones como 10 procesadores efectivos, cada uno de 100 KHz, reduciendo los costos al implementar slamente una vez cada una de las unidades funcionales. Puede verse una evolucin de esta idea retomada hacia mediados de
la dcada del 2000 en los procesadores que manejan hilos de ejecucin.12 .
Esta arquitectura permita tener multitarea real sin tener que realizar cambios de contexto, sin embargo, al tener un nivel de concurrencia fijo establecido
12 Aunque la arquitecura de la CDC6600 era plenamente superescalar, a diferencia de los procesadores Hyperthreading, que ser abordada brevemente en la seccin 4.4.4, en que para que dos
instrucciones se ejecuten simultneamente deben ser de naturalezas distintas, no requiriendo ambas de la misma unidad funcional del CPU. El procesador de la CDC6600 no manejaba pipelines, sino
que cada ejecucin empleaba al CPU completo
152
Figura 4.17: Tres modelos de mapeo de hilos a procesos. (Imgenes: Beth Plale; ver
Otros recursos)
4.3.
Planificacin de hilos
Ahora bien, tras centrar toda la presente discusin en los procesos, cmo
caben los hilos en este panorama? Depende de cmo stos son mapeados a procesos a ojos del planificador.
Como fue expuesto en la seccin 3.2.1, hay dos clases principales de hilo:
los hilos de usuario o hilos verdes, que son completamente gestionados dentro
del proceso y sin ayuda del sistema operativo, y los hilos de ncleo o hilos de
kernel, que s son gestionados por el sistema operativo como si fueran procesos.
Partiendo de esto, existen tres modelos principales de mapeo:
Muchos a uno Muchos hilos son agrupados en un slo proceso. Los hilos
verdes entran en este supuesto: para el sistema operativo, hay un slo
proceso; mientras tiene la ejecucin, ste se encarga de repartir el tiempo
entre sus hilos.
Bajo este modelo, si bien el cdigo escrito es ms portable entre diferentes
sistemas operativos, los hilos no aprovechan realmente al paralelismo, y
todos los hilos pueden tener que bloquearse cuando uno slo de ellos
realiza una llamada bloqueante al sistema.
La figura 4.17(a) ilustra este modelo.
Uno a uno Cada hilo es ejecutado como un proceso ligero (lightweight process o
LWP); podra dar la impresin de que este esquema desperdicia la principal caracterstica de los hilos, que es una mayor sencillez y rapidez de
inicializacin que los procesos, sin embargo, la informacin de estado
requerida para crear un LWP es mucho menor que la de un proceso regular, y mantiene como ventaja que los hilos continan compartiendo su
memoria, descriptores de archivos y dems estructuras.
Este mecanismo permite a los hilos aprovechar las ventajas del paralelismo, pudiendo ejecutarse cada hilo en un procesador distinto, y como ni-
153
ca condicin para su existencia, el sistema operativo debe poder implementar los LWP.
La esquematizacin de este modelo puede apreciarse en la figura 4.17(b).
Muchos a muchos Este mecanismo permite que existan hilos de ambos modelos: permite la existencia de hilos unidos (bound threads), en que cada hilo
corresponde a un (y slo un) LWP, y de hilos no unidos (unbound threads),
de los cuales uno o ms estarn mapeados a cada LWP.
El esquema muchos a muchos proporciona las principales caractersticas
de ambos esquemas; en caso de ejecutarse en un sistema que no soporte
ms que el modelo uno a muchos, el sistema puede caer en ste como modo
degradado.
Este modelo se presenta en la figura 4.17(c).
No se detalla en el presente texto respecto a los primeros cada marco
de desarrollo o mquina virtual (ver seccin B.2.1) que emplee hilos de usuario
actuar cual sistema operativo ante ellos, probablemente con alguno de los
mecanismos ilustrados anteriormente.
4.3.1.
154
La definicin de pthreads apunta a que, si bien el programador puede solicitar que sus hilos sean tratados bajo cualquiera de estos procesos, una implementacin especfica puede implementar ambos o slo uno de los mbitos. Un
proceso que solicite que sus hilos sean programados bajo un mbito no implementado sern ejecutados bajo el otro, notificando del error (pero permitiendo
continuar con la operacin).
Las implementaciones de pthreads tanto en Windows como en Linux slo
contemplan SCS.
Respecto a los otros aspectos mencionados en este captulo, la especificacin pthreads incluye funciones por medio de las cuales el programador
puede solicitar al ncleo la prioridad de cada uno de los hilos por separado
(pthread_setschedprio) e incluso solicitar el empleo de determinado algoritmo de planificacin (sched_setscheduler).
4.4.
Planificacin de multiprocesadores
Hasta este punto, el enfoque de este captulo se ha concentrado en la planificacin asumiendo un slo procesador. Del mismo modo que lo que se ha
visto hasta este momento, no hay una sla estrategia que pueda ser vista como
superior a las dems en todos los casos.
Para trabajar en multiprocesadores, puede mantenerse una sla lista de procesos e ir despachndolos a cada uno de los procesadores como unidades de
ejecucin equivalentes e idnticas, o pueden mantenerse listas separadas de
procesos. A continuacin se presentan algunos argumentos respecto a estos
enfoques.
4.4.1.
Afinidad a procesador
155
erativo debe conocer cmo estn estructurados los diversos procesadores que
tiene a su disposicin, y buscar realizar las migraciones ms baratas, aquellas
que tengan lugar entre los procesadores ms cercanos.
Resulta obvio por esto que un proceso que fue ejecutado en determinado
procesador vuelva a ser ejecutado en el mismo, esto es, el proceso tiene afinidad
por cierto procesador. Un proceso que preferentemente ser ejecutado en determinado procesador se dice que tiene afinidad suave por ese procesador, pero
determinados patrones de carga (por ejemplo, una mucho mayor cantidad de
procesos afines a cierto procesador que a otro, saturando su cola de procesos
listos, mientras que el segundo procesador tiene tiempo disponible) pueden
llevar a que el despachador decida activarlo en otro procesador.
Por otro lado, algunos sistemas operativos ofrecen la posibilidad de declarar
afinidad dura, con lo cual se garantiza a un proceso que siempre ser ejecutado
en un procesador, o en un conjunto de procesadores.
Un entorno NUMA, por ejemplo, funcionar mucho mejor si el sistema que
lo emplea maneja tanto un esquema de afinidad dura como algoritmos de asignacin de memoria que le aseguren que un proceso siempre se ejecutar en el
procesador que tenga mejor acceso a sus datos.
4.4.2.
Balanceo de cargas
En un sistema multiprocesador, la situacin ideal es que todos los procesadores estn despachando trabajos al 100 % de su capacidad. Sin embargo,
ante una definicin tan rgida, la realidad es que siempre habr uno o ms
procesadores con menos del 100 % de carga, o uno o ms procesadores con
procesos encolados y a la espera, o incluso ambas situaciones.
La divergencia entre la carga de cada uno de los procesadores debe ser lo
ms pequea posible. Para lograr esto, se pueden emplear esquemas de balanceo de cargas: algoritmos que analicen el estado de las colas de procesos y,
de ser el caso, transfieran procesos entre las colas para homogeneizarlas. Claro
est, el balanceo de cargas puede actuar precisamente en sentido contrario de
la afinidad al procesador, y efectivamente puede reubicar a los procesos con
afinidad suave.
Hay dos estrategias primarias de balanceo: por un lado, la migracin activa
o migracin por empuje (push migration) consiste en una tarea que ejecuta como
parte del ncleo y peridicamente revisa el estado de los procesadores, y en
caso de encontrar un desbalance mayor a cierto umbral, empuja a uno o ms
procesos de la cola del procesador ms ocupado a la del procesador ms libre.
Linux ejecuta este algoritmo cada 200 milisegundos.
Por otro lado, est la migracin pasiva o migracin por jaln (pull migration). Cuando algn procesador queda sin tareas pendientes, ejecuta al proceso
especial desocupado (idle). Ahora, el proceso desocupado no significa que el procesador detenga su actividad ese tiempo puede utilizarse para ejecutar tareas
156
del ncleo. Una de esas tareas puede consistir en averiguar si hay procesos en
espera en algn otro de los procesadores, y de ser as, jalarlo a la cola de este
procesador.
Ambos mecanismos pueden emplearse y normalmente lo hacen en el
mismo sistema. Los principales sistemas operativos modernos emplean casi
siempre ambos mecanismos.
Como sea, debe mantenerse en mente que todo balanceo de cargas que
se haga entre los procesadores conllevar una penalizacin en trminos de
afinidad al CPU.
4.4.3.
4.4.4.
157
Figura 4.18: Descomposicin de una instruccin en sus cinco pasos clsicos para
organizarse en un pipeline
158
La planificacin de los hilos hardware sale del mbito del presente material, y este tema se presenta nicamente para aclarar un concepto que probablemente confunda al alumno por su similitud; los hilos en hardware implican cuestiones de complejidad tal como el ordenamiento especfico de las
instrucciones, prediccin de ramas de ejecucin, e incluso asuntos relativos a
la seguridad, dado que se han presentado goteos que permiten a un proceso
ejecutando en un hilo espiar el estado del procesador correspondiente a otro
de los hilos. Para abundar al respecto, el mbito adecuado podra ser un texto
orientado a la construccin de compiladores (ordenamiento de instrucciones,
aprovechamiento del paralelismo), o uno de arquitectura de sistemas (estudio
del pipeline, aspectos del hardware).
Esta estrategia guarda gran similitud, y no puede evitar hacerse el paralelo,
con la comparticin de procesador empleada por la CDC6600, presentada en la
seccin 4.2.9.
4.5.
Tiempo real
Todos los esquemas de manejo de tiempo hasta este momento se han enfocado a repartir el tiempo disponible entre todos los procesos que requieren
atencin. Es necesario tambin abordar a los procesos que requieren garantas
de tiempo: procesos que para poder ejecutarse deben garantizar el haber tenido
determinado tiempo de proceso antes de un tiempo lmite. Los procesos con
estas caractersticas se conocen como de tiempo real.
Hay ejemplos de procesos que requieren este tipo de planificacin a todo
nivel; los ejemplos ms comunes son los controladores de dispositivos y los
recodificadores o reproductores de medios (audio, video). La lgica general es
la misma:
Para agendarse como un proceso con requisitos de tiempo real, ste debe
declarar sus requisitos de tiempo (formalmente, efectuar su reserva de recursos)
al iniciar su ejecucin o en el transcurso de la misma. Claro est, siendo que los
159
procesos de tiempo real obtienen una prioridad mucho mayor a otros, normalmente se requerir al iniciar el proceso que ste declare que durante parte de su
ejecucin trabajar con restricciones de tiempo real.
4.5.1.
Supngase que un dispositivo genera peridicamente determinada cantidad de informacin y la va colocando en un rea determinada de memoria
compartida (en un buffer). Al inicializarse, su controlador declarar al sistema
operativo cunto tiempo de ejecucin le tomar recoger y procesar dicha informacin, liberando el buffer para el siguiente ciclo de escritura del dispositivo, y
la frecuencia con que dicha operacin tiene que ocurrir.
En un sistema capaz de operar con garantas de tiempo real, si el sistema operativo puede garantizar que en ese intervalo le otorgar al proceso en cuestin
suficiente tiempo para procesar esta informacin, el proceso se ejecuta; en caso contrario, recibe un error antes de que esto ocurra por medio del cual podr
alertar al usuario.
Los sistemas en que el tiempo mximo es garantizable son conocidos como
de tiempo real duro.
La necesidad de atencin en tiempo real puede manejarse peridica (por
ejemplo, requiero del procesador por 30ms cada segundo), o aperidica, por ocurrencia nica (necesito que este proceso, que tomar 600ms, termine de ejecutarse en
menos de 2s).
Realizar una reserva de recursos requiere que el planificador sepa con
certeza cunto tiempo toma realizar las tareas de sistema que ocurrirn en
el periodo en cuestin. Cuando entran en juego algunos componentes de los
sistemas de propsito general que tienen una latencia con variaciones impredecibles (como el almacenamiento en disco o la memoria virtual) se vuelve
imposible mantener las garantas de tiempo ofrecidas. Por esta razn, en un
sistema operativo de propsito general empleando hardware estndar no es
posible implementar tiempo real duro.
Para solventar necesidades como las expresadas en sistemas de uso general,
el tiempo real suave sigue requiriendo que los procesos crticos reciban un trato
prioritario por encima de los processos comunes; agendar a un proceso con
esta prioridad puede llevar a la inanicin de procesos de menor prioridad y
un comportamiento que bajo ciertas mtricas resultara injusto. Un esquema de
tiempo real suave puede implementarse a travs de un esquema similar al de
la retroalimentacin multinivel, con las siguientes particularidades:
La cola de tiempo real recibe prioridad sobre todas las dems colas
La prioridad de un proceso de tiempo real no se degrada conforme se ejecuta repetidamente
160
Casi todos los sistemas operativos en uso amplio hoy en da ofrecen facilidades bsicas de tiempo real suave.
4.5.2.
Para que la implementacin de tiempo real suave sea apta para estos requisitos es necesario modificar el comportamiento del sistema operativo. Cuando
un proceso de usuario hace una llamada al sistema, o cuando una interrupcin
corta el flujo de ejecucin, hace falta que el sistema procese completa la rutina que da servicio a dicha solicitud antes de que contine operando. Se dice
entonces que el sistema operativo no es prevenible o no es interrumpible.
Para lograr que el ncleo pueda ser interrumpido para dar el control de
vuelta a procesos de usuario, un enfoque fue el poner puntos de interrupcin en
los puntos de las funciones del sistema donde fuera seguro, tras asegurarse que
las estructuras estaban en un estado estable. Esto, sin embargo, no modifica en
mucho la situacin porque estos puntos son relativamente pocos, y es muy
difcil reestructurar su lgica para permitir puntos de prevencin adicionales.
Otro enfoque es hacer al ncleo entero completamente interrumpible, asegurndose de que, a lo largo de todo su cdigo, todas las modificaciones a
estructuras internas estn protegidas por mecanismos de sincronizacin, como
los estudiados en la seccin 3.3. Este mtodo ralentiza varios procesos del ncleo, pero es mucho ms flexible, y ha sido adoptado por los diversos sistemas
operativos. Tiene la ventaja adicional de que permite que haya hilos del ncleo
ejecutando de forma concurrente en todos los procesadores del sistema.
4.5.3.
Inversin de prioridades
Un efecto colateral de que las estructuras del ncleo estn protegidas por
mecanismos de sincronizacin es que puede presentarse la inversin de prioridades. Esto es:
Un proceso A de baja prioridad hace una llamada al sistema, y es interrumpido a la mitad de dicha llamada
Un proceso B de prioridad tiempo real hace una segunda llamada al sistema, que requiere de la misma estructura que la que tiene bloqueada
A
4.6. EJERCICIOS
161
4.6.
Ejercicios
4.6.1.
Preguntas de autoevaluacin
Llegada
0
2
4
4
6
6
t
8
13
3
6
8
3
162
4.6.2.
4.6. EJERCICIOS
163
4.6.3.
Lecturas relacionadas
164
WikiBooks.org (2007-2013)
Thread scheduling and synchronization
http://www.cs.indiana.edu/classes/b534-plal/ClassNotes/sched-synch-details4.
pdf
Mark Russinovich, David A. Solomon y Alex Ionescu (2012); por Microsoft Press. El captulo 5 aborda a profundidad los temas de hilos y
procesos bajo Windows, y est disponible como ejemplo del libro para su
descarga en la pgina referida.
Optimizing preemption
https://lwn.net/Articles/563185/
Captulo 5
Administracin de memoria
5.1.
El nico espacio de almacenamiento que el procesador puede utilizar directamente, ms all de los registros (que si bien le son internos y sumamente
rpidos, son de capacidad demasiado limitada) es la memoria fsica. Todas
las arquitecturas de procesador tienen instrucciones para interactuar con la
memoria, pero ninguna lo tiene para hacerlo con medios persistentes de almacenamiento, como las unidades de disco. Cabe mencionar que cuando se encuentre en un texto referencia al almacenamiento primario siempre se referir a
la memoria, mientras que el almacenamiento secundario se refiere a los discos u
otros medios de almacenamiento persistente.
Todos los programas a ejecutar deben cargarse a la memoria del sistema
antes de ser utilizados. En este captulo se mostrar cmo el sistema operativo
administra la memoria para permitir que varios procesos la compartan esta tarea debe preverse desde el proceso de compilacin de los programas (en
particular, la fase de ligado). Hoy en da, adems, casi todos los sistemas operativos emplean implementaciones que requieren de hardware especializado
la Unidad de Manejo de Memoria (MMU). Se describir cmo se manejaban los
sistemas multitarea antes de la universalizacin de las MMU, y qu rol juegan
hoy en da.
En esta primer seccin se presentarn algunos conceptos base que se emplearn en las secciones subsecuentes.
5.1.1.
Espacio de direccionamiento
166
5.1.2.
5.1.3.
La memoria cach
168
Figura 5.1: Espacio de direcciones vlidas para el proceso 3 definido por un registro
base y un registro lmite
Conforme el procesador avanza en la ejecucin de las instrucciones (aumentando el valor almacenado en el registro de conteo de instruccin), se producen accesos a memoria. Por un lado, tiene que buscar en memoria la siguiente instruccin a ejecutar. Por otro lado, estas instrucciones pueden requerirle
uno o ms operadores adicionales que deban ser ledos de la memoria. Por ltimo, la instruccin puede requerir guardar su resultado en cierta direccin de
memoria.
Hace aos esto no era un problema la velocidad del procesador estaba
bsicamente sincronizada con la del manejador de memoria, y el flujo poda
mantenerse bsicamente estable. Pero conforme los procesadores se fueron haciendo ms rpidos, y conforme se ha popularizado el procesamiento en paralelo, la tecnologa de la memoria no ha progresado a la misma velocidad. La
memoria de alta velocidad es demasiado cara, e incluso las distancias de unos pocos centmetros se convierten en obstculos insalvables por la velocidad
mxima de los electrones viajando por pistas conductoras.
Cuando el procesador solicita el contenido de una direccin de memoria
y esta no est an disponible, tiene que detener su ejecucin (stall) hasta que los
datos estn disponibles. El CPU no puede, a diferencia del sistema operativo,
congelar todo y guardar el estado para atender a otro proceso: para el procesador, la lista de instrucciones a ejecutar es estrictamente secuencial, y todo
tiempo que requiere esperar a una transferencia de datos es tiempo perdido.
La respuesta para reducir esa espera es la memoria cach. Esta es una memoria de alta velocidad, situada entre la memoria principal y el procesador propiamente, que guarda copias de las pginas que van siendo accesadas, partiendo
del principio de la localidad de referencia:
Figura 5.2: Patrones de acceso a memoria, demostrando la localidad espacial / temporal (Silberschatz, p.350)
170
5.1.4.
5.1.5.
Resolucin de direcciones
Ahora bien, en los sistemas actuales, los procesos requieren coexistir con
otros, para lo cual las direcciones indicadas en el texto del programa pueden
requerir ser traducidas al lugar relativo al sitio de inicio del proceso en memoria
esto es, las direcciones son resueltas o traducidas. Existen diferentes estrategias
de resolucin, que se pueden clasificar a grandes rasgos5 en:
En tiempo de compilacin El texto del programa tiene la direccin absoluta de
las variables y funciones. Esto era muy comn en las computadoras previas al multiprocesamiento. En la arquitectura compatible con PC, el formato ejecutable .COM es un volcado de memoria directo de un archivo
objeto con las direcciones indicadas de forma absoluta. Esto puede verse
hoy principalmente en sistemas embebidos o de funcin especfica.
En tiempo de carga Al cargarse a memoria el programa y antes de iniciar su
ejecucin, el cargador (componente del sistema operativo) actualiza las
referencias a memoria dentro del texto para que apunten al lugar correcto
claro est, esto depende de que el compilador indique dnde estn
todas las referencias a variables y funciones.
En tiempo de ejecucin El programa nunca hace referencia a una ubicacin
absoluta de memoria, sino que lo hace siempre relativo a una base y un
desplazamiento (offset). Esto permite que el proceso sea incluso reubicado
en la memoria mientras est siendo ejecutado sin tener que sufrir cambios, pero requiere de hardware especfico (como una MMU).
Esto es, los nombres simblicos (por ejemplo, una variable llamada contador)
para ser traducidos ya sea a ubicaciones en la memoria, pueden resolverse en
tiempo de compilacin (y quedar plasmada en el programa en disco con una
5 Esta explicacin simplifica muchos detalles; para el lector interesado en profundizar en este
tema, se recomienda el libro Linkers and Loaders (Ligadores y cargadores) de John R. Levine (1999).
El libro est disponible en lnea desde el sitio Web del autor, http://www.iecc.com/linker/
172
5.2.
En los sistemas de ejecucin en lotes, as como en las primeras computadoras personales, slo un programa se ejecutaba a la vez. Por lo que, ms all de la
carga del programa y la satisfaccin de alguna eventual llamada al sistema solicitando recursos, el sistema operativo no tena que ocuparse de la asignacin
173
de memoria.
Al nacer los primeros sistemas operativos multitarea, se hizo necesario resolver cmo asignar el espacio en memoria a diferentes procesos.
5.2.1.
Particin de la memoria
174
Mejor ajuste El sistema busca entre todos los bloques disponibles cul es el
que mejor se ajusta al tamao requerido por el nuevo proceso. Esto implica la revisin completa de la lista de bloques, pero permite que los
bloques remanentes, una vez que se ubic al nuevo proceso, sean tan pequeos como sea posible (esto es, que haya de hecho un mejor ajuste).
Peor ajuste El sistema busca cul es el bloque ms grande disponible, y se lo
asigna al nuevo proceso. Empleando una estrucura de datos como un
montculo, esta operacin puede ser incluso ms rpida que la de primer
espacio. Con este mecanismo se busca que los bloques que queden despus de otorgarlos a un proceso sean tan grandes como sea posible, de
cierto modo balanceando su tamao.
La fragmentacin externa se produce cuando hay muchos bloques libres entre bloques asignados a procesos; la fragmentacin interna se refiere a la cantidad de memoria dentro de un bloque que nunca se usar por ejemplo, si
el sistema operativo maneja bloques de 512 bytes y un proceso requiere slo
768 bytes para su ejecucin, el sistema le entregar dos bloques (1024 bytes),
con lo cual desperdicia 256 bytes. En el peor de los casos, con un bloque de n
bytes, un proceso podra solicitar kn + 1 bytes de memoria, desperdiciando por
fragmentacin interna n 1 bytes.
Segn anlisis estadsticos (Silberschatz, p.289), por cada N bloques asignados, se perdern del orden de 0.5N bloques por fragmentacin interna y externa.
Compactacin
Un problema importante que va surgiendo como resultado de esta fragmentacin es que el espacio total libre de memoria puede ser mucho mayor
que lo que requiere un nuevo proceso, pero al estar fragmentada en muchos
bloques, ste no encontrar una particin contigua donde ser cargado.
Si los procesos emplean resolucin de direcciones en tiempo de ejecucin, cuando el sistema operativo comience a detectar un alto ndice de fragmentacin, puede lanzar una operacin de compresin o compactacin. Esta operacin consiste en mover los contenidos en memoria de los bloques asignados
para que ocupen espacios contiguos, permitiendo unificar varios bloques libres
contiguos en uno solo.
La compactacin tiene un costo alto involucra mover prcticamente la
totalidad de la memoria (probablemente ms de una vez por bloque).
175
176
5.3.
Segmentacin
5.3. SEGMENTACIN
177
5.3.1.
Permisos
Una de las principales ventajas del uso de segmentacin consiste en permitir que cada uno de los segmentos tenga un distinto juego de permisos para
el proceso en cuestin: el sistema operativo puede indicar, por ejemplo, que el
segmento de texto (el cdigo del programa) sea de lectura y ejecucin, mientras
que las secciones de datos, libres y pila (donde se almacena y trabaja la informacin misma del programa) sern de lectura y escritura, pero la ejecucin
estar prohibida7 .
De este modo, se puede evitar que un error en la programacin resulte en
que datos proporcionados por el usuario o por el entorno modifiquen el cdigo que est siendo ejecutado.8 Es ms, dado que el acceso de ejecucin est
7 Si bien este es el manejo clsico, no es una regla inquebrantable: el cdigo automodificable conlleva importantes riesgos de seguridad, pero bajo ciertos supuestos, el sistema debe permitir su ejecucin. Adems, muchos lenguajes de programacin permiten la metaprogramacin, que requiere la
ejecucin de cdigo construdo en tiempo de ejecucin.
8 Sin embargo, incluso bajo este esquema, dado que la pila de llamadas (stack) debe mantenerse
como escribible, es comn encontrar ataques que permiten modificar la direccin de retorno de una
subrutina, como ser descrito en la seccin 5.6.1.
178
limitado a slo los segmentos cargados del disco por el sistema operativo, un
atacante no podr introducir cdigo ejecutable tan fcilmente tendra que
cargarlo como un segmento adicional con los permisos correspondientes.
La segmentacin tambin permite distinguir niveles de acceso a la memoria: para que un proceso pueda efectuar llamadas al sistema, debe tener acceso
a determinadas estructuras compartidas del ncleo. Claro est, al ser memoria privilegiada, su acceso requiere que el procesador est ejecutando en modo
supervisor.
5.3.2.
Intercambio parcial
5.3. SEGMENTACIN
179
Por otro lado, si la biblioteca en cuestin reside en disco (antes de ser cargada) como una imagen directa de su representacin en memoria, al sistema
operativo le bastar identificar el archivo en cuestin al cargar el proceso; no
hace falta siquiera cargarlo en la memoria principal y guardarlo al rea de intercambio, puede quedar referido directamente al espacio en disco en que reside
el archivo.
Claro est, el acceso a disco sigue siendo una fuerte penalizacin cada vez
que un segmento tiene que ser cargado del disco (sea del sistema de archivos
o del espacio de intercambio), pero este mecanismo reduce dicha penalizacin,
haciendo ms atractiva la flexibilidad del intercambio por segmentos.
5.3.3.
Ejemplificando
A modo de ejemplo, y conjuntando los conceptos presentados en esta seccin, si un proceso tuviera la siguiente tabla de segmentos:
Segmento
0
1
2
3
4
Inicio
15208
1400
964
10000
Tamao
160
100
96
184
320
Permisos
RWX
R
RX
W
RWX
Presente
s
s
s
no
s
Tipo de
acceso
R
X
W
R
W
R
X
X
Direccin
fsica
15308
1048
Atrapada: Violacin de seguridad
Atrapada: Desplazamiento fuera de rango
Atrapada: Segmento faltante
Atrapada: Segmento faltante;
violacin de seguridad
10128
Atrapada: Segmento invalido
180
5.4.
Paginacin
5.4. PAGINACIN
181
182
Figura 5.9: Ejemplo (minsculo) de paginacin, con un espacio de direccionamiento de 32 bytes y pginas de 4 bytes
5.4.1.
Tamao de la pgina
5.4. PAGINACIN
183
5.4.2.
es 222 bytes;
232
222
= 210 = 1024
=
= 1048576, cada entrada con un mnimo de 20 bits para la pgina y 20 bits para el
marco. La tabla de pginas misma ocupara 1280 pginas!
10 232
212
220
184
5.4. PAGINACIN
185
186
Figura 5.11: Paginacin en dos niveles: una tabla externa de 10 bits, tablas intermedias de 10 bits, y marcos de 12 bits (esquema comn para procesadores de 32
bits)
destino).
Otra alternativa es el emplear funciones digestoras (hash functions)14 para mapear cada una de las pginas a un espacio muestral mucho ms pequeo. Cada
pgina es mapeada a una lista de correspondencias simples15 .
Un esquema basado en funciones digestoras ofrece caractersticas muy deseables: el tamao de la tabla de pginas puede variar segn crece el uso de
memoria de un proceso (aunque esto requiera recalcular la tabla con diferentes
parmetros) y el nmero de accesos a memoria en espacios tan grandes como
el de un procesador de 64 bits se mantiene mucho ms tratable. Sin embargo,
por la alta frecuencia de accesos a esta tabla, debe elegirse un algoritmo digestor muy gil para evitar que el tiempo que tome calcular la posicin en la
tabla resulte significativo frente a las alternativas.
14 Una funcin digestora puede definirse como H : U M, una funcin que mapea o proyecta
al conjunto U en un conjunto M mucho menor; una caracterstica muy deseable de toda funcin
hash es que la distribucin resultante en M resulte homogenea y tan poco dependiente de la secuencialidad de la entrada como sea posible.
15 A una lista y no a un valor nico dado que una funcin digestora es necesariamente proclive
a presentar colisiones; el sistema debe poder resolver dichas colisiones sin prdida de informacin.
5.4. PAGINACIN
5.4.3.
187
Memoria compartida
Figura 5.12: Uso de memoria compartida: tres procesos comparten la memoria ocupada por el texto del programa (azul), difieren slo en los datos.
Claro est, para ofrecer este modelo, el sistema operativo debe garantizar
que las pginas correspondientes a las secciones de texto (el cdigo del programa) sean de slo lectura.
Un programa que est programado y compilado de forma que permita que
todo su cdigo sea de slo lectura posibilita que diversos procesos entren a su
espacio en memoria sin tener que sincronizarse con otros procesos que lo estn
empleando.
16 Algunos ejemplos sobresalientes podran ser la libc o glibc, que proporciona las funcinoes
estndar del lenguaje C y es, por tanto, requerida por casi todos los programas del sistema; los
diferentes entornos grficos (en los Unixes modernos, los principales son Qt y Gtk); bibliotecas
para el manejo de cifrado (openssl), compresin (zlib), imgenes (libpng, libjpeg), etc.
188
/* (...) */
int pid;
/* (...) */
pid = fork();
if (pid == 0) {
/* Soy el proceso hijo */
/* (...) */
} else if (pid < 0) {
/* Ocurri un error, no se cre un proceso hijo */
} else {
/* Soy el proceso padre */
/* La variable pid tiene el PID del proceso hijo */
/* (...) */
}
189
Figura 5.13: Memoria de dos procesos en un sistema que implementa copiar al escribir.
pginas compartidas como slo lectura, con lo cual cuando uno de los dos procesos intente modificar la informacin de alguna pgina se generar un fallo.
El sistema operativo, al notar que esto ocurre sobre un espacio CoW, en vez
de responder al fallo terminando al proceso, copiar slo la pgina en la cual
se encuentra la direccin de memoria que caus el fallo, y esta vez marcar la
pgina como lectura y escritura.
Incluso cuando se ejecutan nuevos programas a travs de execve(), es
posible que una buena parte de la memoria se mantenga compartida, por ejemplo, al referirse a copias de bibliotecas de sistema.
5.5.
Memoria virtual
Varios de los aspectos mencionados en la seccin 5.4 (Paginacin) van conformando a lo que se conoce como memoria virtual: en un sistema que emplea
paginacin, un proceso no conoce su direccin en memoria relativa a otros procesos, sino que trabajan con una idealizacin de la memoria, en la cual ocupan el
190
Figura 5.14: Esquema general de la memoria, incorporando espacio en almacenamiento secundario, representando la memoria virtual
Es importante apuntar que la memoria virtual es gestionada de forma automtica y transparente por el sistema operativo. No se hablara de memoria
virtual, por ejemplo, si un proceso pide explcitamente intercambiar determinadas pginas.
Puesto de otra manera: del mismo modo que la segmentacin (seccin 5.3)
permiti hacer mucho ms cmodo y til al intercambio (5.2.1) a travs del intercambio parcial (5.3.2), permitiendo que continuara la ejecucin del proceso
incluso con ciertos segmentos intercambiados (swappeados) a disco, la memoria
virtual lo hace an ms conveniente al aumentar la granularidad del intercam-
191
5.5.1.
192
193
5.5.2.
Rendimiento
La paginacin sobre demanda puede impactar fuertemente el rendimiento de un proceso -se ha explicado ya que un acceso a disco es varios miles de
veces ms lento que el acceso a memoria. Es posible calcular el tiempo de acceso efectivo a memoria (te ) a partir de la probabilidad que en un proceso se
presente un fallo de pgina (0 p 1), conociendo el tiempo de acceso a
memoria (t a ) y el tiempo que toma atender a un fallo de pgina (t f ):
te = (1 p)t a + pt f
Ahora bien, dado que t a ronda hoy en da entre los 10 y 200ns, mientras que
t f est ms bien cerca de los 8ms (la latencia tpica de un disco duro es de 3ms,
el tiempo de posicionamiento de cabeza de 5ms, y el tiempo de transferencia
es de 0.05ms), para propsitos prcticos se puede ignorar a t a . Con los valores
presentados, seleccionando el mayor de los t a presentados, si slo un acceso a
1
):
memoria de cada 1000 ocasiona un fallo de pgina (esto es, p = 1000
t e = (1
1
1
) 200ns +
8, 000, 000ns
1000
1000
194
5.5.3.
Reemplazo de pginas
195
196
Para los algoritmos que se presentan a continuacin, se asumir una memoria con tres marcos, y con la siguiente cadena de referencia:
7, 0, 1, 2, 0, 3, 0, 4, 2, 3, 0, 3, 2, 1, 2, 0, 1, 7, 0, 1
197
La principal ventaja de este algoritmo es, como ya se ha mencionado, la simplicidad, tanto para programarlo como para comprenderlo. Su implementacin
puede ser tan simple como una lista ligada circular, cada elemento que va recibiendo se agrega en el ltimo elemento de la lista, y se empuja el apuntador para convertirlo en la cabeza. Su desventaja, claro est, es que no toma
en cuenta a la historia de las ltimas solicitudes, por lo que puede causar un
bajo rendimiento. Todas las pginas tienen la misma probabilidad de ser reemplazadas, sin importar su frecuencia de uso.
Con las condiciones aqu presentadas, un esquema FIFO causar 15 fallos
de pgina en un total de 20 accesos requeridos.
El algoritmo FIFO es vulnerable a la anomala de Belady. La figura 5.16(b)
ilustra este fenmeno al pasar de 3 a 4 marcos.
La prevalencia de cadenas que desencadenan la anomala de Belady fue
uno de los factores principales que llevaron al diseo de nuevos algoritmos de
reemplazo de pginas.
Reemplazo de pginas ptimo (OPT, MIN)
Un segundo algoritmo, de inters puramente terico, fue propuesto, y es
tpicamente conocido como OPT o MIN. Bajo este algoritmo, el enunciado ser
elegir como pgina vctima a aquella pgina que no vaya a ser utilizada por un
tiempo mximo (o nunca ms).
Si bien este algoritmo est demostrado como ptimo o mnimo, se mantiene
como curiosidad terica porque requiere conocimiento a priori de las necesi-
198
199
mentacin podra ser agregar un contador a cada uno de los marcos, actualizarlo siempre al hacer una referenciar a dicha pgina, y elegir como vctima a la
pgina con un menor conteo. Este mecanismo tiene la desventaja de que, en
presencia de una gran cantidad de pginas, tiene que recorrerlas a todas para
buscar a la ms envejecida.
Otro mecanismo es emplear una lista doblemente ligada con dos mtodos
de acceso: lista y stack. Cada vez que se haga referencia a una pgina, se mueve
a la cabeza del stack, y cada vez que se busque a una pgina vctima, se selecciona a aquella que est en el extremo inferior del stack. Este mecanismo hace un
poco ms cara la actualizacin (pueden requerirse hasta seis modificaciones),
pero encuentra a la pgina vctima en tiempo constante.
Se ha demostrado que LRU y OPT estn libres de la anomala de Belady,
dado que, para n marcos, las pginas que estaran en memoria son un subconjunto estricto de las que estaran con n + 1 marcos.
Ms frecuentemente utilizada (MFU) / Menos frecuentemente utilizada
(LFU)
Estos dos algoritmos se basan en mantener un contador, como lo hace LRU,
pero en vez de medir el tiempo, miden la cantidad de referencias que se han
hecho a cada pgina.
MFU parte de la lgica que, si una pgina fue empleada muchas veces,
mente en software para actualizar las entradas de los marcos resultara inaceptablemente lento
200
probablemente vuelva a ser empleada muchas veces ms; LFU parte de que
una pgina que ha sido empleada pocas veces es probablemente una pgina
recin cargada, y va a ser empleada en el futuro cercano.
Estos dos algoritmos son tan caros de implementar como LRU, y su
rendimiento respecto a OPT no es tan cercana, por lo cual casi no son empleados.
Aproximaciones a LRU
Dada la complejidad que presenta la implementacin de LRU en hardware,
algunos sistemas implementan una aproximacin a ste.
Bit de referencia Esta es una aproximacin bastante comn. Consiste en que
todas las entradas de la tabla de pginas tengan un bit adicional, al que
llamaremos de referencia o de acceso. Al iniciar la ejecucin, todos los bits
de referencia estn apagados (0). Cada vez que se referencia a un marco,
su bit de referencia se enciende (esto en general lo realiza el hardware).
El sistema operativo invoca peridicamente a que se apaguen nuevamente todos los bits de referencia. En caso de presentarse un fallo de
pgina, se elige por FIFO sobre el subconjunto de marcos que no hayan
sido referenciados en el periodo actual (esto es, entre todos aquellos para
los cuales el bit de referencia sea 0).
Columna de referencia Una mejora casi trivial sobre la anterior consiste en
agregar varios bits de referencia, conformndose como una columna: en
vez de descartar su valor cada vez que transcurre el periodo determinado, el valor de la columna de referencia es desplazado a la derecha,
descartando el bit ms bajo (una actualizacin slo modifica el bit ms
significativo). Por ejemplo, con una implementacin de 4 bits, un marco que no ha sido empleado en los ltimos 4 periodos tendra el valor
0000, mientras que un marco que s ha sido referenciado los ltimos cuatro periodos tendra 1111. Un marco que fue empleado hace cuatro y tres
periodos, pero desde entonces no, tendra el 0011.
Cuando el sistema tenga que elegir a una nueva pgina vctima, lo har
de entre el conjunto que tenga un nmero ms bajo.
La parte de mantenimiento de este algoritmo es muy simple; recorrer una
serie de bits es una operacin muy sencilla. Seleccionar el nmero ms
pequeo requiere una pequea bsqueda, pero sigue resultando mucho
ms sencillo que LRU.
Segunda oportunidad (o reloj) El algoritmo de la segunda oportunidad trabaja tambin basado en un bit de referencia y un recorrido tipo FIFO. La
diferencia en este caso es que, al igual que hay eventos que encienden a
201
este bit (efectuar una referencia al marco), tambin hay eventos que lo
apagan:
se mantiene un apuntador a la prxima vctima, y cuando el sistema requiera efectuar un reemplazo, ste verificar si el marco al que apunta
tiene el bit de referencia encendido o apagado. En caso de estar apagado,
el marco es seleccionado como vctima, pero en caso de estar encendido
(indicando que fue utilizado recientemente), se le da una segunda oportunidad: el bit de referencia se apaga, el apuntador de vctima potencial
avanza una posicin, y vuelve a intentarlo.
A este algoritmo se le llama tambin de reloj porque puede implementarse
como una lista ligada circular, y el apuntador puede ser visto como una
manecilla. La manecilla avanza sobre la lista de marcos buscando uno
con el bit de referencia apagado, y apagando a todos a su paso.
En el peor caso, el algoritmo de segunda oportunidad degenera en FIFO.
Segunda oportunidad mejorada El bit de referencia puede amplairse con un
bit de modificacin, dndonos las siguientes combinaciones, en orden de
preferencia:
(0, 0) No ha sido utilizado ni modificado recientemente. Candidato ideal
para su reemplazo.
(0,1) No ha sido utilizada recientemente, pero est modificada. No es tan
buena opcin, porque es necesario escribir la pgina a disco antes
de reemplazarla, pero puede ser elegida.
(1,0) El marco est limpio, pero fue empleado recientemente, por lo que
probablemente se vuelva a requerir pronto.
(1,1) Empleada recientemente y sucia sera necesario escribir la pgina
a disco antes de reemplazar, y probablemente vuelva a ser requerida
pronto. Hay que evitar reemplazarla.
La lgica para encontrar una pgina vctima es similar a la segunda oportunidad, pero busca reducir el costo de E/S. Esto puede requerir, sin embargo, dar hasta cuatro vueltas (por cada una de las listas) para elegir la
pgina vctima.
Algoritmos con manejo de buffers
Un mecanismo que se emplea con cada vez mayor frecuencia es que el sistema no espere a enfrentarse a la necesidad de reemplazar un marco, sino que
proactivamente busque tener siempre espacio vaco en memoria. Para hacerlo,
conforme la carga lo permite, el sistema operativo busca las pginas sucias ms
proclives a ser paginadas a disco y va actualizando el disco (y marcndolas
nuevamente como limpias). De este modo, cuando tenga que traer una pgina
202
nueva del disco, siempre habr espacio donde ubicarla sin tener que esperar a
que se transfiera una para liberarla.
5.5.4.
Asignacin de marcos
203
caso de que se le permitiera solo uno, si la instruccin ubicada en 0x00A2C8 solicita la carga de 0x043F00, esta causara dos fallos: el primero, cargar al marco
la pgina 0x043, y el segundo, cargar nuevamente la pgina 0x00A, necesario
para leer la siguiente instruccin a ejecutar del programa (0x00A2CC, asumiendo palabras de 32 bits).
Algunas arquitecturas, adems, permiten referencias indirectas a memoria, esto es, la direccin de carga puede solicitar la direccin que est referenciada en
0x043F00. El procesador tendra que recuperar esta direccin, y podra encontrarse con que hace referencia a una direccin en otra pgina (por ejemplo, 0x010F80). Cada nivel de indireccin que se permite aumenta en uno el
nmero de pginas que se deben reservar como mnimo por proceso.
Algunas arquitecturas, particularmente las ms antiguas,21 , permiten que
tanto los operandos de algunas instrucciones aritmticas como su resultado
sean direcciones de memoria (y no operan estrictamente sobre los registros,
como las arquitecturas RISC). En dichas arquitecturas, el mnimo debe tambin
tener este factor en cuenta: si en una sola instruccin es posible sumar dos
direcciones de memoria y guardar el resultado en una adicional, el mnimo
a reservar es de cuatro marcos: uno para el flujo del programa, uno para el
primer operando, uno para el segundo operando, y uno para el resultado.
Esquemas de asignacin
Ahora, una vez establecido el nmero mnimo de marcos por proceso, cmo determinar el nivel deseable?
Partiendo de que el rendimiento de un proceso ser mejor entre menos fallos de paginacin cause, se podra intentar otorgar a cada proceso el total de
marcos que solicita pero esto tendra como resultado disminuir el grado de
multiprogramacin, y por tanto, reducir el uso efectivo total del procesador.
Otra alternativa es la asignacin igualitaria: se divide el total de espacio en
memoria fsica entre todos los procesos en ejecucin, en partes iguales. Esto
es, volviendo a la computadora hipottica que se present al inicio de esta
seccin, si existen 4 procesos que requieren ser ejecutados, de los 194 marcos
disponibles, el sistema asignar 48 marcos (192KB) a dos de los procesos y 49
(196KB) a los otros dos (es imposible asignar fracciones de marcos). De este
modo, el espacio ser compartido por igual.
La asignacin igualitaria resulta ser un esquema deficiente para casi todas
las distribuciones de procesos: bajo este esquema, si P1 es un gestor de bases de
datos que puede estar empleando 2048KB (512 pginas) de memoria virtual (a
pesar de que el sistema tiene slo 1MB de memoria fsica) y P2 es un lector de
texto que est empleando un usuario, requiriendo apenas 112KB (28 pginas),
con lo cual incluso dejara algunos de sus marcos sin utilizar.
21 Aquellas diseadas antes de que la velocidad del procesador se distanciara tanto del tiempo
de acceso a memoria
204
205
rfaga) hasta que termine con su tarea. En la seccin 5.5.5 se retomar este tema.
mbitos del algoritmo de reemplazo de pginas
Para atender a los problemas no resueltos que se describieron en la seccin
anterior, se puede discutir el mbito en que operar el algoritmo de reemplazo
de pginas.
Reemplazo local Mantener tan estable como sea posible el clculo hecho por
el esquema de asignacin empleado. Esto significa que cuando se presente un fallo de pgina, las pginas que sern consideradas para su intercambio sern nicamente aquellas pertenecientes al mismo proceso que
el que caus el fallo.
Un proceso tiene asignado su espacio de memoria fsica, y se mantendr
estable mientras el sistema operativo no tome alguna decisin por cambiarlo.
Reemplazo global Los algoritmos de asignacin determinan el espacio asignado a los procesos al ser inicializados, e influyen a los algoritmos de
reemplazo (por ejemplo, dando mayor peso para ser elegidas como pginas vctima a aquellas que pertenezcan a un proceso que excede de su
asignacin en memoria fsica).
Los algoritmos de reemplazo de pginas operan sobre el espacio completo de memoria, y la asignacin fsica de cada proceso puede variar segn
el estado del sistema momento a momento.
Reemplazo global con prioridad Es un esquema mixto, en el que un proceso
puede sobrepasar su lmite siempre que le robe espacio en memoria fsica
exclusivamente a procesos de prioridad inferior a l. Esto es consistente
con el comportamiento de los algoritmos planificadores, que siempre dan
preferencia a un proceso de mayor prioridad por sobre de uno de prioridad ms baja.
El reemplazo local es ms rgido y no permite aprovechar para mejorar
el rendimiento los periodos de inactividad de algunos de los procesos. En
contraposicin, los esquemas basados en reemplazo global pueden llevar a
rendimiento inconsistente: dado que la asignacin de memoria fsica sale del
control de cada proceso, puede que la misma seccin de cdigo presente tiempos de ejecucin muy distintos si porciones importantes de su memoria fueron
paginadas a disco.
5.5.5.
Hiperpaginacin
Es un fenmeno que se puede presentar por varias razones: cuando (bajo un esquema de reemplazo local) un proceso tiene asignadas pocas pginas
206
para llevar a cabo su trabajo, y genera fallos de pgina con tal frecuencia que le
imposibilita realizar trabajo real. Bajo un esquema de reemplazo global, cuando hay demasiados procesos en ejecucin en el sistema y los constantes fallos
y reemplazos hacen imposible a todos los procesos involucrados avanzar, tambin se presenta hiperpaginacin 23 .
Hay varios escenarios que pueden desencadenar la hiperpaginacin, y su
impacto es tan claro e identificable que prcticamente cualquier usuario de
cmputo lo sabr reconocer. A continuacin se presentar un escenario ejemplo
en que las malas decisiones del sistema operativo pueden conducirlo a este
estado.
Suponga un sistema que est con una carga media normal, con un esquema
de reemplazo global de marcos. Se lanza un nuevo proceso, que como parte de
su inicializacin requiere poblar diversas estructuras a lo largo de su espacio
de memoria virtual. Para hacerlo, lanza una serie de fallos de pgina, a las que
el sistema operativo responde reemplazando a varios marcos pertenecientes a
otros procesos.
Casualmente, a lo largo del periodo que toma esta inicializacin (que puede
parecer una eternidad: el disco es entre miles y millones de veces ms lento que
la memoria) algunos de estos procesos solicitan los espacios de memoria que
acaban de ser enviados a disco, por lo cual lanzan nuevos fallos de pgina.
Cuando el sistema operativo detecta que la utilizacin del procesador decrece, puede aprovechar la situacin para lanzar procesos de mantenimiento.
Se lanzan estos procesos, reduciendo an ms el espacio de memoria fsica
disponible para cada uno de los procesos preexistentes.
Se ha formado ya toda una cola de solicitudes de paginacin, algunas veces
contradictorias. El procesador tiene que comenzar a ejecutar NOOP (esto es, no
tiene trabajo que ejecutar), porque la mayor parte del tiempo lo pasa en espera
de un nuevo marco por parte del disco duro. El sistema completo avanza cada
vez ms lento.
Los sntomas de la hiperpaginacin son muy claros, y no son difciles de
detectar. Qu estrategia puede emplear el sistema operativo una vez que se
da cuenta que se present esta situacin?
Una salida sera reducir el nivel de multiprogramacin si la paginacin
se present debido a que los requisitos de memoria de los procesos actualmente en ejecucin no pueden ser satisfechos con la memoria fsica disponible,
el sistema puede seleccionar a uno (o ms) de los procesos y suspenderlos por
completo hasta que el sistema vuelva a un estado normal. Podra seleccionarse,
por ejemplo, al proceso con menor prioridad, al que est causando ms cantidad de fallos, o al que est ocupando ms memoria.
23 Una traduccin literal del trmino thrashing, empleado en ingls para designar a este fenmeno, resulta ms grfica: paliza
207
El conjunto activo es, pues, la aproximacin ms clara a la localidad de referencia de un proceso dado: el conjunto de pginas sobre los que est iterando en
un momento dado.
Idealmente, para evitar los problemas relacionados con la hiperpaginacin,
el sistema debe asignar a cada proceso suficientes pginas como para que mantenga en memoria fsica su conjunto activo y si no es posible hacerlo, el
proceso es un buen candidato para ser suspendido. Sin embargo, detectar con
suficiente claridad como para efectuar este diagnstico cul es el conjunto acti-
208
vo es una tarea muy compleja, que tpicamente implica rastrear y verificar del
orden de los ltimos miles a decenas de miles de accesos a memoria.
5.6.
Consideraciones de seguridad
5.6.1.
209
concepto de marcos empleado al hablar de memoria virtual); durante el periodo en que es el marco activo (esto es, cuando no se ha transferido el control
a ninguna otra funcin), est delimitado por dos valores, almacenados en registros:
Apuntador a la pila (Stack pointer, SP) Apunta al final actual (direccin inferior) de la pila. En arquitecturas x86, emplea el registro ESP; cuando se
pide al procesador que acte sobre el stack (con las operaciones pushl o
popl), lo hace sobre este registro
Apuntador del marco (Frame pointer, FP, o Base local, LB) Apunta al inicio del
marco actual, o lo que es lo mismo, al final del marco anterior. En arquitecturas x86, emplea el registro EBP.
A cada funcin a que va entrando la ejecucin del proceso, se va creando
un marco de activacin en el stack, que incluye:
Los argumentos recibidos por la funcin
La direccin de retorno al cdigo que la invoc
Las variables locales creadas en la funcin
Con esto en mente, es posible analizar la traduccin de una llamada a funcin en C a su equivalente en ensamblador, y en segundo trmino ver el marco
del stack resultante:
1
2
3
4
5
6
7
8
210
; main
pushl $3
pushl $2
pushl $1
call func
func:
pushl %ebp
movl %esp, %ebp
subl $20, %esp
La figura 5.22 ilustra cmo queda la regin inferior del stack (el espacio de
trabajo de la funcin actual) una vez que tuvieron lugar estos cuatro pasos.
211
#include <stdio.h>
int main(int argc, char **argv) {
char buffer[256];
if(argc > 1) strcpy(buffer, argv[1]);
printf("Escribiste %s\n", buffer);
return 0;
}
212
213
if (valid_user(usr, pass)) {
/* (...) */
} else {
printf("Error!\n");
exit 1;
}
Y detecta que valid_user() es susceptible a un desbordamiento, le bastara con incrementar en 4 la direccin de retorno. La conversin de este if
a ensamblador es, primero, saltar hacia la etiqueta valid_user, y (empleando al valor que sta regrese en %EBX) ir a la siguiente instruccin, o saltar a la
etiqueta FAIL. Esto puede hacerse con la instruccin BNE $0, %EBX, FAIL
(Branch if Not Equal, Saltar si no es igual, que recibe como argumentos dos valores a ser comparados, en este caso el registro %EBX y el nmero 0, y la etiqueta
destino, FAIL). Cambiar la direccin destino significa burlar la verificacin.
Por otro lado, el atacante podra usar la segunda tcnica para lograr que el
sistema haga algo ms complejo por ejemplo, que ejecute cdigo arbitrario
que l proporcione. Para esto, el ataque ms frecuente es saltar hacia adentro del
stack.
Para hacerlo, si en vez de proporcionar simplemente una cadena suficientemente grande para sobrepasar el buffer se inyecta una cadena con cdigo ejecutable vlido, y sobreescribiera la direccin de retorno con la direccin de su
214
cdigo dentro del buffer, tendra 256 bytes de espacio para especificar cdigo arbitrario. Este cdigo tpicamente se llama shellcode, pues se emplea para obtener
un shell (un intrprete de comandos) que ejecuta con los privilegios del proceso
explotado. Este escenario se ilustra en la figura 5.24.
Mecanismos de mitigacin
Claro est, el mundo no se queda quieto. Una vez que estos mecanismos de
ataque se dieron a conocer, comenz un fuerte trabajo para crear mecanismos
de mitigacin de daos.
La principal y ms importante medida es crear una cultura de programadores conscientes y prcticas seguras. Esto cruza necesariamente el no emplear funciones que no hagan verificacin de lmites. La desventaja de esto es
que hace falta cambiar al factor humano, lo cual resulta prcticamente imposible de lograr con suficiente profundidad25 . Muchos desarrolladores esgrimen
argumentos en contra de estas prcticas, como la prdida de rendimiento que
estas funciones requieren, y muchos otros sencillamente nunca se dieron por
enterados de la necesidad de programar correctamente.
Por esto, se han ido creando diversos mecanismos automatizados de proteccin ante los desbordamientos de buffer. Ninguno de estos mecanismos es
perfecto, pero s ayudan a reducir los riesgos ante los atacantes menos persistentes o habilidosos.
Secciones de datos no ejecutables
En secciones anteriores se describi la proteccin que puede imponer la
MMU por regiones, evitando la modificacin de cdigo ejecutable.
En la arquitectura x86, dominante en el mercado de computadoras personales desde hace muchos aos, esta caracterstica exista en varios procesadores
basados en el modelo de segmentacin de memoria, pero desapareci al cambiarse el modelo predominante por uno de memoria plana paginada, y fue
hasta alrededor del 2001 en que fue introducida de vuelta, bajo los nombres
bit NX (Never eXecute, Nunca ejecutar) o bit XD (eXecute Disable, Deshabilitar
ejecucin), como una caracterstica particular de las extensiones PAE.
Empleando este mecanismo, la MMU puede evitar la ejecucin de cdigo
en el rea de stack, lo cual anula la posibilidad de saltar al stack. Esta proteccin
desafortunadamente no es muy efectiva: una vez que tiene acceso a un buffer
vulnerable, el atacante puede saltar a libc, esto es, por ejemplo, proporcionar
como parmetro el nombre de un programa a ejecutar, e indicar como retorno
la direccin de la funcin system o execve de la libc.
Las secciones de datos no ejecutables son, pues, un obstculo ante un atacante, aunque no representan una dificultad mucho mayor.
25 El ejemplo ms claro de este problema es la funcin gets, la cual sigue siendo enseada y usada
en los cursos bsicos de programacin en C.
215
Empleo de canarios
Se llama canario a un valor aleatorio de proteccin26 , insertado entre los
buffers y la direccin de retorno, que es verificado antes de regresar de una
funcin. Si se present un desbordamiento de buffer, el valor del canario ser
reemplazado por basura, y el sistema podr detener la ejecucin del proceso
comprometido antes de que brinde privilegios elevados al atacante. La figura
5.25 ilustra este mecanismo.
Un atacante tiene dos mecanismos ante un sistema que requiere del canario:
uno es el atacar no directamente a la funcin en cuestin, sino que al manejador
de seales que es notificado de la anomala, y otro es, ya que se tiene acceso
a la memoria del proceso, averiguar el valor del canario. Esto requiere ataques
bastante ms sofisticados que los vistos en esta seccin, pero definitivamente
ya no fuera del alcance de los atacantes.
26 Este uso proviene de la costumbre antigua de los mineros de tener un canario en una jaula en
las minas. Como el canario es muy sensible ante la falta de oxgeno, si el canario mora serva como
indicador a los mineros de que deban abandonar la mina de inmediato, antes de correr la misma
suerte.
216
5.6.2.
27 Refirase al libro Linkers and Loaders (ligadores y cargadores) de John R. Levine (1999) para
mayores detalles respecto a este proceso.
217
218
5.7.
Ejercicios
5.7.1.
Preguntas de autoevaluacin
1. Diagrame el acomodo del espacio en memoria de un proceso. Qu diferencias principales y qu similitudes tienen la seccin de datos con el espacio
de libres (heap)? Y el espacio de libres con la pila (stack)?
2. Un proceso en un sistema con arquitectura de memoria basada en la segmentacin tiene la siguiente tabla de segmentos:
Segmento
0
1
2
3
4
Inicio
240
2300
90
1320
-
Tamao
600
16
100
950
96
Permisos
RX
R
RW
RW
RX
5.7. EJERCICIOS
219
b) Escritura, 0-150
c) Lectura, 1,15
d) Escritura, 2-130
e) Ejecucin, 4-25
3. El buffer de traduccin adelantada (TLB) de un sistema en particular presenta una efectividad del 95 %. Obtener un valor del TLB toma 10ns. La
memoria principal tarda 120ns en recuperar un valor. Cul es el tiempo
promedio para completar una operacin a memoria?
4. Con la siguiente cadena de referencia, y empleando cuatro marcos de
memoria fsica, desarrolle la asignacin bajo los esquemas FIFO, OPT y
LRU:
1, 3, 2, 1, 5, 3, 4, 1, 5, 2, 6, 7, 5, 7, 2, 5, 3, 5, 3, 1
Asumiendo que cada fallo de pgina toma 8 milisegundos en ser atendido, qu diferencia en rendimiento puede observarse?
5. Suponga un sistema paginado con un rango de direcciones de 4GB
(4294967296 direcciones).
Cuntas pginas tendr el sistema si se utilizan pginas de 4096
bytes?
Qu tamao (en bits) tendr una entrada de la tabla de traduccin?
Suponga que slo se guarda el nmero de marco fsico.
Qu tamao tendr la tabla de paginacin si se desea cubrir todo el
rango?
Suponga que el tamao de la tabla de paginacin fuera demasiado
grande. Proponga dos soluciones explicando ventajas y desventajas
de cada una.
6. Explique la relacin que hay entre direcciones virtuales y direcciones fsicas. Indique cmo se realiza la traduccin en los siguientes casos:
Una computadora con TLB y tabla de paginacin de un nivel, con la
entrada cargada en la TLB.
Una computadora con TLB y tabla de paginacin de un nivel y sin
la entrada cargada.
Una computadora sin TLB y con tabla de paginacin de dos niveles.
Una computadora sin paginacin ni TLB pero con segmentacin.
220
7. Un equipo presenta rendimiento muy deficiente. Ante un anlisis de utilizacin a lo largo de un da, se encuentra que el promedio de uso de CPU
est al 20 % y el uso de la interfaz al disco duro que aloja a la memoria
virtual al 95 %. En qu condicin est el sistema?
Elija de la siguiente lista las dos respuestas que mayor efectividad tendran
para mejorar el rendimiento del sistema. Fundamente con una breve explicacin.
a) Reemplazar al CPU por uno 20 % ms rpido (pasar de 1GHz a
1.2GHz)
b) Destinar un rea del disco 25 % ms grande para la memoria virtual
(pasar de 4 a 5GB)
c) Aumentar el grado de multiprogramacin en 10 % (aumentar de 20
a 22 los procesos en la cola de ejecucin)
d) Reducir el grado de multiprogramacin en 10 % (reducir de 20 a 18
los procesos en la cola de ejecucin)
e) Instalar un 25 % ms de memoria principal (pasar de 2 a 2.5GB)
f ) Instalar un disco duro un 33 % ms rpido (cambiar un disco de 5400
RPM por uno de 7200 RPM)
8. Describa en qu consiste un ataque de desbordamiento de pila (stack overflow), y un mecanismo de proteccin del sistema para contrarrestarlos.
Puede sugerir una manera en que un atacante podra burlar dicha proteccin?
5.7.2.
5.7. EJERCICIOS
221
222
5.7.3.
Lecturas relacionadas
5.7. EJERCICIOS
223
224
Aleph One (1996): Uno de los primeros artculos publicados acerca de los
buffers desbordados
Attacking the Windows 7/8 Address Space Randomization
http://kingcope.wordpress.com/2013/01/24/
Kingcopes (2013): Explica cmo puede burlarse la proteccin ALSR (aleatorizacin de direcciones) en Windows 7 y 8, logrando una direccin predecible de memoria hacia la cual saltar.
An overview of Non-Uniform Memory Access
https://dl.acm.org/citation.cfm?doid=2500468.2500477
Captulo 6
Organizacin de archivos
6.1.
Introduccin
otros mecanismos para su organizacin, pero estos no estn tan ampliamente difundi-
dos
225
226
archivos virtual,2 brindando al usuario una interfaz uniforme. Por ltimo, los
archivos son una estructura meramente lgica; deben ser convertidos para ser
representados en un dispositivo de bloques como los diversos tipos de unidades
aunque esta nomenclatura es a veces incorrecta como discos. Este ltimo paso
ser abordado en el captulo 7.
Del diagrama presentado en la figura 6.1, toca al objeto de estudio de esta
obra el sistema operativo recibir del espacio de usuario las llamadas al sistema que presentan la interfaz de archivos y directorios, integrar el sistema de
archivos virtual, y traducir la informacin resultante a un sistema de archivos.
Cabe mencionar que varias de las capas aqu presentadas podran perfectamente ser subdivididas, analizadas por separado, e incluso tratarse de forma
completamente modular de hecho, este es precisamente el modo en que se
implementan de forma transparente caractersticas hoy en da tan comunes como sistemas de archivos en red, o compresin y cifrado de la informacin. Una
referencia ms detallada acerca de ventajas, desventajas, tcnicas y mecanismos de la divisin y comunicacin entre capas puede ubicarse en el artculo de
Heidemann y Popek (1994).
2 Esto
6.2.
227
Concepto de archivo
6.2.1.
228
6.2.2.
229
Tanto el sistema operativo como cada uno de los procesos mantienen normalmente tablas de archivos abiertos. stas mantienen informacin acerca de
todos los archivos actualmente abiertos, presentndolos hacia el proceso por
medio de un descriptor de archivo; una vez que un archivo fue abierto, las operaciones que se realizan dentro de ste no son empleando su nombre, sino que
su descriptor de archivo.
En un sistema operativo multitareas, ms de un proceso podra abrir el mismo archivo a la vez; lo que cada uno de ellos pueda hacer, y cmo esto impacte
a lo que vean los dems procesos, depende de la semntica que implemente el
sistema; un ejemplo de las diferentes semnticas posibles es el descrito en la
seccin 6.2.3.
Ahora, por qu estas tablas son mantenidas tanto por el sistema operativo
como por cada uno de los procesos? No lleva esto a una situacin de informacin redundante?
La respuesta es que la informacin que cada uno debe manejar es distinta.
El sistema operativo necesita:
Conteo de usuarios del archivo Cuando se solicita, por ejemplo, desmontar
una particin (por ejemplo, para expulsar una unidad removible) o eliminar un archivo, el sistema debe poder determinar cundo es momento
de declarar la solicitud como efectuada. Si algn proceso tiene abierto a
un archivo, y particularmente si tiene cambios pendientes de guardar, el
sistema debe hacer lo posible por evitar que el archivo desaparezca de su
visin.
Modos de acceso Aunque un usuario tenga permisos de acceso a determinado
recurso, el sistema puede determinar negarlo si llevara a una inconsistencia. Por ejemplo, si dos procesos abren un mismo archivo en modo de
escritura, es probable que los cambios que realice uno sobreescriban a los
que haga el otro.
Ubicacin en disco El sistema mantiene esta infromacin para evitar que cada
proceso tenga que consultar las tablas en disco para encontrar al archivo,
o cada uno de sus fragmentos.
Informacin de bloqueo En caso de que los modos de acceso del archivo requieran proteccin mutua, puede implementarse por medio de un bloqueo.
Por otro lado, el proceso necesita:
Descriptor de archivo Relacin entre el nombre del archivo abierto y el identificador numrico que maneja internamente el proceso. Un archivo abierto
230
Permisos Los modos vlidos de acceso para un archivo. Esto no necesariamente es igual a los permisos que tiene el archivo en cuestin en disco,
sino que el subconjunto de dichos permisos bajo los cuales est operando
para este proceso en particular si un archivo fue abierto en modo de
slo lectura, por ejemplo, este campo slo permitir la lectura.
6.2.3.
Dado que los archivos pueden emplearse como mecanismo de comunicacin entre procesos que no guarden relacin entre s, incluso a lo largo del
tiempo, y para emplear un archivo basta indicar su nombre o ruta, los sistemas
operativos multitarea implementan mecanismos de bloqueo para evitar que
varios procesos intentando emplear de forma concurrente a un archivo se corrompan mutuamente.
Algunos sistemas operativos permiten establecer bloqueos sobre determinadas regiones de los archivos, aunque la semntica ms comn es operar sobre el archivo entero.
En general, la nomenclatura que se sigue para los bloqueos es:
Compartido (Shared lock) Podra verse como equivalente a un bloqueo (o candado) para realizar lectura varios procesos pueden adquirir al mismo
tiempo un bloqueo de lectura, e indica que todos los que posean dicho
candado tienen la expectativa de que el archivo no sufrir modificaciones.
Exclusivo (Exclusive lock) Un bloqueo o candado exclusivo puede ser adquirido
por un slo proceso, e indica que realizar operaciones que modifiquen
al archivo (o, si la semntica del sistema operativo permite expresarlo, a
la porcin del archivo que indica).
Respecto al mecanismo de bloqueo, hay tambin dos tipos, dependiendo de
qu tan explcito tiene que ser su manejo:
Mandatorio u obligatorio (Mandatory locking) Una vez que un proceso adquiere
un candado obligatorio, el sistema operativo se encargar de imponer
las restricciones corresponidentes de acceso a todos los dems procesos,
4 No slo los archivos reciben descriptores de archivo. Por ejemplo, en todos los principales
sistemas operativos, los descriptores 0, 1 y 2 estn relacionados a flujos de datos: respectivamente, la
entrada estndar (STDIN), la salida estndar (STDOUT) y el error estndar (STDERR); si el usuario
no lo indica de otro modo, la terminal desde donde fue ejecutado el proceso.
231
6.2.4.
Tipos de archivo
Si los archivos son la unidad lgica mnima con la que se puede guardar
informacin en almacenamiento secundario, naturalmente sigue que existen
archivos de diferentes tipos: cada archivo podra ser un documento de texto,
un binario ejecutable, un archivo de audio o video, o un largusimo etcetera,
e intentar emplear a un archivo como uno de un tipo distinto puede resultar
desde una frustracin al usuario porque el programa no responde como ste
quiere, hasta en prdidas econmicas.6
Hay tres estrategias principales para que el sistema operativo reconozca al
tipo de un archivo:
Extensin En los sistemas CP/M de los 1970, el nombre de cada archivo se
divida en dos porciones, empleando como elemento separador al punto:
el nombre del archivo y su extensin. El sistema mantena una lista de
5 Esto
explica por qu en Windows es tan comn que el sistema mismo rechace hacer determinada operacin porque el archivo est abierto por otro programa (bloqueo mandatorio compartido),
mientras que en Unix esta responsabilidad recae en cada uno de los programas de aplicacin
6 Por ejemplo, imprimir un archivo binario resulta en una gran cantidad de hojas intiles, particularmente tomando en cuenta que hay caracteres de control como el ASCII 12 (avance de forma,
form feed), que llevan a las impresoras que operan en modo texto a iniciar una nueva pgina; llevar
a un usuario a ejecutar un archivo ejecutable disfrazado de un documento inocuo, como se ver a
continuacin, fue un importante vector de infeccin de muchos virus.
232
Nmeros mgicos La alternativa que emplean los sistemas Unix es, como
siempre, simple y elegante, aunque indudablemente presenta eventuales
lagunas: el sistema mantiene una lista compilada de las huellas digitales de
los principales formatos que debe manejar,7 para reconocer el contenido
de un archivo basado en sus primeros bytes.
Casi todos los formatos de archivo incluyen lo necesario para que se lleve
a cabo este reconocimiento, y cuando no es posible hacerlo, se intenta
por medio de ciertas reglas heursticas. Por ejemplo, todos los archivos
de imgen en formato de intercambio grfico (GIF) inician con la cadena
GIF87a o GIF89a, dependiendo de la versin; los archivos del lenguaje
de descripcin de pginas PostScript inician con la cadena %!, el Formato
de Documentos Porttiles (PDF) con %PDF, etctera. Un documento en formatos definidos alrededor de XML inicia con <!DOCTYPE. Algunos de
estos formatos no estn anclados al inicio, sino que en un punto especfico
del primer bloque.
Un caso especial de nmeros mgicos es el llamado hashbang (#!). Esto indica a un sistema Unix que el archivo en cuestin (tpicamente
un archivo de texto, incluyendo cdigo fuente en algn lenguaje de
script) debe tratarse como un ejecutable, y empleando como intrprete
al comando indicado inmediatamente despus del hashbang. Es por esto que se pueden ejecutar directamente, por ejemplo, los archivos que
7 Una de las ventajas de este esquema es que cada administrador de sistema puede ampliar la
lista con las huellas digitales que requiera localmente
233
6.2.5.
234
como IBM CICS (1968), IBM MVS (1974) o DEC VMS (1977), que administraban
ciertos tipos de datos en un formato bsico de base de datos.
El hecho de que el sistema operativo no imponga estructura a un archivo
no significa, claro est, que la aplicacin que lo genera no lo haga. La razn
por la que los sistemas creados en los ltimos 30 aos no han implementado
este esquema de base de datos es que le resta flexibilidad al sistema: el que
una aplicacin tuviera que ceirse a los tipos de datos y alineacin de campos del sistema operativo impeda su adecuacin, y el que la funcionalidad
de un archivo tipo base de datos dependiera de la versin del sistema operativo creaba un acoplamiento demasiado rgido entre el sistema operativo y las
aplicaciones.
Esta prctica ha ido cediendo terreno a dejar esta responsabilidad en manos
de procesos independientes en espacio de usuario (como sera un gestor de
bases de datos tradicional), o de bibliotecas que ofrezcan la funcionalidad de
manejo de archivos estructurados (como en el caso de SQLite, empleado tanto
por herramientas de adquisicin de datos de bajo nivel como systemtap como
por herramientas tan de escritorio como el gestor de fotografas shotwell o el
navegador Firefox).
En los sistemas derivados de MS-DOS puede verse an un remanente de
los archivos estructurados: en estos sistemas, un archivo puede ser de texto o
binario. Un archivo de texto est compuesto por una serie de caracteres que
forman lneas, y la separacin entre una lnea y otra constituye de un retorno
de carro (CR, caracter ASCII 13) seguido de un salto de lnea (LF, caracter ASCII
10).8
El acceso a los archivos puede realizarse de diferentes maneras:
Acceso secuencial Mantiene la semntica por medio de la cual permite leer de
los archivos de forma equivalente a como lo haran las unidades de cinta
mencionadas en la seccin 6.2.1, y como lo ilustra la figura 6.2: el mecanismo principal para leer o escribir es ir avanzando consecutivamente por
los bytes que conforman al archivo hasta llegar a su final.
Tpicamente se emplea este mecanismo de lectura para leer a memoria
cdigo (programas o bibliotecas) o documentos, sea enteros o fracciones
de los mismos. Para un contenido estructurado, como una base de datos,
resultara absolutamente ineficiente, dado que no se conoce el punto de
inicio o finalizacin de cada uno de los registros, y probablemente sera
necesario que hacer barridos secuenciales del archivo completo para cada
una de las bsquedas.
8 Esta
lgica es herencia de las mquinas de escribir manuales, en que el salto de lnea (avanzar
el rodillo a la lnea siguiente) era una operacin distinta a la del retorno de carro (devolver la cabeza
de escritura al inicio de la lnea). En la poca de los teletipos, como medida para evitar que se
perdieran caracteres mientras la cabeza volva hasta la izquierda, se decidi separar el inicio de
nueva lnea en los dos pasos que tienen las mquinas de escribir, para inducir una demora que
evitara la prdida de informacin.
235
Acceso relativo a ndice En los ltimos aos se han popularizado los gestores
de base de datos dbilmente estructurados u orientados a documentos, llamados genricamente NoSQL. Estos gestores pueden guardar registros de
tamao variable en disco, por lo que, como lo ilustra la figura 6.4, no
pueden encontrar la ubicacin correcta por medio de los mecanismos de
acceso aleatorio.
Para implementar este acceso, se divide al conjunto de datos en dos secciones (incluso, posiblemente, en dos archivos independientes): la primer
seccin es una lista corta de identificadores, cada uno con el punto de
236
Figura 6.4: Acceso relativo a ndice: un ndice apuntando al punto justo de un archivo sin estructura
6.2.6.
Archivos especiales
Los sistemas de archivos son estructuras de tan fcil manejo y comprensin que resulta natural que los diseadores de sistemas operativos buscaran
237
6.2.7.
238
6.3.
Organizacin de archivos
6.3.1.
239
240
241
242
Figura 6.7: Directorio como un grafo dirigido acclico: el directorio proyecto est
tanto en el directorio /home/usr1 como en el directorio /home/usr2
nodo. Ambas entradas, pues, son el mismo archivo no hay uno maestro
y uno dependiente.
En un sistema Unix, este mecanismo tiene slo dos restricciones:
1. Slo se pueden hacer ligas duras dentro del mismo volumen.
2. No pueden hacerse ligas duras a directorios, slo a archivos.13
Liga o enlace simblico Es un archivo especial, que meramente indica a dnde
apunta. El encargado de seguir este archivo a su destino (esto es, de resolver la liga simblica) es el sistema operativo mismo; un proceso no
tiene que hacer nada especial para seguir la liga.
Una liga simblica puede apuntar a directorios, incluso creando ciclos, o
a archivos en otros volmenes.
Cuando se crea una liga simblica, la liga y el archivo son dos entidades
distintas. Si bien cualquier proceso que abra al archivo destino estar trabajando con la misma entidad, en caso de que ste sea renombrado o
eliminado, la liga quedar rota (esto es, apuntar a una ubicacin inexistente).
Si bien estos dos tipos de liga existen tambin en los sistemas Windows14 ,
en dichos sistemas sigue siendo ms comn emplear los accesos directos. Se denomina as a un archivo (identificado por su extensin, .lnk), principalmente
creado para poder apuntar a los archivos desde el escritorio y los menes
13 Formalmente, puede haberlas, pero slo el administrador puede crearlas; en la seccin 6.3.2 se
cubre la razn de esta restriccin al hablar de recorrer los directorios.
14 nicamente en aquellos que emplean el sistema de archivos NTFS, no en los que utilizan alguna de las variantes de FAT
243
Figura 6.8: Directorio como un grafo dirigido, mostrando los enlaces ocultos al directorio actual . y al directorio padre ..
Como se puede ver en la figura 6.8, en todos los directorios, . es una liga
dura al mismo directorio, y .. es una liga al directorio padre (de nivel jerrquico
inmediatamente superior). Claro est, como slo puede haber una liga .., un
directorio enlazado desde dos lugares distintos slo apunta hacia uno de ellos con su enlace ..; en este caso, el directorio comn proyecto est dentro del directorio /home/usr2. La figura representa la liga simblica desde
/home/usr1 como una lnea punteada.
Hay una excepcin a esta regla: el directorio raiz. En este caso, tanto . como
.. apuntan al mismo directorio.
Esta es la razn por la cual no se puede tomar rigurosamente a un rbol de
archivos como a un grafo dirigido acclico, ni en Windows ni en Unix: tanto las
244
entradas . (al apuntar al mismo directorio donde estn contentidas) como las
entradas .. (al apuntar al directorio padre) crean ciclos.
6.3.2.
Al igual que los archivos, los directorios tienen una semntica bsica de
acceso. Los directorios resultan tambin tipos de datos abstractos con algunas
operaciones definidas. Muchas de las operaciones que pueden realizarse con
los directorios son anlogas a las empleadas para los archivos.15 Las operaciones bsicas a presentar son:
Abrir y cerrar Al igual que los archivos, los directorios deben ser abiertos para
trabajar con ellos, y cerrados cuando ya no se les requiera. Para esto, en
C, se emplean las funciones opendir() y closedir(). Estas funciones
trabajan asociadas a un flujo de directorio (directory stream), que funciona
de forma anloga a un descriptor de archivo.
Listado de archivos Para mostrar los archivos que conforman a un directorio,
el directorio se abre (tal como se hara con un archivo, pero empleando la
funcin opendir() en vez de open()), y va leyendo (con readdir())
cada una de sus entradas. Cada uno de los resultados es una estrcutura dirent (directory entry, esto es, entrada de directorio), que contiene su
nombre en d_name, un apuntador a su i-nodo en d_ino, y algunos datos
adicionales del arcihvo en cuestin.
Para presentar al usuario la lista de archivos que conforman un directorio, podra hacerse:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
#include <stdio.h>
#include <dirent.h>
#include <sys/types.h>
int main(int argc, char *argv[]) {
struct dirent *archivo;
DIR *dir;
if (argc != 2) {
printf("Indique el directorio a mostrar\n");
return 1;
}
dir = opendir(argv[1]);
while ((archivo = readdir(dir)) != 0) {
printf(" %s\t", archivo->d_name);
}
printf("\n");
closedir(dir);
15 De hecho, en muchos sistemas de archivos los directorios son meramente archivos de tipo especial, que son presentados al usuario de forma distinta. En la seccin 7.1.4 se presenta un ejemplo.
245
246
/home/jose/proyecto/miembros
/home/jose/proyecto/miembros/jose
/home/jose/proyecto/miembros/jose/proyectos
/home/jose/proyecto/miembros/jose/proyectos/miembros
. . . Y un etctera infinito.
Para resolver esta situacin, los programas que recorren directorios en los
sistemas de archivos reales deben emplear un indexado basado en i-nodo16 identifica sin lugar a dudas a cada uno de los archivos. En el caso presentado, si el
i-nodo de jose fuera 10543, al consultar a los miembros de miembros el sistema encontrar que su primer entrada apunta al i-nodo 10543, por lo cual la
registrara slo como un apuntador a datos ya archivados, y continuara con la
segunda entrada del directorio, que apunta a pedro.
Otros esquemas de organizacin
Por ms que el uso de sistemas de archivos basados en directorios jerrquicos
parece universal y es muy ampliamente aceptado, hay cada vez ms casos de
uso que apuntan a que se pueda estar por dar la bienvenida a una nueva metfora de organizacin de archivos.
Hay distintas propuestas, y claro est, es imposible an saber cul direccin
obtendr el favor del mercado o, dado que no necesariamente siga existiendo un modelo apto para todos los usos, de qu segmento del mercado.
16 Que si bien no ha sido definido an formalmente, para esta discusin bastar saber que es un
nmero nico por volumen.
6.3.3.
247
Montaje de directorios
Para trabajar con el contenido de un sistema de archivos, el sistema operativo tiene que montarlo: ubicarlo en algn punto del rbol de archivos visible al
sistema y al usuario.
Es muy comn, especialmente en los entornos derivados de Unix, que un
sistema operativo trabaje con distintos sistemas de archivos al mismo tiempo.
Esto puede obedecer a varias causas, entre las cuales se encuentran:
Distintos medios fsicos Si la computadora tiene ms de una unidad de almacenamiento, el espacio dentro de cada uno de los discos se maneja como
un sistema de archivos indepentiente. Esto es especialmente cierto en la
presencia de unidades removibles (CDs, unidades USB, discos duros externos, etc.)
Diferentes usos esperados Como se ver ms adelante, distintos esquemas de
organizacin (esto es, distintos sistemas de archivos) presentan ventajas
para distintos patrones de uso. Por ejemplo, tiene sentido que una base
de datos resida sobre una organizacin distinta a la de los programas
ejecutables (binarios) del sistema.
Abstracciones de sistemas no-fsicos El sistema operativo puede presentar
diversas estructuras con una estructura de sistema de archivos. El ejemplo
ms claro de esto es el sistema de archivos virtual /proc, existente en
los sistemas Unix, que permite ver diversos aspectos de los procesos en
ejecucin (y, en Linux, del sistema en general). Los archivos bajo /proc
no existen en ningn disco, pero se presentan como si fueran archivos
estndar.
Razones administrativas El administrador del sistema puede emplear sistemas de archivos distintos para aislar espacios de usuarios entre s: por
ejemplo, para evitar que un exceso de mensajes enviados en la bitcora
(tpicamente bajo /var/log) saturen al sistema de archivos principal, o
para determinar patrones de uso mximo por grupos de usuarios.
En los sistemas tipo Unix, el mecanismo para montar los archivos es el de
un rbol con puntos de montaje. Esto es, todos los archivos y directorios del sistema
operativo estn estructurados en un nico rbol. Cuando se solicita al sistema
operativo montar un sistema de archivos en determinado lugar, ste se integra
al rbol, ocultando todo lo que el directorio en cuestin previamente tuviera.17
17 Hay implementaciones que exigen que el montaje se realice exclusivamente en directorios
vacos; existen otras, como UnionFS, que buscan seguir presentando una interfaz de lectura a los
objetos que existan en el directorio previo al montaje, pero realizan las escrituras nicamente en
el sistema ya montado; estas complican fuertemente algunos aspectos semnticos, por lo cual resultan poco comunes.
248
Figura 6.10: rbol formado del montaje de sda1 en la raiz, sda2 como /usr, sdb1
como /home, y el directorio virtual proc
6.4.
Control de acceso
249
6.4.1.
Sistemas FAT
250
6.4.2.
El sistema Unix precede a MS-DOS por una dcada. Sin embargo, su concepcin es de origen para un esquema multiusuario, con las provisiones necesarias para que cada uno de ellos indique qu usuarios pueden o no tener diferentes tipos de acceso a los archivos.
En Unix, cada uno de los usuarios pertenece a uno o ms grupos. Estos grupos son gestionados por el administrador del sistema.
Cada objeto en el sistema de archivos describe sus permisos de acceso por
nueve bits, y con el identificador de su usuario y grupo propietarios.
Estos bits estn dispuestos en tres grupos de tres; uno para el usuario, uno
para el grupo, y uno para los otros. Por ltimo, los tres grupos de tres bits indican si se otorga permiso de lectura, eescritura y ejecucin. Estos permisos son
251
.
..
compilacion.log
factura
factura.c
factura.h
factura.o
lineamientos.txt
Makefile
Este ejemplo muestra que cada archivo puede pertenecer a otro de los
miembros del grupo.20 Para el ejemplo aqu mostrado, el usuario propietario
es menos importante que el grupo al que pertenece.
La ejecucin slo est permitida, para los miembros del grupo factura,
en el archivo factura: Los dems archivos son ya sea el cdigo fuente que se
emplea para generar dicho archivo ejecutable, o la informacin de desarrollo y
compilacin.
Respecto al acceso del resto de los usuarios (esto es, aquellos no pertenecientes
al grupo factura), todos tienen permiso de lectura sobre todos los archivos
a excepcin del archivo intermedio de compilacin, factura.o, el documento
de diseo, lineamientos.txt, y la bitcora de compilacin, compilacion.log
Este ejemplo muestra los directorios . y .., que fueron presentados en la
seccin 6.3.1. Para los directorios, se emplea el mismo sistema de permisos;
el permiso de escritura indica quin puede crear o eliminar archivos dentro
de l, el permiso de lectura indica qu usuarios pueden averiguar la lista de
archivos contenidos en dicho directorio, y el de ejecucin indica qu usuarios
pueden entrar al directorio. En este caso, todos los usuarios pueden listar (leer)
y ejecutar (entrar) al directorio, pero nicamente el administrador root y los
miembros del grupo factura pueden modificar los archivos que contiene.
Claro est, el directorio .. (que apunta de vuelta al directorio padre,
/usr/local/) es del sistema, y permite slo la lectura y ejecucin a todos
20 Los archivos pertenecen al usuario que los cre, a menos que su propiedad sea cedida por el
administrador a otro usuario.
252
6.4.3.
253
Estas polticas no siempre resultan fciles de comprender por los usuarios del
sistema.
6.5.
254
se designa como cliente a la computadora que solicita un servicio, y como servidor a la que lo provee; es frecuente que dos computadoras sean tanto servidor
como cliente la una de la otra en distintos servicios.
6.5.1.
El Sistema de Archivos en Red (Network File System, mejor conocido por sus
siglas, NFS) fue creado por Sun Microsystems, y desde 1984 forma parte de su
sistema operativo result una implementacin tan exitosa que a los pocos
aos formaba parte de todos los sistemas tipo Unix.
NFS est construido sobre el mecanismo RPC (Remote Procedure Call, Llamada a Procedimientos Remotos), un mecanismo de mensajes y manejo bsico
de sesin que acta como una capa superior a TCP/IP, incluyendo facilidades
de descubrimiento de recursos y abstraccin. RPC puede ser comparado con protocolos como DCE/RPC de OSF, DCOM de Microsoft, y hoy en da, SOAP y
XML-RPC. Estos mecanismos permiten al programador delegar en un servicio
el manejo de las conexiones de red, particularmente (en el caso particular aqu
descrito) la persistencia de sesiones en caso de desconexin, y limitar su atencin a una conexin virtual establecida.
La motivacin de origen para la creacin de NFS fue presentar una solucin
que aprovechara el hardware existente y centralizara la administracin: ofrecer
las facilidades para contar con redes donde hubiera un servidor de archivos, y
donde las estaciones de trabajo tuvieran nicamente una instalacin bsica,21
y el entorno de usuario completo estuviera disponible en cualquiera de las
estaciones.
NFS ofrece sobre la red un sistema de archivos con la semntica Unix completa para montar un sistema remoto, basta montarlo22 y usarlo como si
fuera local. El manejo de permisos, usuarios, e incluso las ligas duras y simblicas se manejan exactamente como se hara localmente.
NFS es un protocolo muy ligero no implementa cifrado ni verificaciones
adicionales, pero al da de hoy, es uno de los mejores mecanismos para el envo de grandes cantidades de informacin pero siempre en redes que sean
completamente confiables.
Ahora, NFS se presenta como uno de los componentes de una solucin
completa. Dado que se espera que la informacin de usuarios y permisos sea
consistente en todos los clientes; Sun ofreca tambin un esquema llamado Yellow Pages (posteriormente renombrado a NIS, Network Information System) para
compartir la informacin de autenticacin y listas de usuarios.
21 Incluso manejando estaciones de trabajo diskless, esto es, computadoras sin disco duro, cuyo
sistema de arranque tiene la capacidad de solicitar al servidor le enve incluso el ncleo del sistema
operativo que ejecutar
22 Para
montar un sistema remoto, se emplea un comando como mount
archivos.unam.mx:/ext/home /home, con lo cual el directorio /ext/home ubicado en
el servidor archivos.unam.mx aparecer montado como directorio /home local.
255
6.5.2.
El equivalente a NFS en los entornos donde predominan los sistemas Windows es el protocolo CIFS (Common Internet File System, Sistema de Archivos
Comn para Internet). Aparece en los sistemas primarios de Microsoft alrededor de 199023 , originalmente bajo el nombre SMB (Server Message Block, Bloque
de Mensaje del Servidor).
Las primeras implementaciones estaban basadas en el protocolo NBF, frecuentemente conocido como NetBEUI, un protocolo no ruteable diseado para
redes pequeas y entornos sencillos de oficina. A partir de Windows 2000 se ha
reimplementado completamente para operar sobre TCP/IP. Es a partir de este
momento que se le comienza a denominar CIFS, aunque el nombre SMB sigue
siendo ampliamente utilizado.24
CIFS se ajusta mucho ms a la semntica de los sistemas MS-DOS y Windows, aunque dado el lapso de tiempo que ha existido, ha pasado por varios
cambios fundamentales, que al da de hoy complican su uso.
Para tener acceso a un volumen compartido por SMB se introdujo el comando NET;25 basta indicar a DOS o Windows (desde la lnea de comando) NET
USE W: \\servidor\directorio para que el recurso compartido bajo el
nombre directorio dentro del equipo conocido como servidor aparezca
23 El
256
6.5.3.
257
cuencia las redes grandes28 (y lo hacan mucho ms hace 30 aos): AFS debe
operar tan confiablemente como sea posible, incluso sin la certeza de que la red
opera correctamente.
AFS construye fuertemente sobre el modelo de tickets y credenciales de Kerberos,29 pero se aleja sensiblemente de la semntica de operacin de archivos
que hasta ahora se han presentado. Muchos eventos, operaciones y estados
van ligados al momento en el tiempo en que se presentan, a travs de un modelo
de consistencia dbil (weak consistency model). Muy a grandes rasgos, esto significa
que:
Cuando se abre un archivo, ste se copia completo al cliente. Todas las
lecturas y escrituras (a diferencia de los esquemas tradicionales, en que
stas son enviadas al servidor lo antes posible y de forma sncrona) se dirigen nicamente a la copia local.
Al cerrar el archivo, ste se copia de vuelta al servidor de origen, el cual se
compromete a notificar a los clientes si un archivo abierto fue modificado
(esto es, a hacer una llamada o callback). Los clientes pueden entonces intentar incorporar los cambios a su versin de trabajo, o continuar con la
copia ya obtenida es esperable que si un segundo cliente realiza alguna modificacin, incorpore los cambios hechos por el primero, pero esta
responsabilidad se deja a la implementacin del programa en cuestin.
Esto significa en pocas palabras que los cambios a un archivo abierto por
un usuario no son visibles a los dems de inmediato; slo una vez que se cierra
un archivo, los cambios hechos a ste son puestos a disposicin de las sesiones
abiertas actuales, y slo son enviados como versin actual a las sesiones abiertas
posteriormente.
Con este cambio semntico, debe quedar claro que AFS no busca ser un
sistema para todo uso ni un reemplazo universal de los sistemas de archivos
locales, en contraposicin de los sistemas de archivos centralizados. AFS no
plantea en ningn momento una operacin diskless. Bajo el esquema aqu descrito, las lecturas y escrituras resultan baratas, porque se realizan exclusivamente sobre el cach local, pero abrir y cerrar un archivo puede ser muy caro,
porque debe transferirse el archivo completo.
Hay aplicaciones que verdaderamente sufriran si tuvieran que implementarse sobre un sistema de archivos distribudo por ejemplo, si una base de
datos se distribuyera sobre AFS, la carencia de mecanismos de bloqueo sobre
secciones del archivo, y el requisito de operar sobre archivos completos haran
impracticable compartir un archivo de uso intensivo y aleatorio.
28 El uso tpico de AFS se planteaba para organizaciones grandes, del orden de decenas de miles
de estaciones
29 Un sistema de autenticacin y autorizacin centralizado para entornos corporativos.
258
6.6.
Ejercicios
6.6.1.
Preguntas de autoevaluacin
6.6. EJERCICIOS
259
6.6.2.
6.6.3.
Lecturas relacionadas
260
http://cyanezfdz.me/post/los-discos-desde-la-perspectiva-de-un-sistema-de-a
Captulo 7
Sistemas de archivos
7.1.
7.1.1.
262
Mientras tanto, conviene mantener una visin an bastante idealizada y abstracta: un disco visto desde la perspectiva del sistema operativo ser presentado a lo largo del presente captulo1 como un arreglo muy grande de bloques
de tamao fijo, cada uno de ellos directamente direccionable; esto significa que
el sistema operativo puede referirse por igual a cualquiera de los bloques del
disco a travs de una direccin fsica e inambigua dentro del disco entero. Partiendo de esto, se emplean los siguientes conceptos para almacenar, ubicar o
recuperar la informacin:
Particin Una subdivisin de un disco, por medio de la cual el administrador/usuario del sistema puede definir la forma en que se emplea
el espacio del disco, segmentndolo si hace falta segn haga falta.
Un disco puede tener varias particiones, y cada una de ellas puede tener
un sistema de archivos independiente.
Volumen Coleccin de bloques inicializados con un sistema de archivos que
pueden presentarse al usuario como una unidad. Tpicamente un volumen coincide con una particin (pero no siempre es el caso, como se
describir en las secciones C.2 y C.3).
El volumen se describe ante el sistema operativo en el bloque de control de
volumen, tambin conocido como superbloque en Unix, o Tabla Maestra de
Archivos (Master File Table) en NTFS.
Sistema de archivos Esquema de organizacin que sigue un determinado volumen. Dependiendo del sistema de archivos elegido, cada uno de los
componentes aqu presentados ocuparn un distinto lugar en el disco,
presentando una semntica propia.
Para poder tener acceso a la informacin almacenada en determinado
volumen, el sistema operativo debe tener soporte para el sistema de
archivos particular en que ste est estructurado.
Directorio raiz La estructura que relaciona cada nombre de archivo con su
nmeros de i-nodo. Tpicamente slo almacena los archivos que estn en
el primer nivel jerrquico del sistema, y los directorios derivados son nicamente referenciados desde ste.
En sistemas de archivos modernos, el directorio normalmente incluye slo el nombre de cada uno de los archivos y el nmero de i-nodo que lo
describe, todos los metadatos adicionales estn en los respectivos i-nodos.
Metadatos Recibe este nombre toda la informacin acerca de un archivo que no
es el contenido del archivo mismo. Por ejemplo, el nombre, tamao o tipo
del archivo, su propietario, el control de acceso, sus fechas de creacin,
ltimo acceso y modificacin, ubicacin en disco, etc.
1 Para una visin ms rigurosa de cmo se relaciona el sistema operativo con los discos y dems
mecanismos de almacenamiento, refirase al apndice C.
263
I-nodo Del ingls i-node, information node (nodo de informacin); en los sistemas tipo Windows, normalmente se le denomina bloque de control de
archivo (FCB). Es la estructura en disco que guarda los metadatos de cada uno de los archivos, proporcionando un vnculo entre la entrada en el
directorio y los datos que lo conforman.
La informacin almacenada incluye todos los metadatos relacionados
con el archivo a excepcin del nombre (mismo que radica nicamente en el
directorio): los permisos y propietarios del archivo, sus fechas de creacin,
ltima modificacin y ltimo acceso, y la relacin de bloques que ocupa en
el disco. Ms adelante se abordarn algunos de los esquemas ms comunes para presentar esta relacin de bloques.
Esta separacin entre directorio e i-nodo permite a un mismo archivo formar parte de distintos directorios, como se explic en la seccin 6.3.1.
Mapa de bits de espacio libre La funcin del bitmap es poder gestionar el espacio libre del disco. Recurdese que el disco se presenta asignado por
bloques, tpicamente de 4096 bytes en el bitmap cada bloque se representa con un bit, con lo que aqu se puede encontrar de forma compacta
el espacio ocupado y disponible, as como el lugar adecuado para crear
un nuevo archivo.
El bitmap para un disco de 100GB puede, de esta manera, represen109 ), cantidad que puede razonablemente mantener
tarse en 23MB ( 1004096
en memoria un sistema de escritorio promedio hoy en da.2
Ms adelante se vern algunas estructuras avanzadas que permiten mayor eficiencia en este sentido.
7.1.2.
264
7.1.3.
El volumen
265
7.1.4.
El directorio es la estructura que relaciona a los archivos como son presentados al usuario identificados por una ruta y un nombre con las estructuras
que los describen ante el sistema operativo los i-nodos.
A lo largo de la historia de los sistemas de archivos, se han implementado
muy distintos esquemas de organizacin. Se presenta a continuacin la estructura bsica de la popular familia de sistemas de archivos FAT.
266
El directorio raiz
Una vez que el sistema de archivos est montado (ver 6.3.3), todas las referencias a archivos dentro de ste deben pasar a travs del directorio. El directorio raiz est siempre en una ubicacin bien conocida dentro del sistema
de archivos tpicamente al inicio del volumen, en los primeros sectores6 .
Un disco flexible tena 80 pistas (tpicamente denominadas cilindros al hablar
de discos duros), con lo que, al ubicar al directorio en la pista 40, el tiempo
promedio de movimiento de cabezas para llegar a l se reduca a la mitad. Si
todas las operaciones de abrir un archivo tienen que pasar por el directorio,
esto resultaba en una mejora muy significativa.
El directorio es la estructura que determina el formato que debe seguir el
nombre de cada uno de los archivos y directorios: es comn que en un sistema
moderno, el nombre de un archivo pueda tener hasta 256 caracteres, incluyendo espacios, caracteres internacionales, etc. Algunos sistemas de archivos son
sensibles a maysculas, como es el caso de los sistemas nativos a Unix (el archivo
ejemplo.txt es distinto de Ejemplo.TXT), mientras que otros no lo son, como es el caso de NTFS y VFAT (ejemplo.txt y Ejemplo.TXT son idnticos
ante el sistema operativo).
Todas las versiones de FAT siguen para los nombres de archivos un esquema claramente arcico: los nombres de archivo pueden medir hasta 8 caracteres, con una extensin opcional de 3 caracteres ms, dando un total de 11.
El sistema no slo no es sensible a maysculas y minsculas, sino que todos
los nombres deben guardarse completamente en maysculas, y permite slo
ciertos caracteres no alfanumricos. Este sistema de archivos no implementa
la separacin entre directorio e i-nodo, que hoy es la norma, por lo que cada
una de las entradas en el directorio mide exactamente 32 bytes. Como es de
esperarse en un formato que ha vivido tanto tiempo y ha pasado por tantas
generaciones como FAT, algunos de estos campos han cambiado substancialmente sus significados. La figura 7.1 muestra los campos de una entrada del
directorio bajo FAT32.
Figura 7.1: Formato de la entrada del directorio bajo FAT (Mohammed, 2007)
267
7 La etiqueta de volumen estaba definida para ser empleada exclusivamente a la cabeza del directorio, dando una etiqueta global al sistema de archivos completo; el significado de una entrada de
directorio con este atributo hasta antes de la incorporacin de VFAT no estaba definida.
268
Figura 7.2: Entradas representando archivos con (y sin) nombre largo bajo VFAT
269
Cuadro 7.1: Significado de cada uno de los bits del byte de atributos del archivo en el
directorio FAT. La semntica que se presenta es la empleada por los sistemas MSDOS y Windows; otros sistemas pueden presentar comportamientos adicionales.
Bit
0
1
2
Nombre
Slo lectura
Oculto
Sistema
Etiqueta
Subdirectorio
Archivado
Dispositivo
Reservado
Descripcin
El sistema no permitir que sea modificado.
No se muestra en listados de directorio.
El archivo pertenece al sistema y no debe
moverse de sus clusters (empleado, por
ejemplo, para los componentes a cargar para
iniciar al sistema operativo)
Indica el nombre del volumen, no un archivo.
En VFAT, expresa la continuacin de un
nombre largo.
Los clusters que componen a este archivo
son interpretados como un subdirectorio,
no como un archivo.
Empleado por algunos sistemas de respaldo
para indicar si un archivo fue modificado
desde su ltima copia.
Para uso interno del sistema operativo, no
fue adoptado para los archivos.
Reservado, no debe ser manipulado.
va asignando espacio conforme encuentra nuevos clusters libres, sin cuidar que
sea espacio continuo. Los apuntadores al siguiente cluster se van marcando en
la tabla, cluster por cluster, y el ltimo cluster de cada archivo recibe el valor
especial (dependiendo de la versin de FAT) 0xFFF, 0xFFFF o 0xFFFFFFFF.
Ahora bien, si los directorios son sencillamente archivos que reciben un
tratamiento especial, estos son tambin susceptibles a la fragmentacin. Dentro de un sistema Windows 95 o superior (empleando VFAT), con directorios
anidados a cuatro o cinco niveles como lo establece su jerarqua estndar9 , la
simple tarea de recorrerlos para encontrar determinado archivo puede resultar
muy penalizado por la fragmentacin.
La eliminacin de entradas del directorio
Slo unos pocos sistemas de archivos guardan sus directorios ordenados
si bien esto facilitara las operaciones ms frecuentes que se realizan sobre
de ellos (en particular, la bsqueda: cada vez que un directorio es recorrido
9 Por
ejemplo,
C:\Documents and Settings\Usuario\Men Inicio\Programa
Ejemplo\Programa Ejemplo.lnk
270
hasta encontrar un archivo tiene que leerse potencialmente completo), mantenerlo ordenado ante cualquier modificacin resultara mucho ms caro, dado
que tendra que reescribirse el directorio completo al crearse o eliminarse un
archivo dentro de ste, y lo que es ms importante, ms peligroso, dado que
aumentara el tiempo que los datos del directorio estn en un estado inconsistente, aumentando la probabilidad de que ante una interrupcin repentina
(fallo de sistema, corte elctrico, desconexin del dispositivo, etc.) se presentara corrupcin de la informacin llevando a prdida de datos. Al almacenar
las entradas del directorio sin ordenar, las escrituras que modifican esta crtica
estructura se mantienen atmicas: un slo sector de 512 bytes puede almacenar
16 entradas bsicas de FAT, de 32 bytes cada una.10
Ordenar las entradas del directorio teniendo sus contenidos ya en memoria
y, en general, diferir las modificaciones al directorio resulta mucho ms conveniente en el caso general. Esto vale tambin para la eliminacin de archivos
a continuacin se abordar la estrategia que sigue FAT. Cabe recordar que
FAT fue diseado cuando el medio principal de almacenamiento era el disco
flexible, decenas de veces ms lento que el disco duro, y con mucha menor
confiabilidad.
Cuando se le solicita a un sistema de archivos FAT eliminar un archivo, ste
no se borra del directorio, ni su informacin se libera de la tabla de asignacin
de archivos, sino que se marca para ser ignorado, reemplazando el primer caracter de su nombre por 0xE5. Ni la entrada de directorio, ni la cadena de clusters
correspondiente en las tablas de asignacin,11 son eliminadas slo son marcadas como disponibles. El espacio de almacenamiento que el archivo eliminado
ocupa debe, entonces, ser sumado al espacio libre que tiene el volumen. Es slo cuando se crea un nuevo archivo empleando esa misma entrada, o cuando
otro archivo ocupa el espacio fsico que ocupaba el que fue eliminado, que el
sistema operativo marca realmente como desocupados los clusters en la tabla de
asignacin.
Es por esto que desde los primeros das de las PC existen tantas herramientas de recuperacin (o des-borramiento, undeletion) de archivos: siempre que
no haya sido creado un archivo nuevo que ocupe la entrada de directorio en
cuestin, recuperar un archivo es tan simple como volver a ponerle el primer
caracter a su nombre.
Este es un ejemplo de un mecanismo flojo (en contraposicin de los mecanismos ansiosos, como los vistos en la seccin 5.5.1). Eliminar un archivo requiere
de un trabajo mnimo, mismo que es diferido al momento de reutilizacin de la
entrada de directorio.
10 Aunque en el caso de VFAT, las diferentes entradas que componen un slo nombre de archivo
pueden quedar separadas en diferentes sectores.
11 Este tema ser abordado en breve, en la seccin 7.2.4, al hablar de las tablas de asignacin de
archivos.
7.1.5.
271
Compresin y desduplicacin
272
273
vo desde ese punto en adelante; esto podra mitigarse insertando espacios para
preservar el espacio ya ocupado, pero agrega complejidad al proceso (y abona
en contra de la compresin). Los archivos comprimidos son adems mucho
ms sensibles a la corrupcin de datos, particularmente en casos de fallo de sistema o de energa: dado que un cambio menor puede resultar en la necesidad
de reescribir al archivo completo, la ventana de tiempo para que se produzca
un fallo se incrementa.
En archivos estructurados para permitir el acceso aleatorio, como podran
ser las tablas de bases de datos, la compresin implicara que los registros no
estarn ya alineados al tamao que el programa gestor espera, lo cual acarrear
necesariamente una penalizacin en el rendimiento y en la confiabilidad.
Por otro lado, los formatos nativos en que se expresan los datos que tpicamente ms espacio ocupan en el almacenamiento de los usuarios finales implican ya un alto grado de compresin: los archivos de fotografas, audio o video
estn codificados empleando diversos esquemas de compresin aptos para sus
particularidades. Y comprimir un archivo que de suyo est ya comprimido no
slo no reporta ningn beneficio, sino que resulta en desperdicio de trabajo por
el esfuerzo invertido en descomprimirlo cada vez que es empleado.
La compresin transparente archivo por archivo tiene innegables ventajas,
sin embargo, por las desventajas que implica, no puede tomarse como el modo
de operacin por omisin.
Desduplicacin
Hay una estrategia fundamentalmente distinta para optimizar el uso del
espacio de almacenamiento, logrando muy altos niveles de sobreuso: guardar
slo una copia de cada cosa.
Ha habido sistemas implementando distintos tipos de desduplicacin desde fines de los 1980, aunque su efectividad era muy limitada y, por tanto, su
uso se mantuvo como muy marginal hasta recientemente.
El que se retomara la desduplicacin se debe en buena medida se debe a
la consolidacin de servidores ante la adopcin a gran escala de mecanismos de
virtualizacin (ver apndice B, y en particular la seccin B.5). Dado que un mismo servidor puede estar alojando a decenas o centenas de mquinas virtuales,
muchas de ellas con el mismo sistema operativo y programas base, los mismos
archivos se repiten muchas veces; si el sistema de archivos puede determinar
que determinado archivo o bloque est ya almacenado, podra almacenarse
slamente una copia.
La principal diferencia entre la desduplicacin y las ligas duras mencionados en la seccin 6.3.1 es que, en caso de que cualquiera de estos archivos (o
bloques) sea modificado, el sistema de archivos tomar el espacio necesario
para representar estos cambios y evitar que esto afecte a los dems archivos.
Adems, si dos archivos inicialmente distintos se hacen iguales, se liberar el
espacio empleado por uno de ellos de forma automtica.
274
7.1.6.
275
276
7.2.
7.2.1.
Asignacin contigua
Los primeros sistemas de archivos en disco empleaban un esquema de asignacin contigua. Para implementar un sistema de archivos de este tipo, no hara
falta el contar con una tabla de asignacin de archivos: bastara con la informacin
que forma parte del directorio de FAT la extensin del archivo y la direccin
de su primer cluster.
La principal ventaja de este mecanismo de asignacin, claro est, es la simplicidad de su implementacin. Brinda adems la mejor velocidad de transferencia del archivo, dado que al estar cada uno de los archivos en espacio
contiguo en el disco, el movimiento de cabezas se mantiene al mnimo. Sin
embargo, este mecanismo se vuelve sumamente inconveniente en medios que
soporten lectura y escritura: es muy sensible a la fragmentacin externa; si un
archivo requiere crecer, debe ser movido ntegramente a un bloque ms grande
(lo cual toma demasiado tiempo), y el espacio que libera un archivo en caso
de reducirse su necesidad de espacio queda atrapado entre bloques asignados;
podemos tener mucho ms espacio disponible que el que podamos asignar a
un nuevo archivo.
Los esquemas de asignacin contigua se emplean hoy en da principalmente en sistemas de archivo de slo lectura por ejemplo, lo emplea
el sistema principal que utilizan los CD-ROMs, el ISO-9660, pensado para
277
aprovechar al mximo un espacio que, una vez grabado, slo podr abrirse
en modo de slo lectura. Esto explica por qu, a diferencia de como ocurre
en cualquier otro medio de almacenamiento, al quemar un CD-ROM es necesario preparar primero una imagen en la que los archivos ocupen sus posiciones
definitivas, y esta imagen debe grabarse al disco en una sola operacin.
7.2.2.
Asignacin ligada
Un enfoque completamente distinto sera el de asignacin ligada. Este esquema brinda mucho mayor flexibilidad al usuario, sacrificando la simplicidad y
la velocidad: cada entrada en el directorio apunta a un primer grupo de sectores
(o cluster), y ste contiene un apuntador que indica cul es el siguiente.
Para hacer esto, hay dos mecanismos: el primero, reservar un espacio al
final de cada cluster para guardar el apuntador, y el segundo, crear una tabla
independiente, que guarde nicamente los apuntadores.
En el primer caso, si se manejan clusters de 2048 bytes, y se reservan los
4 bytes (32 bits) finales de cada uno, el resultado sera de gran incomodidad
al programador: frecuentemente, los programadores buscan alinear sus operaciones con las fronteras de las estructuras subyacentes, para optimizar los accesos (por ejemplo, evitar que un slo registro de base de datos requiera ser
ledo de dos distintos bloques en disco). El programador tendra que disear
sus estructuras para ajustarse a la poco ortodoxa cantidad de 2044 bytes.
Y ms all de esta inconveniencia, guardar los apuntadores al final de cada
cluster hace mucho ms lento el manejo de todos los archivos: al no tener en
una sola ubicacin la relacin de clusters que conforman a un archivo, todas las
transferencias se convierten en secuenciales: para llegar directamente a determinado bloque del archivo, habr que atravesar todos los bloques previos para
encontrar su ubicacin.
Particularmente por este segundo punto es mucho ms comn el empleo
de una tabla de asignacin de archivos y precisamente as es como opera FAT
(de hecho, esta tabla es la que le da su nombre). La tabla de asignacin es un
mapa de los clusters, representando a cada uno por el espacio necesario para
guardar un apuntador.
La principal ventaja del empleo de asignacin ligada es que desaparece la
fragmentacin interna.16 Al ya no requerir la pre-asignacin de un espacio contiguo, cada uno de los archivos puede crecer o reducirse segn sea necesario.
Ahora, la asignacin ligada no slo resulta ms lenta que la contigua, sino
que presenta una mayor sobrecarga administrativa: el espacio desperdiciado para
16 Con fragmentacin interna se hace aqu referencia al concepto presentado en la seccin 5.2.1. El
fenmeno generalmente conocido como fragmentacin se refiere a la necesidad de compactacin; es
muy distinto, y s se presenta bajo este esquema: cada archivo se separa en pequeos fragmentos
que pueden terminar esparcidos por todo el disco, impactando fuertemente en el rendimiento del
sistema
278
Figura 7.4: Asignacin ligada de archivos: directorio con apuntador slo al primer
cluster
7.2.3.
Asignacin indexada
279
280
281
7.2.4.
282
Cuadro 7.2: Valores especiales que puede almacenar FAT; cualquier otro valor indica la direccin del siguiente cluster que forma parte del archivo al cual pertenece el
registro en cuestin.
FAT12
0x000
0xFF7
0xFFF
FAT16
0x0000
0xFFF7
0xFFFF
FAT32
0x00000000
0xFFFFFFF7
0xFFFFFFFF
Significado
Disponible, puede ser asignado
Cluster daado, no debe utilizarse
ltimo cluster de un archivo
cluster debe apuntar al siguiente, puede asumirse que el caso comn es que los
clusters no ocuparn contiguos en el disco. Claro est, la tabla puede apuntar
a varios clusters adyacentes, pero el sistema de archivos mismo no hace nada
para que as sea.
En la seccin 7.1.4, al presentar el formato del directorio de FAT, se mencion que los subdirectorios son en realidad archivos de un tipo especial: una
suerte de archivos estructurados (ver seccin 6.2.5), gestionados por el sistema
operativo. Lo nico que distingue a un directorio de un archivo normal es que,
en la entrada que lo describe en su directorio padre, el doceavo byte de la entrada (que indica los atributos del archivo, ver figura 7.1 y cuadro 7.1) tiene activado
el bit 4.
Un directorio es almacenado en disco exactamente como cualquier otro
archivo. Si se le asigna nicamente un cluster, y el tamao del cluster es pequeo (2KB), podr almacenar slo 64 entradas ( 2048
32 ) y cada cluster adicional
le dar 64 entradas ms. Y como tal, est sujeto tambin a la fragmentacin:
conforme se agregan entradas al directorio, ste crece. Llegado el momento,
283
7.3.
Fallos y recuperacin
El sistema de archivos FAT es relativamente frgil: no es difcil que se presente una situacin de corrupcin de metadatos, y muy particularmente, de la
estructura de las tablas de asignacin. Los usuarios de sistemas basados en
FAT en Windows sin duda conocen a los programas CHKDSK y SCANDISK, dos
programas que implementan la misma funcionalidad base, y difieren principalmente en su interfaz al usuario: CHKDSK existe desde los primeros aos
de MS-DOS, y est pensado para su uso interactivo en lnea de comando;
SCANDISK se ejecuta desde el entorno grfico, y presenta la particularidad de
que no requiere (aunque s recomienda fuertemente) acceso exclusivo al sistema
de archivos mientras se ejecuta.
19 Claro est, en el caso de los archivos que estn como ligas duras desde varios directorios,
pueden ubicarse slo cerca de uno de ellos
284
285
Cada sistema de archivos podr presentar un distinto conjunto de inconsistencias, dependiendo de sus estructuras bsicas y de la manera en que cada
sistema operativo las maneja.
En la dcada de los 1980 comenzaron a entrar a mercado los controladores de
disco inteligentes, y en menos de diez aos dominaban ya el mercado. Estos controladores, con buses tan dismiles como SCSI, IDE, o los ms modernos, SAS
y SATA, introdujeron muchos cambios que fueron disociando cada vez ms al
sistema operativo de la gestin fsica directa de los dispositivos; en el apndice
C se presenta a mayor profundidad lo que esto ha significado para el desarrollo de sistemas de archivos y algoritmos relacionados. Sin embargo, para el
tema en discusin, los controladores inteligentes resultan relevantes porque, si
bien antes el sistema operativo poda determinar con toda certeza si una operacin se haba realizado o no, hoy en da los controladores dan un acuse de
recibo a la informacin en el momento en que la colocan en el cach incorporado del dispositivo en caso de un fallo de corriente, esta informacin puede
no haber sido escrita por completo al disco.
Es importante recordar que las operaciones con los metadatos que conforman al sistema de archivos no son atmicas. Por poner un ejemplo, crear un
archivo en un volumen FAT requiere:
1. Encontrar una lista de clusters disponibles suficiente para almacenar la
informacin que conformar al archivo.
2. Encontrar el siguiente espacio disponible en el directorio.
3. Marcar en la tabla de asignacin la secuencia de clusters que ocupar el
archivo.
4. Crear en el espacio encontrado una entrada con el nombre del archivo,
apuntando al primero de sus clusters.
5. Guardar los datos del archivo en cuestin en los clusters correspondientes.
Cualquier fallo que se presente despus del tercer paso (cuando hacemos la
primer modificacin) tendr como consecuencia que el archivo resulte corrupto, y muy probablemente que el sistema de archivos todo presente inconsistencias
o est en un estado inconsistente.
7.3.1.
Datos y metadatos
286
7.3.2.
Verificacin de la integridad
7.3.3.
Actualizaciones suaves
287
288
7.3.4.
Este esquema tiene su origen en el mbito de las bases de datos distribudas. Consiste en separar un rea del volumen y dedicarla a llevar una bitcora
(journal) con todas las transacciones de metadatos.23 Una transaccin es un conjunto de operaciones que deben aparecer como atmicas.
La bitcora es generalmente implementada como una lista ligada circular,
con un apuntador que indica cul fue la ltima operacin realizada exitosamente. Peridicamente, o cuando la carga de transferencia de datos disminuye, el sistema verifica qu operaciones quedaron pendientes, y avanza sobre
la bitcora, marcando cada una de las transacciones conforme las realiza.
En caso de tener que recuperarse de una condicin de fallo, el sistema operativo slo tiene que leer la bitcora, encontrar cul fue la ltima operacin
efectuada, y aplicar las restantes.
Una restriccin de este esquema es que las transacciones guardadas en la
bitcora deben ser idempotentes esto es, si una de ellas es efectuada dos veces, el efecto debe ser exactamente el mismo que si hubiera sido efectuada una
sla vez. Por poner un ejemplo, no sera vlido que una transaccin indicara
Agregar al directorio x un archivo llamado y, dado que si la falla se produce despus de procesar esta transaccin pero antes de avanzar al apuntador
de la bitcora, el directorio x quedara con dos archivos y una situacin inconsistente. En todo caso, tendramos que indicar registrar al archivo y en la
posicin z del directorio x; de esta manera, incluso si el archivo ya haba sido
registrado, puede volverse a registrar sin peligro.
289
7.3.5.
290
aunque es un campo que an requiere de mucha investigacin e implementaciones ejemplo. Muchas de las implementaciones en sistemas libres han llegado a niveles de funcionalidad aceptables, pero por diversas causas han ido
perdiendo el inters o el empuje de sus desarrolladores, y su ritmo de desarrollo ha decrecido. Sin embargo, varios conceptos muy importantes han nacido
bajo este tipo de sistemas de archivos, algunos de los cuales (como el de las
fotografas) se han ido aplicando a sistemas de archivo estndar.
Por otro lado, dado el fuerte crecimiento que estn registrando los medios
de almacenamiento de estado slido (en la seccin C.1.2 se abordarn algunas
de sus particularidades), y dado que estos sistemas aprovechan mejor varias
de sus caractersticas, es probable que el inters en estos sistemas de archivos
resurja.
7.4.
Ejercicios
7.4.1.
Preguntas de autoevaluacin
7.4. EJERCICIOS
7.4.2.
291
Desduplicacin Una de las caractersticas que ofrecen varios sistemas operativos de ltima generacin es la desduplicacin, presentada en la seccin
7.1.5: La deteccin de sectores idnticos pertenecientes a ms de un archivo, para evitar repetirlos varias veces en el disco (es un fenmeno que
ocurre mucho ms de lo que esperaramos). Esta deteccin se realiza tpicamente por medio de hashes criptogrficos.
Cmo opera un poco ms a detalle este mecanismo? Qu tan confiable
es? (esto es, se recomienda utilizar ya en sistemas en produccin?) Qu
tan eficiente resulta con los datos que se encuentran tpicamente? Qu
pasa con el espacio libre reportado al sistema? No se cae en riesgos de
sobrecomprometimiento (overcommit)? Qu diferencias tienen la desduplicacin en lnea y la desduplicacin fuera de lnea (online deduplication, offline
deduplication)? Cmo opera el hash criptogrfico? Hay veces que resulte
insuficiente? Qu alternativas hay?
Como referencia informal al respecto, sugiero leer el siguiente hilo de
discusin al respecto en la lista de DebConf (el congreso de Debian):
http://lists.debconf.org/lurker/message/20130813.100610.f38cd67f.en.html
7.4.3.
Lecturas relacionadas
Dominic Giampaolo (1999). El autor fue parte del equipo que implement el sistema operativo BeOS, un sistema de alto rendimiento pensado
para ejecutar en estaciones de alto rendimiento, particularmente enfocado al video. El proyecto fracas a la larga, y BeOS (as como BeFS, el
sistema que describe) ya no se utilizan. Este libro, descargable desde el
sitio Web del autor, tiene una muy buena descripcin de varios sistemas
de archivos, y aborda a profundidad tcnicas que hace 15 aos eran verdaderamente novedosas, y hoy forman parte de casi todos los sistemas
de archivos con uso amplio, e incluso algunas que no se han logrado implementar y que BeFS s ofreca.
Processes as Files
http://lucasvr.gobolinux.org/etc/Killian84-Procfs-USENIX.pdf
T. J. Killian (1984)
A method for the construction of Minimum-Redundancy Codes
http://compression.graphicon.ru/download/articles/huff/huffman_
1952_minimum-redundancy-codes.pdf
292
http://cyanezfdz.me/post/los-discos-desde-la-perspectiva-de-un-sistema-de-a
7.4. EJERCICIOS
293
294
Apndice A
Software libre y
licenciamiento
A.1.
Software libre
Este apndice, a diferencia del resto del libro, no se enfoca a asuntos tcnicos, sino que a un aspecto social: a la construccin del conocimiento de forma
colectiva, colaborativa, que ha resultado en el movimiento del software libre.
Si bien este tema es meramente tangente al que desarrolla el libro, los autores consideran importante incluirlo no slo por la importancia que el software libre ha tenido para el desarrollo y estudio de los sistemas operativos,
sino que directamente como se explica en la seccin A.2 para el presente libro en particular.
A.1.1.
Citando la definicin que brinda la Fundacin del Software Libre (Free Software Foundation), el software libre es todo programa en el cual los usuarios
tienen la libertad para ejecutar, copiar, distribuir, estudiar, modificar y mejorar el
software. Esto es, todo programa cuyo modelo de licenciamiento respete las cuatro libertades del software:
La libertad de ejecutar el programa para cualquier propsito.
La libertad de estudiar cmo funciona el programa, y cambiarlo para que haga lo que usted quiera. El acceso al cdigo fuente
es una condicin necesaria para ello.
La libertad de redistribuir copias para ayudar a su prjimo.
La libertad de distribuir copias de sus versiones modificadas a
terceros. Esto le permite ofrecer a toda la comunidad la oportu295
296
A.1.2.
El software libre como hoy se conoce existi mucho antes del proyecto
GNU: era la norma prcticamente hasta la aparicin de las computadoras personales.
Los sistemas operativos, las herramientas de sistema y los compiladores eran, en un principio, entregadas por los fabricantes junto con el equipo de cmputo no slo como objetos binarios, sino que en cdigo fuente. Esto era natural:
los operadores de las computadoras no limitaban su uso a adecuar el software,
sino que era comn que adecuaran tambin el hardware: cada equipo instalado
era, hasta cierto punto, nico.
Para hacerlo, claro, casi siempre era necesario modificar al software de forma correspondiente. Esto requera el acceso al cdigo fuente, e implcitamente
pasaba por las cuatro libertades ya enunciadas.
Durante las primeras dcadas, prcticamente la totalidad del desarrollo del
cmputo se llev a cabo siguiendo la tradicin acadmica: los programas eran
distribudos, sea en cintas o incluso en listados impresos, requiriendo nicamente como en un artculo cientfico que se preserve la atribucin de autora.
Slo de este modo puede entenderse el desarrollo (y la supervivencia hasta el
da de hoy) de sistemas con la relevancia de CP-CMS, creado por la muy pragmtica y corporativa empresa IBM y cuya progenie sigue emplendose como
ncleo de su arquitectura de virtualizacin z/VM (ver seccin B.3) o Unix.
297
A.1.3.
La anomala histrica resulta, ms bien, el auge que tuvo el software propietario o privativo.2 Una de las probables razones para ste puede ser, paradjicamente, el nacimiento del segmento del cmputo aficionado, como los presentados en la seccin 1.4: las primeras computadoras personales carecan del almacenamiento y poder de cmputo suficiente para siquiera compilar sus propios
entornos operativos, razn por la cual las empresas productoras recurrieron a
una distribucin exclusivamente binaria.
El inicio de la masificacin del cmputo llev a que varias empresas nacientes identificaran un nicho de mercado donde podran vender licencias de
1 The Evolution of the Unix Time-sharing System; Language Design and Programming Methodology conference; Sydney, Australia, 1979. http://cm.bell-labs.com/cm/cs/who/dmr/hist.html
2 Se designa de esta forma al software no-libre.
298
uso de los programas que produjeran, cobrando relativamente poco por cada
licencia, pero aspirando a vender un gran volumen.
En este sentido, vale mucho la pena leer la carta abierta a los entusiastas que
Bill Gates, socio de la entonces naciente y pequea empresa Micro-Soft public
en varias revistas de cmputo personal; la publicacin original fue en el Homebrew Computer Club Newsletter (peridico del club de cmputo casero) en enero de
1976, y fue replicado en varias otras revistas.
Esta carta abierta tuvo amplias repercusiones, y desat un interesante debate que los lectores interesados podrn encontrar (y seguir en copias de los
textos originales) desde el artculo de Wikipedia repecto a esta carta abierta.
A.1.4.
299
300
A.2.
Los distintos esquemas de software libre fueron logrando una masa crtica
y poco a poco rompieron las predicciones de fracaso. 1998 fue un ao crtico,
en que varios importantes proyectos propietarios decidieron migrar a un licenciamiento libre por resultar ms conveniente y sustentable.
Ya con esta experiencia previa, y conforme el acceso a Internet se masificaba
cada vez ms, comenz a verse la necesidad de crear con esquemas similares de
licenciamiento libre para otros productos de la creatividad humana, no nicamente para el desarrollo del software. Si bien las licencias acadmicas podran
aplicarse sin demasiado problema a productos que no fueran software, las licencias Copyleft llevan demasiadas referencias al cdigo fuente y al binario como
parte de su definicin.
Del mismo modo que hay diferentes escuelas de pensamiento y puntos de
vista ideolgicos que han llevado al surgimiento de diversas licencias de software libre, respondiendo a distintas necesidades y matices ideolgicos.
El proyecto Wikipedia fue anunciado en enero del 2001. Al convocar a todo
mundo y no slo a un manojo de especialistas, a crear contenido enciclopdico, este experimento iniciado por Jimmy Wales y Larry Sanger demostr que la
301
creacin es un acto profundamente social. Miles de voluntarios de todo el mundo han contribudo para hacer de la Wikipedia el compendio de conocimiento
humano ms grande de la historia. Al nacer, la Wikipedia adopt el modelo
de licenciamiento recomendado por la FSF para manuales y libros de texto: la
Licencia de Documentacin Libre de GNU (GFDL).
El modelo de la GFDL resulta, sin embargo, de dificil comprensin y aplicacin para muchos autores, y la licencia no resulta apta para obras creativas
ms all de lo que puede constituir documentacin.
El marco regulatorio de la Convencin de Berna, que rige al derecho de autor, estipula (como ya se mencion) que toda creacin plasmada en un medio
fsico est protegida, y todo uso no expresamente autorizado por una licencia expresa est prohibido. La tarea de crear esquemas de licenciamiento aptos
para lo que se fue definiendo como obras culturales libres result ms compleja
por la riqueza de su expresin. En pocos aos hubo una proliferacin de licencias que buscaban ayudar a los autores de obras creativas de todo tipo no se
abordarn los distintos intentos, sino que aprovechando que la distancia en
tiempo permiten simplificar se tocar slo el esquema de licenciamiento que
ms impacto ha tenido.
A.2.1.
302
su xito y adopcin masiva fue simplificar la explicacin de estos distintos elementos, y la presentacin de las alternativas bajo siglas mnemotcnicas.
Las licencias CC han pasado, al momento de edicin del presente material,
por cuatro versiones mayores, que han ido corrigiendo defectos en el lenguaje
legal, y agregando o clarificando conceptos. Las opciones de las licencias CC
son:5
CC0 (Dominio Pblico) La rigidez del convenio de Berna hace muy dificil en
la mayor parte de las jurisdicciones el liberar una obra renunciando expresamente a todos los derechos patrimoniales que conlleva. La licencia
cero o dedicacin al dominio pblico explicita esta renuncia expresa de derechos.
BY (Atribucin) Todas las combinaciones de licencias CC a excepcin de CC0
incluyen la clusula de atribucin: la obra puede emplearse para cualquier
fin, pero toda redistribucin debe reconocer el crdito de manera adecuada, proporcionar un enlace a la licencia, e indicar si se han realizado cambios. Puede hacerlo en cualquier forma razonable, pero no de forma tal
que sugiera que tiene el apoyo del licenciante o lo recibe por el uso que
hace.
SA (Compartir Igual) Si un usuario del la obra en cuestin decide mezclar,
transformar o crear nuevo material a partir de ella, puede distribuir su
contribucin siempre que utilice la misma licencia que la obra original.
Esto es, la clusula Compartir Igual le confiere un caracter Copyleft al licenciamiento elegido.
NC (No Comercial) La obra puede ser utilizada, reproducida o modificada
segn lo permitido por los otros componentes elegidos de la licencia
siempre y cuando esto no se considere o dirija hacia una ganancia comercial o monetaria.
ND (No Derivadas) La obra puede ser redistribuda acorde con los otros componentes elegidos de la licencia, pero debe ser redistribuda slo si no se
afecta su integridad: no puede ser modificada sin autorizacin expresa
del autor.
Las licencias CC han sido empleadas para todo tipo de creaciones: Libros,
msica, pelculas, artes plsticas incluso, si bien no era su fin original, para
licenciamiento de software. Y su gran xito estiba no slo en su uso, sino en que
han llevado la nocin del licenciamiento permisivo y de las obras culturales libres a una gran cantidad de creadores que, sin CC, probablemente habran
publicado sus creaciones bajo la tradicional modalidad todos los derechos reservados.
5 Parte del texto aqu presentado ha sido tomado del asistente para la eleccin de licencias de
Creative Commons; dicho texto est licenciado bajo un esquema CC-BY (atribucin) 4.0.
303
A.3.
Los autores de este libro buscaron contribuir con material de calidad libremente apropiable y reutilizable para la enseanza superior en pases hispanoparlantes. Para lograr este fin, todo el material contenido en el libro (texto,
cdigo fuente e imgenes) est licenciado bajo Creative Commons Atribucin 4.0
Internacional (CC BY 4.0)6 , salvo si se menciona explcitamente de otra manera.
304
A.4.
Ejercicios
A.4.1.
Lecturas relacionadas
A.4. EJERCICIOS
305
306
Apndice B
Virtualizacin
B.1.
Introduccin
307
308
APNDICE B. VIRTUALIZACIN
Para casi todos los casos que se presentan, se emplearn los siguientes trminos:
Anfitrin El hardware o sistema real, que ofrece el mecanismo de virtualizacin. En ingls se le denomina host.
Husped El sistema o las aplicaciones que se ejecutan en el entorno virtualizado. En ingls se les denomina guest.
B.2.
Emulacin
B.2. EMULACIN
309
mayor parte de las computadoras vendidas son sistemas embebidos3 o dispositivos mviles, que hacen imposible (o, por lo menos, muy difcil) desarrollar
software directamente en ellos. Los programadores desarrollan en equipos de
escritorio, ejecutan entornos de prueba en emuladores del equipo destino. A
pesar del costo computacional de realizar la emulacin, la diferencia de velocidad entre los equipo de escritorio de gama alta y los embebidos permiten que
frecuentemente la velocidad del emulador sea muy similar incluso superior
a la del hardware emulado.
B.2.1.
310
APNDICE B. VIRTUALIZACIN
B.2. EMULACIN
311
B.2.2.
De lo abstracto a lo concreto
312
APNDICE B. VIRTUALIZACIN
Crusoe fue lanzado al mercado con el CMS para la arquitectura x86 de Intel,
y efectivamente, la emulacin era completamente transparente al usuario.4 El
procesador mismo, adems, no implementaba algunas caractersticas que hoy
en da se consideran fundamentales, como una unidad de manejo de memoria,
dado que eso poda ser implementado por software en el CMS. Separando de
esta manera las caractersticas complejas a una segunda capa, podan mantenerse ms bajos tanto el nmero de transistores (y, por tanto, el gasto eneergtico) y los costos de produccin.
La segunda generacin de chips Transmeta (Efficeon) estaba basada en una
arquitectura muy distinta, buscando un rendimiento mejorado. Pero, gracias al
CMS, esto resulta imperceptible al usuario.
A pesar de estas ideas interesantes y novedosas, Transmeta no pudo mantener el dinamismo necesario para despegar, y ces sus operaciones en 2009.
B.2.3.
Emulacin o simulacin?
313
B.3.
Actualmente se usa la virtualizacin como una herramienta para la consolidacin de servicios, de gran ayuda para los administradores de sistemas. Este
uso se refiere principalmente a lo que se presentar en este apartado, as como en las secciones B.4 (Paravirtualizacin) y B.5 (Contenedores). Y si bien este
zumbido de la virtualizacin se ha producido mayormente a partir del 20062007, no se trata de tecnologas o ideas novedosas existe desde fines de los
1960. Hasta hace algunos aos, sin embargo, se mantena dentro del mbito de
los servidores a gran escala, fuera del alcance de la mayor parte de los usuarios.
Es necesario estudiar la gnesis de esta herramienta, para poder comprender
mejor cmo opera y cmo se implementa.
En 1964, IBM cre la primer familia de computadoras, la serie 360. Presentaron
la entonces novedosa idea de que una organizacin poda adquirir un modelo
sencillo y, si sus necesidades se ajustaban al modelo de cmputo, podran migrar facilmente hacia modelos ms poderosos dado que tendran compatibilidad
binaria.
Uno de los modelos de esta familia fue la S-360-67, con la caracterstica distintiva en ser la nica de la serie 360 en ofrecer una unidad de manejo de memoria (MMU), con lo cual permita la reubicacin de programas en memoria. Esto, sin embargo, creaba un problema: el software desarrollado para los equipos
ms pequeos de la familia estaba creado bajo un paradigma de usuario nico,
y si bien podra ser ejecutado en este modelo, eso llevara a un desperdicio de
recursos (dado que el modelo 67 tena todo lo necesario para operar en modo
multitarea).
La respuesta de IBM fue muy ingeniosa: desarrollar un sistema operativo mnimo, CP (Control Program, Programa de Control) con el nico propsito
de crear y gestionar mquinas virtuales dentro del hardware S/360-67, dentro
de cada una de las cuales pudiera ejecutarse sin requerir modificaciones un sistema operativo estndar de la serie 360. De entre los varios sistemas operativos
disponibles para la S/360, el que ms frecuentemente se utiliz fue el CMS,5
un sistema sencillo, interactivo y monousuario. La combinacin CP/CMS proporcionaba un sistema operativo multiusuario, con plena proteccin entre procesos, y con compatibilidad con los modelos ms modestos de la serie 360.
5 Originalmente, las siglas CMS eran por el Cambridge Monitor System, por haber sido desarrollado en la divisin de investigacin de IBM en Cambridge, pero posteriormente fue renombrado a
Conversational Monitor System, Sistema de Monitoreo Conversacional
314
APNDICE B. VIRTUALIZACIN
An despus de la vida til de la serie 360 original, IBM mantuvo compatibilidad con este modelo hacia la serie 370, e incluso hoy, 50 aos ms tarde, se
encuentra an como z/VM en la lnea de Sistemas z.
Vale la pena mencionar que tanto CP como CMS fueron distribudos desde
el principio de forma consistente con lo que en la actualidad se conoce como
software libre: IBM los distribua en fuentes, con permiso de modificacin y redistribucin, y sus diferentes usuarios fueron enviando las mejoras que realizaban de vuelta a IBM, de modo que hoy en da incorpora el trabajo de 50 aos
de desarrolladores.
B.3.1.
El hipervisor
El modelo CP/CMS lleva a una separacin bastante limpia entre un multiplexador de hardware (CP) y el sistema operativo propiamente dicho (CMS). Y
si bien la dupla puede ser vista como un slo sistema operativo, conforme se
fueron ejecutando en mquinas virtuales sistemas operativos ms complejos
se hizo claro que el CP tendra que ser otra cosa. Partiendo del concepto de que
el sistema operativo es el supervisor de la actividad de los usuarios, yendo un
paso ms hacia arriba, se fue popularizando el nombre de hipervisor para el programa que administra y virtualiza a los supervisores. Algunas caractersticas
primarias que definen qu es un hipervisor son:
Es nicamente un micro-sistema operativo, dado que no cubre muchas de
las reas clsicas ni presenta las interfaces abstractas al usuario final
sistemas de archivos, mecanismos de comunicacin entre procesos,
gestin de memoria virtual, evasin de bloqueos, etctera.
Se limita a gestionar bloques de memoria fsica contiguos y fijos, asignacin de dispositivos y poco ms que eso.
Normalmente no tiene una interfaz usuario directa, sino que es administrado a travs de llamadas privilegiadas desde alguno de los sistemas
operativos husped.
Estas lneas se han ido haciendo borrosas con el tiempo. Ahora, por ejemplo, muchos hipervisores entienden a los sistemas de archivos, permitiendo que
los espacios de almacenamiento ofrecidos a sus sistemas operativos husped
sean simples archivos para el sistema anfitrin (y no particiones o dispositivos
enteros). Algunos hipervisores, como KVM bajo Linux se presentan integrados
como un componente ms de un sistema operativo estndar.
B.3.2.
Hasta alrededor del ao 2005, la virtualizacin no se mencionaba muy frecuentemente. Si bien haba hardware virtualizable 40 aos atrs, era hardware
315
bastante especializado y caro. Ese ao, Intel sac al mercado los procesadores con las extensiones necesarias para la virtualizacin, bajo el nombre
Vanderpool Technology (o VT-x). Al ao siguiente, AMD hizo lo propio, denominndolas extensiones Pacifica. Hoy en da, casi todas las computadoras de escritorio de rango medio-alto tienen el sopote necesario para llevar a cabo virtualizacin asistida por hardware. Y si bien en un principio el tema tard en
tomar traccin, llev a un replanteamiento completo de la metodologa de trabajo tanto de administradores de sistemas como de programadores.
En contraste con las arquitecturas diseadas desde un principio para la virtualizacin, los usuarios de computadoras personales (inclusive cuando estas
son servidores en centros de datos siguen estando basadadas en la misma
arquitectura bsica) se enfrentan a una mayor variedad de dispositivos para
todo tipo de tareas.6 Y si bien la virtualizacin permite aparentar varias computadoras distintas ejecutando sobre el mismo procesador, esta no incluye a
los dispositivos. Al presentarse una mquina virtual, el sistema anfitrin esta
casi siempre7 emulando hardware. Claro est, lo ms frecuente es que el hipervisor ofrezca a los huspedes la emulacin de dispositivos relativamente viejos
y simples.8 Esto no significa que estn limitados a las prestaciones del equipo
emulado (por ejemplo, a los 10Mbps para los que estaba diseada una tarjeta de red NE2000), sino que la interfaz del ncleo para enviar datos a dicho
dispositivo es una sencilla y que ha sido empleada tanto tiempo que presenta
muy poca inestabilidad.
Y este ltimo punto permite un acercamiento mayor a una de las ventajas
que ofrecen los sistemas operativos virtualizados la estabilidad. Los controladores de dispositivos provistos por fabricante han sido responsabilizados
una y otra vez, y con justa razn, de la inestabilidad de los sistemas operativos de escritorio. En particular, son en buena medida culpables de la fama de
inestabilidad que obtuvo Windows. Los fabricantes de hardware no siempre
gozan de suficiente conocimiento acerca del sistema operativo como para escribir controladores suficientemente seguros y de calidad, y por muchos aos,
los sistemas Windows no implementaban mayor verificacin al comportamiento de los controladores que, siendo un sistema monoltico, eran cdigo ejecutado con privilegios de ncleo.
Al emplear el sistema operativo husped nicamente controladores ampliamente probados y estabilizados a lo largo de muchos aos, la estabilidad que
ofrece una mquina virtualizada muchas veces supera a la que obtendra eje6 Una
descripcin completa de la complejidad a la que debe enfrentarse un hipervisor bajo arquitectura x86 excede con mucho el mbito del presente texto; se sugiere a los lectores interesados
referirse al excelente artculo de Bugnion et. al. (2012) detallando la implementacin de VMWare.
7 Hay mecanismos para reservar y dirigir un dispositivo fsico existente a una mquina virtual
especfica, pero hacerlo implica que ste dispositivo no ser multiplexado hacia las dems mquinas
virtuales que se ejecuten paralelamente.
8 Por ejemplo, KVM bajo Linux emula tarjetas de red tipo NE2000, tarjetas de sonido tipo Soundblaster16 y tarjetas de video Cirrus Logic, todos ellos de la dcada de los 1990.
316
APNDICE B. VIRTUALIZACIN
B.4.
Paravirtualizacin
B.4. PARAVIRTUALIZACIN
B.4.1.
317
La paravirtualizacin resulta muy atractiva, presentando muy obvias ventajas. Pero a pesar de que es posible emplearla en cualquier arquitectura hardware, no siempre es posible emplearla.
Como se mencion anteriormente, incorporar dentro de un sistema operativo el soporte para una arquitectura de paravirtualizacin es casi equivalente
a traducirlo a una nueva arquitectura hardware. Para que los autores de un
entorno que implemente paravirtualizacin logren que un sistema operativo
nuevo pueda ser ejecutado en su arquitectura, deben poder manipular y modificar su cdigo fuente: de otra manera, cmo se le podra adecuar para que
supiera desenvolverse en un entorno no nativo?
El proyecto de gestin de virtualizacin y paravirtualizacin Xen naci como un proyecto acadmico de la Universidad de Cambridge, presentando su
versin 1.x a travs de un artculo en 2003 (ver Xen and the Art of Virtualization). Este artculo presenta su experiencia paravirtualizando a una versin
entonces actual de Linux y de Windows XP. Sin embargo, Xen slo pudo ser
empleado por muchos aos como plataforma de paravirtualizacin de Linux
porque, dado que la adaptacin de Windows se realiz bajo los trminos del
Academic Licensing Program, que permita a los investigadores acceso y modificacin al cdigo fuente, pero no su redistribucin la versin paravirtualizable de Windows XP existe, pero no puede distribuirse fuera de los participantes de dicho programa de licenciamiento.
En tanto, el trabajo necesario para lograr la paravirtualizacin de un sistema operativo libre, como Linux, FreeBSD u otros, puede ser libremente redistribudo. No slo eso, sino que el esfuerzo de realizar la adaptacin pudo
compartirse entre desarrolladores de todo el mundo, dado que esta entonces
novedosa tecnologa resultaba de gran interes.
B.4.2.
Paravirtualizacin de dispositivos
318
APNDICE B. VIRTUALIZACIN
drivers paravirtuales. Por supuesto, varios aspectos que son parte del ncleo
duro del sistema, como la administracin de memoria o el manejo de interrupciones (incluyendo al temporizador) tendrn que seguirse manejando a travs
de una emulacin, aunque mucho ms delgada.
Segn mediciones empricas realizadas en 2007 por Qumranet (quienes liderearon el desarrollo del mdulo de virtualizacin asistido por hardware KVM
en Linux), las clases de dispositivos virtio y pv resultaron entre 5 y 10 veces
ms rpidas que la emulacin de dispositivos reales.
Mediante esta estrategia es posible ejecutar sistemas operativos propietarios, como los de la familia Windows, con buena parte de las ventajas de la
paravirtualizacin, sobre entornos de virtualizacin asistida por hardware.
B.5.
Contenedores
Una estrategia completamente distinta para la creacin de mquinas virtuales es la de contenedores. A diferencia de emulacin, virtualizacin asistida
por hardware y paravirtualizacin, al emplear contenedores slo se ejecuta un
sistema operativo, que es el mismo para los sistemas anfitrin y huesped. El anfitrin implementar una serie de medidas para aumentar el grado de separacin
que mantiene entre procesos, agregando la nocin de contextos o grupos que
se describirn en breve. Dado que el sistema operativo es el nico autorizado
para tener acceso directo al hardware, no hace falta ejecutar un hipervisor.
Podra presentarse un smil: las tecnologas antes descritas de virtualizacin
implementan hardware virtual para cada sistema operativo, mientras que los
contenedores ms bien presentan un sistema operativo virtual para el conjunto
de procesos que definen el comportamiento de cada mquina virtual muchos autores presentan a la virtualizacin por contenedores bajo el nombre virtualizacin a nivel sistema operativo. Y si bien el efecto a ojos del usuario puede
ser comparable, este mtodo ms que una multiplexacin de mquinas virtuales sobre hardware real opera a travs de restricciones adicionales sobre los
procesos de usuario.
Al operar a un nivel ms alto, un contenedor presenta algunas limitantes
adicionales (principalmente, se pierde la flexibilidad de ejecutar sistemas operativos distintos), pero obtiene tambin importantes ventajas.
El desarrollo histrico de los contenedores puede rastrearse a la llamada
al sistema chroot(), que restringe la visin del sistema de archivos de un
proceso a slo el directorio hacia el cual sta fue invocada.10 Esto es, si dentro
de un proceso se invoca chroot(/usr/local) y posteriormente se le pide
10 La llamada chroot() fue creada por Bill Joy en 1982 para ayudarse en el desarrollo del sistema Unix 4.2BSD. Joy buscaba probar los cambios que iba haciendo en los componentes en espacio de usuario del sistema sin modificar su sistema vivo y en produccin, esto es, sin tener que
reinstalar y reiniciar cada vez, y con esta llamada le fue posible instalar los cambios dentro de un
directorio especfico y probarlos como si fueran en la raiz.
B.5. CONTENEDORES
319
abrir el archivo /boot.img, a pesar de que ste indique una ruta absoluta, el
archivo que se abrir ser /usr/local/boot.img
Ahora bien, chroot() no es (ni busca ser) un verdadero aislamiento, slo proporciona un inicio11 pero conforme ms usuarios comenzaban a utilizarlo para servicios en produccin, se hizo claro que resultara til ampliar la
conveniencia de chroot() a un verdadero aislamiento.
El primer sistema en incorporar esta funcionalidad fue FreeBSD, creando
el subsistema Jails a partir de su versin 4.0, del ao 2000. No tardaron mucho en aparecer implementaciones comparables en los distintos sistemas Unix.
Hay incluso un producto propietario, el Parallels Virtuozzo Containers, que implementa esta funcionalidad para sistemas Windows.
Un punto importante a mencionar cuando se habla de contenedores es que
se pierde buena parte de la universalidad mencionada en las secciones anteriores. Si bien las diferentes implementaciones comparten principios bsicos de
operacin, la manera en que implementan la separacin e incluso la nomenclatura que emplean difieren fuertemente.
El ncleo del sistema crea un grupo para cada contenedor (tambin conocido
como contexto de seguridad), aislndolos entre s por lo menos en los siguientes
reas:
Tablas de procesos Los procesos en un sistema Unix se presentan como un
rbol, en cuya raiz est siempre el proceso 1, init. Cada contenedor inicia su existencia ejecutando un init propio y enmascarando su identificador de proceso real por el nmero 1.
Seales, comunicacin entre procesos Ningn proceso de un contenedor debe
poder interferir con la ejecucin de uno en otro contenedor. El ncleo restringe toda comunicacin entre procesos, regiones de memoria compartida y envo de seales entre procesos de distintos grupos.
Interfaces de red Vara segn cada sistema operativo e implementacin, pero
en lneas generales, cada contenedor tendr una interfaz de red con una
direccin de acceso a medio (MAC) distinta.12 Claro est, cada una de ellas
recibir una diferente direccin IP, y el ncleo rutear e incluso aplicar
reglas de firewall entre ellas.
Dispositivos de hardware Normalmente los sistemas huesped no tienen acceso directo a ningn dispositivo en hardware. En algunos casos, el acceso
a dispositivos ser multiplexado, y en otros, un dispositivo puede especificarse a travs de su configuracin. Cabe mencionar que, dado que esta
multiplexin no requiere emulacin sino que nicamente una cuidadosa
planificacin, no resulta tan oneroso como la emulacin.
11 Como referencia a por qu no es un verdadero aislamiento, puede referirse al artculo How to
break out of a chroot() jail (Simes, 2002)
12 Es comn referirse a las direcciones MAC como direcciones fsicas, sin embargo, todas las
tarjetas de red permiten configurar su direccin, por lo cual la apelacin fsica resulta engaosa.
320
APNDICE B. VIRTUALIZACIN
B.6.
Ejercicios
B.6.1.
Preguntas de autoevaluacin
1. En este captulo se presentaron diversas tecnologas para la virtualizacin: emulacin, virtualizacin asistida por hardware, paravirtualizacin y contenedores. Las cuatro categoras tienen su lugar y casos de
uso recomendados. Elabore un cuadro comparativo, presentando las ventajas y desventajas relativas de cada categora respecto a las dems.
2. A continuacin se presentan varias afirmaciones. Evale si cada una de
ellas es verdadera o falsa, sustentando con argumentos su conclusin.
La emulacin implica naturalmente el implementar un intrprete
del cdigo que fue originado para una arquitectura distinta. Este
proceso necesariamente tiene un alto costo en tiempo de cmputo, y
una infraestructura basada en emulacin siempre ser por lo menos
un rden de magnitud ms lenta que lo que resultara de su ejecucin nativa. La popularizacin de la emulacin deriva por un lado
de la diferencia de poder de cmputo entre las arquitecturas de escritorio y las embebidas, y por el otro de la conveniencia de contar
con cdigo que pueda ser transportado fcilmente (write once, run
anywhere).
La Ley de Moore (presentada en la seccin 2.9.1) ha llevado a una cada vez mayor integracin y ha llevado a que el desarrollo del cmputo por fin cruzara obligadamente por el multiprocesamiento, el
B.6. EJERCICIOS
321
322
APNDICE B. VIRTUALIZACIN
B.6.2.
B.6.3.
Lecturas relacionadas
B.6. EJERCICIOS
323
Avi Kivity, Yaniv Kamay, Dor Laor, Uri Lublin, Anthony Liguori (2007)
Qumranet / IBM)
KVM PV devices
http://www.linux-kvm.org/wiki/images/d/dd/KvmForum2007$kvm_pv_
drv.pdf
Simes (2002)
Notes from a container
http://lwn.net/Articles/256389/
324
APNDICE B. VIRTUALIZACIN
Apndice C
El medio fsico y el
almacenamiento
C.1.
El medio fsico
A lo largo del presente texto, particularmente de los captulos 6 y 7 y siguiendo las prcticas a que ha impuesto la realidad de los ltimos 40 aos, el
trmino genrico de disco se ha empleado prcticamente como sinnimo de
medio de almacenamiento a largo plazo.
En este apndice se abordan en primer trmino las caractersticas principales del medio an prevalente, los discos duros magnticos rotativos, y una
introduccin a las diferencias que presentan respecto a otros medios, como
los discos pticos y los de estado slido, as como las implicaciones que stos
tienen sobre el material presentado en el captulo 7.
Cabe mencionar que la razn de separar este contenido hacia un apndice
es que, si bien estas funciones resultan relevantes para los sistemas operativos y
estos cada vez ms van asumiendo las funciones que aqu sern descritas, estas
comenzaron siendo implementadas por hardware especializado; fue apenas
hasta la aparicin de los esquemas de manejo avanzado de volmenes (que
sern cubiertos en la seccin C.3) que entran al mbito del sistema operativo.
C.1.1.
326
mayor capacidad y son mucho ms rpidos, pero a cambio de ello, son correspondientemente ms sensibles a la contaminacin por partculas de polvo y a
daos mecnicos, razn por la cual hoy en da se venden, junto con el mecanismo lector e incluso la electrnica de control, en empaque sellado.
Un disco flexible es una hoja de material plstico, muy similar al empleado
en las cintas magnticas, resguardado por un estuche plstico. Al insertarse
el disco en la unidad lectora, esta lo hace girar sujetndolo por el centro, y
las cabezas lectoras (en un principio una sola; posteriormente aparecieron las
unidades de doble cara, con dos cabezas lectoras) se deslizan por una ventana
que tiene el estuche.
La mayor parte de los discos flexibles presentaban velocidades de rotacin
de entre 300 y 400 revoluciones por minuto presentaban, pues, una demora
rotacional de entre 0.15 y 0.2 segundos. La demora rotacional es el tiempo que
toma la cabeza lectora en volver a posicionarse sobre un mismo sector del disco. (Ver figura C.1)
A lo largo de ms de 20 aos se presentaron muy diferentes formatos fsicos siguiendo esta misma lgica, designndose principalmente por su tamao
(en pulgadas). La capacidad de los discos, claro est, fue creciendo con el paso
de los aos esto explica la aparente contradiccin de que los discos (fsicamente) ms chicos tenan ms capacidad que los ms grandes.
Cuadro C.1: Principales formatos de disco flexible que se popularizaron en el mercado
Fecha de introduccin
Capacidad
Velocidad (kbit/s)
Pistas por pulgada
8 pulgadas
1971
150KB-1.2MB
33
48
5.25 pulgadas
1976
110KB-1.2MB
125-500
48-96
3.5 pulgadas
1982
264KB-2.88MB
250-1000
135
327
periores a la de los discos flexibles: los primeros discos duros que se comercializaron para computadoras personales eran de 10MB (aproximadamente 70
discos flexibles de su poca), y actualmente hay ya discos de 4TB. La velocidad mxima de transferencia sostenida hoy en da es superior a los 100MB por
segundo, 100 veces ms rpido que la ltima generacin de discos flexibles.
Para medir la eficiencia de un disco duro, adems de la demora rotacional
presentada unos prrafos atrs, el otro dato importante es el tiempo que toma
la cabeza en moverse a travs de la superficie del disco. Hoy en da, las velocidades ms comunes son de 20ms para un recorrido completo (desde el primer
hasta el ltimo sector), y entre 0.2ms y 0.8ms para ir de un cilindro al inmediato
siguiente. Como punto de comparacin, el recorrido completo en una unidad
de disco flexible toma aproximadamente 100ms, y el tiempo de un cilindro al
siguiente va entre 3 y 8ms.
Notacin C-H-S
En un principio y hasta la dcada de los noventa, el sistema operativo siempre haca referencia a la ubicacin de un bloque de informacin en el disco
es conocido como la notacin C-H-S indicando el cilindro, cabeza y sector
(Cylinder, Head, Sector) para ubicar a cada bloque de datos. Esto permite mapear el espacio de almacenamiento de un disco a un espacio tridimensional,
con cual resulta trivial ubicar a un conjunto de datos en una regin contigua.
328
norma), pero en un disco duro es comn tener varios platos paralelos. Todas las
cabezas van fijas a un mismo motor, por lo que no pueden moverse de forma
independiente.
El cilindro indica la distancia del centro a la orilla del disco. Al cilindro tambin se le conoce como pista (track), una metfora heredada de la poca en que
la msica se distribua principalmente en discos de vinil, y se poda ver a simple vista la frontera entre una pista y la siguiente.
Un sector es un segmento de arco de uno de los cilindros, y contiene siempre
la misma cantidad de informacin (histricamente 512 bytes; en actualmente
se estn adoptando gradualmente sectores de 4096 bytes. Refirase a la seccin
C.1.1 para una mayor discusin al respecto.)
Un archivo almacenado secuencialmente ocupa sectores adyacentes a lo largo
de una misma pista y con una misma cabeza.
Algoritmos de planificacin de acceso a disco
Las transferencias desde y hacia los discos son uno de los procesos ms
lentos de los que gestiona el sistema operativo. Cuando ste tiene varias solicitudes de transferencia pendientes, resulta importante encontrar un mecanismo ptimo para realizar la transferencia, minimizando el tiempo de demora. A
continuacin se describirn a grandes rasgos tres de los algoritmos histricos
de planificacin de acceso a disco para abordar despus el por qu estos hoy
en da casi no son empleados.
Como con los dems escenarios en que se han abordado algoritmos, para
analizar su rendimiento, el anlisis se realizar sobre una cadena de referencia.
Este ejemplo supone un disco hipottico de 200 cilindros, la cadena de solicitudes 83, 175, 40, 120, 15, 121, 41, 42, y teniendo la cabeza al inicio de la operacin en el cilindro 60.
En la figura C.2 puede apreciarse de forma grfica la respuesta que presentaran los distintos algoritmos ante la cadena de referencia dada.
FIFO Del mismo modo que cuando fueron presentados los algoritmos de asignacin de procesador y de reemplazo de pginas, el primero y ms sencillo de implementar es el FIFO primero llegado, primero servido.
Este algoritmo puede verse como muy justo, aunque sea muy poco eficiente: el movimiento total de cabezas para el caso planteado es de 622
cilindros, equivalente a poco ms que recorrer de extremo a extremo el
disco completo tres veces. Esto es, despreciando la demora rotacional la
demora mecnica para que el brazo se detenga por completo antes de
volver a moverse, esta lectura tomara un mnimo de 60ms, siendo el
recorrido completo del disco 20ms.
Puede identificarse como causante de buena parte de esta demora a la
quinta posicin de la cadena de referencia: entre solicitudes para los cilindros contiguos 120 y 121, lleg una solicitud al 15.
329
Figura C.2: Movimientos de las cabezas bajo los diferentes algoritmos planificadores de acceso a disco, indicando la distancia total recorrida por la cabeza bajo
cada uno, iniciando con la cabeza en la posicin 60. Para SCAN, LOOK y C-SCAN,
se asume que la cabeza inicia avanzando en direccin decreciente.
330
Familia de algoritmos de elevador (SCAN, LOOK, C-SCAN) En este tercer lugar se abordar ya no un slo algoritmo, sino que una familia, dado que
parten de la misma idea, pero con modificaciones menores llevan a que
el patrn de atencin resultante sea muy distinto.
El planteamiento base para el algoritmo bsico de elevador (SCAN) busca evitar la inanicin, minimizando al mismo tiempo el movimiento de
las cabezas. Su lgica indica que la cabeza debe recorrer el disco de extremo a extremo, como si fuera un elevador en un edificio alto, atendiendo a todas las solicitudes que haya pendientes en su camino. Si bien los
recorridos para ciertos patrones pueden resultar en mayores desplazamientos a los que dara SSTF, la garanta de que ningn proceso esperar
indefinidamente lo hace muy atractivo.
Atender la cadena de referencia bajo SCAN, asumiendo un estado inicial
descendente (esto es, la cabeza est en el cilindro 60 y va bajando) da un
recorrido total de 235 cilindros; empleando LOOK, se reduce a 205 cilindros, y evita el movimiento innecesario hasta el lmite del disco.
Una primer (y casi obvia) modificacin a este algoritmo sera, cada vez
que la cabeza se detenga para satisfacer una solicitud, verificar si hay
alguna otra solicitud pendiente en la direccin actual, y de no ser as, emprender el camino de regreso sin llegar a la orilla del disco. Esta modificacin es frecuentemente descrita como LOOK.
Sin embargo, el patrn de atencin a solicitudes de SCAN y LOOK dejan qu desear: al llegar a un extremo del recorrido, es bastante probable
que no haya ninguna solicitud pendiente en la primer mitad del recorrido de vuelta (dado que acaban de ser atendidas). El tiempo que demora
atender a una solictud se compone de la suma del desplazamiento de la
cabeza y la demora rotacional (que depende de cul sector del cilindro
fue solicitado). Para mantener una tasa de transferencia ms predecible,
el algoritmo C-SCAN (SCAN Circular) realiza las operaciones en el disco
nicamente en un sentido si el algoritmo lee en orden descendente, al
llegar a la solicitud del cilindro ms bajo, saltar de vuelta hasta el ms
alto para volver a iniciar desde ah. Esto tiene como resultado, claro, que
el recorrido total aumente (aumentando hasta los 339 para la cadena de
referencia presentada).
331
332
Sectores variables por cilindro En casi todos los discos previos a LBA,1 el
nmero de sectores por pista se mantena constante, se tratara de las pistas ms internas o ms externas. Esto significa que, a igual calidad de la
cobertura magntica del medio, los sectores ubicados en la parte exterior
del disco desperdiciaban mucho espacio (ya que el rea por bit era mucho
mayor).
Figura C.3: Disco formateado bajo densidad de bits por zona, con ms sectores por
pista en las pistas exteriores. (Imagen de la Wikipedia: Zone Bit Recording)
Bajo LBA, los discos duros comenzaron a emplear un esquema de densidad de bits por zona (zone bit recording), con la que en los cilindros ms
externos se aumenta.
Reubicacin de sectores Conforme avanza el uso de un disco, es posible que
algunos sectores vayan resultando difciles de leer por daos microscpicos a la superficie. El controlador es capaz de detectar estos problemas, y
de hecho, casi siempre puede rescatar la informacin de dichos sectores
de forma imperceptible al usuario.
Los discos duros ST-506 tpicamente iban acompaados por una lista de
defectos, una lista de coordenadas C-H-S que desde su fabricacin haban
presentado errores. El usuario deba ingresar estos defectos al formatear
el disco a bajo nivel.
Hoy en da, el controlador del disco detecta estos fallos y se los salta,
presentando un mapa LBA lineal y completo. Los discos duros tpicamente vienen con cierto nmero de sectores de reserva para que, conforme
1 Las unidades de disco Commodore 1541 y Macintosh Superdrive, que empleaban velocidad variable por cilindro para aprovechar mejor el medio magntico, constituyen notorias excepciones; en
ambos casos, sin embargo, terminaron desapareciendo por cuestiones de costos y de complejidad
al sistema.
333
C.1.2.
334
335
Figura C.5: Unidad de estado slido basado en Flash con interfaz SATA (Imagen
de la Wikipedia: Solid state drive)
336
Figura C.6: Unidad de estado slido basado en Flash con interfaz USB (Imagen de
la Wikipedia: Solid state drive)
Independientemente del tipo, las unidades de estado slido presentan ventajas ante los discos rotativos, como un muy bajo consumo elctrico, operacin
completamente silenciosa, y resistencia a la vibracin o a los golpes. Adems, el
medio es verdaderamente de acceso aleatorio: al no ser ya un disco, desaparecen
tanto la demora de movimiento de cabezas como la rotacional.
Desgaste del medio
La memoria Flash presenta patrones de desgaste muy distintos de los que
presentan otros medios. La memoria Flash tiene capacidad de aguantar un
cierto nmero de operaciones de borrado por pgina6 antes de comenzar a
degradarse y fallar. Las estructuras tradicionales de sistemas de archivos basados en disco concentran una gran cantidad de modificaciones frecuentes a lo
largo de la operacin normal del sistema en ciertas regiones clave: las tablas de
asignacin y directorios registran muchos ms cambios que la regin de datos.
Casi todos los controladores de discos Flash cuentan con mecanismos de
nivelamiento de escrituras (write leveling). Este mecanismo busca reducir el desgaste focalizado modificando el mapeo de los sectores que ve el sistema operativo respecto a los que son grabados en verdad en el medio: en vez de actualizar
un bloque (por ejemplo, un directorio) en su lugar, el controlador le asigna un
nuevo bloque de forma transparente, y marca el bloque original como libre.
Los mecanismos ms simples de nivelamiento de escrituras lo hacen nicamente intercambiando los bloques libres con los recin reescritos; mecanismos
ms avanzados buscan nivelar el nivel de reescritura en toda la unidad reubicando peridicamente tambin a los bloques que no son modificados, para no
favorecerlos injustamente y hacer un mejor balanceo de uso.
6 Dependiendo
337
Emulacin de discos
Hoy en da, casi la totalidad de medios de estado sldo se presentan ante
el sistema con una interfaz que emula la de los discos, la FTL (Flash Translation
Layer, Capa de Traduccin de Flash). La ventaja de esta emulacin es que no hizo falta desarrollar controladores adicionales para comenzar a emplear estos
medios. La desventaja, sin embargo, es que al ocultarse el funcionamiento real
de las unidades de estado slido, el sistema operativo no puede aprovechar las
ventajas estructurales y ms importante an, no puede evitar las debilidades
inherentes al medio.
Uno de los ejemplos ms claros de esta falta de control real del medio la
ilustra el artculo de Valerie Aurora (2009), que menciona que tanto la poca
informacin pblicamente disponible acerca del funcionamiento de los controladores como los patrones de velocidad y desgaste de los mismos apuntan a
que la estructura subyacente de casi todos los medios de estado slido es la de
un sistema de archivos estructurado en bitcora. Aurora indica que hay varias operaciones que no pueden ser traducidas eficientemente a travs de esta capa de
emulacin, y que seguramente permitiran un mucho mejor aprovechamiento
del medio. Como se mencion en la seccin 7.3.5 (Sistemas de archivo estructurados en bitcora), si bien varios de estos sistemas de archivos han presentado
implementaciones completamente utilizables, la falta de inters ha llevado a
que muchos de estos proyectos sean abandonados.
En su artculo de 2012, Neil Brown apunta a que Linux tiene una interfaz
apta para hablar directamente con dispositivos de estado slido, llamada mtd
memory technology devices, dispositivos de tecnologa de memoria.
Si bien los discos duros se han empleado por ya 50 aos y los sistemas de
archivos estn claramente desarrollados para aprovechar sus detalles fsicos y
lgicos, el uso de los dispositivos de estado slido apenas est despegando en
la ltima dcada. Y si bien esta primer aproximacin que permite emplear esta
tecnologa transparentemente es suficientemente buena para muchos de los usos
bsicos, sin duda hay espacio para mejorar. Este es un tema que seguramente
brinda amplio espacio para investigacin y desarrollo para los prximos aos.
C.2.
338
C.2.1.
El primer nivel de RAID brinda una ganancia tanto en espacio total, dado que presenta a un volumen grande en vez de varios discos ms pequeos
(simplificando la tarea del administrador) como de velocidad, dado que las lecturas y escrituras al volumen ya no estarn sujetas al movimiento de una sola
cabeza, sino que habr una cabeza independiente por cada uno de los discos
que conformen al volumen.
339
al espaol se refieren a este proceso como bandeado). Esto hace que la carga
se reparta de forma uniforme entre todos los discos, y asegura que todas las
transferencias mayores al tamao de una franja provengan de ms de un disco
independiente.
C.2.2.
340
C.2.3.
C.2.4.
El nivel 5 de RAID proporciona un muy buen equilibrio respecto a las caractersticas que se han mencionando: brinda el espacio total de almacenamiento
de todos los discos que formen parte del volumen menos uno. Para cada una de
las franjas, RAID5 calcula un bloque de paridad.
Para obtener una mayor tolerancia a fallos, este bloque de paridad no siempre va al mismo disco, sino que se va repartiendo entre todos los discos del
volumen, desplazndose a cada franja, de modo que cualquiera de los discos puede
fallar, y el arreglo continuar operando sin prdida de informacin. Esta debe
notificarse al administrador del sistema, quien reemplazar al disco daado lo
antes posible (dado que, de no hacerlo, la falla en un segundo disco resultar
en la prdida de toda la informacin).
En equipos RAID profesionales es comn contar con discos de reserva en
caliente (hot spares): discos que se mantienen apagados pero listos para trabajar.
Si el controlador detecta un disco daado, sin esperar a la intervencin del
administrador, desactiva al disco afectado y activa al hot spare, reconstruyendo
de inmediato la informacin a partir de los datos en los discos sanos.
341
fallo de lectura, cuando el sistema requiere leer datos, estos pueden ser solicitados nicamente a n 1 discos (e ignorar al de paridad); si el arreglo RAID
est configurado para verificar la paridad en lecturas, todas las lecturas tendrn que obtener la franja correspondiente de todos los discos del arreglo para
poder calcularla.
RAID 5 opera con un algoritmo de verificacin y recuperacin sorprendentemente eficiente y simple: el de una suma XOR, ilustrado en la figura C.11. La
operacin booleana XOR (de Exclusive OR) suma los bits individuales, columna por columna. Si es un nmero par, almacena un 0, si es impar, almacena un
1. Esta operacin es muy eficiente computacionalmente.
Figura C.11: Para cada franja, el disco de paridad guarda la suma XOR de los bits
de las franjas correspondientes de los otros discos; no importa cul disco falle, sus
datos pueden recuperarse haciendo un XOR de los datos de los dems.
Las escrituras son invariablemente ms lentas respecto tanto ante la ausencia de RAID como en niveles 0 y 1, dado que siempre tendr que recalcularse
la paridad; en el caso de una escritura mnima (menor a una franja) tendr que
leerse la franja entera de todos los discos participantes en el arreglo, recalcularse la paridad, y grabarse en el disco correspondiente.
Cuando uno de los discos falla, el arreglo comienza a trabajar en el modo
interino de recuperacin de datos (Interim data recovery mode, tambin conocido
como modo degradado), en el que todas las lecturas involucran a todos los discos,
ya que tienen que estar recalculando y rellenando la informacin que provendra
del disco daado.
Para implementar RAID nivel 5 son necesarios por lo menos 3 discos,
aunque es comn verlos ms anchos, pues de este modo se desperdicia menos
espacio en paridad. Si bien tericamente un arreglo nivel 5 puede ser arbitrariamente ancho, en la prctica es muy raro ver arreglos con ms de 5 discos: tener
un arreglo ms ancho aumentara la probabilidad de falla. Si un arreglo que est ya operando en el modo interino de recuperacin de datos se encuentra con
una falla en cualquiera de sus discos, tendr que reportar un fallo irrecuperable.
342
Figura C.12: Cinco discos organizados en RAID 5. La franja de paridad se va alternando, repartindose entre todos los discos.
C.2.5.
Figura C.13: Cinco discos organizados en RAID 6. Al igual que bajo RAID 5, las
franjas de paridad se van alternando entre todos los discos.
C.2.6.
343
Con RAID nivel 10 se crean volmenes que suman por franjas unidades en
espejo (un volumen RAID 0 compuesto de varios volmenes RAID 1). En caso
de fallar cualquiera de las unidades del arreglo, sta puede ser reemplazada fcilmente, y su reemplazo no significar un trabajo tan intensivo para el arreglo
entero (slo para su disco espejo).
Bajo este esquema, en el peor de los casos, un volumen con n discos fsicos est conformado por n2 volmenes nivel 1, y por tanto puede soportar la
prdida de hasta n2 discos siempre que estos no formen parte de un mismo
volumen nivel 1.
Esta combinacin ilustra cmo el orden de los factores s altera al producto:
si en vez de la concatenacin de varias unidades espejeadas (un volumen nivel
0 compuesto de varios volmenes nivel 1) se armara el arreglo en orden inverso
344
(esto es, como el espejeo de varias unidades concatenadas por franjas), ante un
primer anlisis parecera se obtienen los mismos beneficios pero analizando
lo que ocurre en caso de falla, resulta claro que el nivel de redundancia resulta
mucho menor.
Figura C.15: Seis discos organizados en RAID 0+1, ilustrando cmo una combinacin errnea puede reducir la tolerancia mxima a fallos del arreglo
C.3.
345
C.3.1.
Una evolucin natural de los conceptos de RAID es el LVM2 (segunda generacin del Logical Volume Manager, o Gestor de Volmenes Lgicos) de Linux. La
lgica de operacin de LVM est basada en los siguientes conceptos:
Volumen fsico Cada uno de los discos o unidades disponibles.
Grupo de volmenes Conjunto de volmenes fsicos que sern administrados
como una sola entidad.
Volumen lgico Espacio dentro del grupo de volmenes que se presenta como
un dispositivo, y que puede alojar sistemas de archivos.
El esquema es limpio y elegante: LVM es una interfaz que permite, como dos pasos independientes, agregar diferentes volmenes fsicos a un grupo
de volmenes, para posteriormente y siguiendo las necesidades del administrador del sistema, ya independientes del tamao de las unidades fsicamente
existentes crear las unidades lgicas, donde se alojarn los sistemas de archivos
propiamente.
Este esquema permite naturalmente una funcionalidad comparable con
RAID 0: puede crearse un grupo de volmenes con todos los discos que
disponibles, y dentro de este crear un volumen lgico nico. Dependiendo de
la configuracin, este volumen lgico puede crecer abarcando todos los discos
en cuestin, sea como simple concatenacin o dividindose en franjas.
Permite tambin la creacin de unidades espejo, con una operacin a
grandes rasgos equivalente a la de RAID1. Incluso, dentro de un mismo grupo
de volmenes, pueden existir tanto volmenes lgicos espejeados como otros
que no lo estn, a diferencia de la estricta rigidez de RAID.
Para los niveles 4, 5 y 6 de RAID, la correspondencia es ms directa an: al
crear un volumen, se le puede solicitar a LVM al crear un volumen lgico que
cree un volumen con ese nivel de RAID obviamente, siempre que cuente
con suficientes volmenes fsicos.
El esquema de LVM no brinda, pues, funcionalidad estrictamente distinta
a la que presenta RAID pero da al administrador del sistema flexibilidad:
ampliar o reducir el espacio dedicado a cada uno de los volmenes, incluso en
un sistema en produccin y con datos.
LVM ofrece varias funcionalidades adicionales, como las fotografas (snapshots) o varios esquemas de reemplazo de disco; si bien hay mucho ms que
podra decirse de LVM, no se profundiza ms en esta herramienta dado que
excede del objetivo del presente material.
346
C.3.2.
ZFS
Si bien LVM realiza una importante tarea de simplificacin en la administracin del sistema, su operacin sigue siendo orientada a bloques: los
volmenes lgicos deben an ser formateados bajo el sistema de archivos que
el administrador del sistema considere acorde para la tarea requerida.
ZFS9 fue desarrollado por Sun Microsystems desde el ao 2001, forma parte
del sistema operativo Solaris desde el 2005, y hoy en da puede emplearse desde los principales sistemas operativos libres.10 Y si bien ZFS resulta suficientemente atractivo tan slo por haber sido diseado para que el usuario nunca
ms se tope con un lmite impuesto por el sistema operativo, el principal cambio que presenta al usuario es una forma completamente distinta de referirse
al almacenamiento.
En primer trmino, al igual que LVM presenta una primer integracin entre conceptos, permitiendo unir de diferentes maneras varios dispositivos fsicos en un dispositivo lgico, ZFS incluye en la misma lgica administrativa al
sistema de archivos: en la configuracin estndar, basta conectar una unidad
al sistema para que sta aparezca como espacio adicional disponible para los
usuarios. El espacio combinado de todas las unidades conforma un fondo de
almacenamiento (storage pool).
La lgica de ZFS parte de que operar una coleccin de sistemas de archivos
en una organizacin jerrquica. Pero a diferencia del esquema tradicional Unix
en que cada sistema de archivos es preparado desde un principio para su funcin, en ZFS se pueden aplicar lmites a jerarquas completas. Bajo un esquema
ZFS, la creacin y el montaje de un sistema de archivos es una operacin sencilla al grado que se presenta como recomendacin que, para cada usuario
en el sistema, se genere un sistema de archivos nuevo e independiente.
Una de las principales diferencias con los sistemas de archivos tradicionales
es el manejo del espacio vaco: el espacio disponible total del fondo de almacenamiento se reporta como disponible para todos los sistemas de archivos que
formen parte de ste. Sin embargo, se pueden indicar reservas (mantener un
mnimo del espacio especificado disponible para determinado subconjunto de
sistemas de archivos dentro de la coleccin) y lmites (evitar que el uso de
una coleccin exceda el almacenamiento indicado) para las necesidades de las
diferentes regiones del sistema.
9 El nombre ZFS proviene de Zettabyte File System. Los diseadores de ZFS indican, sin embargo,
que esto no es para indicar que ZFS sea capaz de direccionar hasta zettabytes de informacin, sino
que ser el ltimo sistema de archivos que cualquier administrador requerir.
10 ZFS no puede ser incorporado ntegramente al ncleo de Linux por incompatibilidad de licencias:
si bien ambos son software libre, los modelos de licenciamiento GPL (de Linux) y CDDL (de ZFS)
son incompatibles.
C.4. EJERCICIOS
C.4.
Ejercicios
C.4.1.
Preguntas de autoevaluacin
347
1. Se presentaron algunos algoritmos para gestionar las solicitudes de acceso a disco Primero llegado, primero servido (FIFO), Tiempo ms corto
a continuacin (SSTF), Elevador (SCAN), y algunas de sus variaciones. Se
mencion tambin que, a pesar de la importancia de conocerlos por su
importancia histrica, hoy en da han dejado de ser tan importantes como lo fueron hacia los 1980. Mencione dos factores que han llevado a que
pierdan relevancia.
2. Realice un esquema de cmo se estructura cada bloque de informacin
sobre varios discos bajo RAID niveles 0, 1 y 5. Para cada uno de estos
niveles, indique el impacto que su empleo tendra en cuanto a espacio
total, velocidad de acceso y confiabilidad.
C.4.2.
C.4.3.
Lecturas relacionadas
http://constantin.glez.de/blog/2010/03/opensolaris-zfs-deduplication-everything-you-need-
FreeBSD Handbook
A hash-based DoS attack on Btrfs
http://lwn.net/Articles/529077/
348
ndice de figuras
1.1. La microcomputadora Altair 8800, primer computadora personal
con distribucin masiva, a la venta a partir de 1975. (Imagen de
la Wikipedia: Altair 8800) . . . . . . . . . . . . . . . . . . . . . . .
1.2. La Commodore Pet 2001, en el mercado desde 1977, una de las
primeras con intrprete de BASIC. (Imagen de la Wikipedia:
Commodore PET) . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3. La computadora IBM PC modelo 5150 (1981), iniciadora de la arquitectura predominantemente en uso hasta el da de hoy. (Imagen de la Wikipedia: IBM Personal Computer) . . . . . . . . . . .
1.4. Apple Macintosh (1984), populariz la interfaz usuario grfica
(GUI). (Imagen de la Wikipedia: Macintosh) . . . . . . . . . . . .
1.5. Commodore Amiga 500 (1987), la computadora ms popular de
la familia Amiga, con amplias capacidades multimedia y multitarea apropiativa; una verdadera maravilla para su momento.
(Imagen de la Wikipedia: Amiga) . . . . . . . . . . . . . . . . . .
1.6. Psion Organiser, anunciada como la primer computadora de bolsillo
prctica del mundo en 1984. En la imagen, un dispositivo de su
segunda generacin. (Imagen de la Wikipedia: Psion Organiser) .
1.7. Sharp ZQ-770, diseo bajo uno de los formatos de PDA (Asistente Personal Digital) ms popularizados de la dcada de los
90. (Imagen de la Wikipedia: Sharp Wizard) . . . . . . . . . . . .
1.8. El iPhone, de Apple, introdujo la primer interfaz usuario multitouch y deton la popularidad de los telfonos inteligentes Y
con ello, del cmputo mvil (Imagen de la Wikipedia: iPhone 2)
1.9. Esquematizacin de los componentes en un sistema monoltico
1.10. Esquematizacin de los componentes en un sistema microkernel
1.11. Esquematizacin de los componentes en un sistema hbrido . .
2.1. Jerarqua de memoria entre diversos medios de almacenamiento.
2.2. Ejemplo de registros: Intel 8086/8088 (Imagen de la Wikipedia:
Intel 8086 y 8088) . . . . . . . . . . . . . . . . . . . . . . . . . . .
349
21
21
22
23
24
26
27
28
36
37
37
43
45
350
NDICE DE FIGURAS
2.3. Diagrama de la comunicacin entre componentes de un sistema
de cmputo basado en puente norte y puente sur. Imagen de la
Wikipedia: Puente Norte . . . . . . . . . . . . . . . . . . . . . . .
2.4. Esquema simplificado del chipset Intel 875 (para el procesador
Pentium 4) ilustrando la velocidad de cada uno de los canales .
2.5. Transicin del flujo entre espacio usuario y espacio ncleo en
una llamada al sistema . . . . . . . . . . . . . . . . . . . . . . . .
2.6. Esquema de la ejecucin de tres procesos en un sistema secuencial, multiprogramado, multiprocesado, e hbrido . . . . . . . .
2.7. La Ley de Moore, en su artculo publicado en 1965, prediciendo la
miniaturizacin por diez aos . . . . . . . . . . . . . . . . . . . .
2.8. La Ley de Moore se sostiene al da de hoy: conteo de transistores
por procesador de 1971 al 2012 . . . . . . . . . . . . . . . . . . .
2.9. Ley de Amdahl: ejecucin de un programa con 500 unidades de
tiempo total de trabajo con uno, dos y cuatro procesadores. . . .
2.10. Ganancia mxima al paralelizar un programa, segn la Ley de
Amdahl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
51
53
57
58
59
62
63
3.1.
3.2.
3.3.
3.4.
3.5.
NDICE DE FIGURAS
4.3. Planificador a corto plazo, o despachador . . . . . . . . . . . . . .
4.4. Diagrama de transicin entre los estados de un proceso . . . . .
4.5. Ejecucin de cuatro procesos con quantums de 5 ticks y cambios
de contexto de 2 ticks . . . . . . . . . . . . . . . . . . . . . . . . .
4.6. Primero llegado, primero servido (FCFS) . . . . . . . . . . . . .
4.7. Ronda (Round Robin) . . . . . . . . . . . . . . . . . . . . . . . . .
4.8. Ronda (Round Robin), con q = 4 . . . . . . . . . . . . . . . . . . .
4.9. El proceso ms corto a continuacin (SPN) . . . . . . . . . . . .
4.10. Promedio exponencial (prediccin de prxima solicitud de tiempo) de un proceso. . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.11. Ronda egosta (SRR) con a = 2 y b = 1 . . . . . . . . . . . . . . .
4.12. Representacin de un sistema con cinco colas de prioridad y siete procesos listos . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.13. Retroalimentacin multinivel (FB) bsica . . . . . . . . . . . . .
4.14. Retroalimentacin multinivel (FB) con q exponencial . . . . . . .
4.15. Proporcin de penalizacin registrada por cada proceso contra
el porcentaje del tiempo que ste requiere (Finkel, p.33) . . . . .
4.16. Tiempo perdido contra porcentaje de tiempo requerido por proceso (Finkel, p.34) . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.17. Tres modelos de mapeo de hilos a procesos. (Imgenes: Beth
Plale; ver Otros recursos) . . . . . . . . . . . . . . . . . . . . . . .
4.18. Descomposicin de una instruccin en sus cinco pasos clsicos
para organizarse en un pipeline . . . . . . . . . . . . . . . . . . .
4.19. Alternando ciclos de cmputo y espera por memoria, un procesador que implementa hilos hardware (hyperthreaded) se presenta como dos procesadores . . . . . . . . . . . . . . . . . . . . . .
5.1. Espacio de direcciones vlidas para el proceso 3 definido por un
registro base y un registro lmite . . . . . . . . . . . . . . . . . .
5.2. Patrones de acceso a memoria, demostrando la localidad espacial / temporal (Silberschatz, p.350) . . . . . . . . . . . . . . . .
5.3. Regiones de la memoria para un proceso . . . . . . . . . . . . .
5.4. Proceso de compilacin y carga de un programa, indicando el
tipo de resolucin de direcciones (Silberschatz, p.281) . . . . . .
5.5. Compactacin de la memoria de procesos en ejecucin . . . . .
5.6. Ejemplo de segmentacin . . . . . . . . . . . . . . . . . . . . . .
5.7. Pgina y desplazamiento, en un esquema de direccionamiento
de 16 bits y pginas de 512 bytes . . . . . . . . . . . . . . . . . .
5.8. Esquema del proceso de paginacin, ilustrando el rol de la MMU
5.9. Ejemplo (minsculo) de paginacin, con un espacio de direccionamiento de 32 bytes y pginas de 4 bytes . . . . . . . . . . .
5.10. Esquema de paginacin empleando un buffer de traduccin adelantada (TLB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
351
130
131
134
138
139
139
141
141
143
144
145
146
150
151
152
157
158
168
169
171
172
175
177
181
181
182
185
352
NDICE DE FIGURAS
5.11. Paginacin en dos niveles: una tabla externa de 10 bits, tablas
intermedias de 10 bits, y marcos de 12 bits (esquema comn para
procesadores de 32 bits) . . . . . . . . . . . . . . . . . . . . . . .
5.12. Uso de memoria compartida: tres procesos comparten la memoria ocupada por el texto del programa (azul), difieren slo en los
datos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.13. Memoria de dos procesos en un sistema que implementa copiar
al escribir. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.14. Esquema general de la memoria, incorporando espacio en almacenamiento secundario, representando la memoria virtual . . .
5.15. Pasos que atraviesa la respuesta a un fallo de pgina . . . . . . .
5.16. Anomala de Belady, empleando la cadena de referencia 1, 2, 3,
4, 1, 2, 5, 1, 2, 3, 4, 5 (Belady, 1969). . . . . . . . . . . . . . . . . .
5.17. Algoritmo FIFO de reemplazo de pginas . . . . . . . . . . . . .
5.18. Algoritmo ptimo de reemplazo de pginas (OPT) . . . . . . . .
5.19. Algoritmo reemplazo de pginas menos recientemente utilizadas
(LRU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.20. Al aumentar demasiado el grado de multiprogramacin, el uso
del CPU cae abruptamente, entrando en hiperpaginacin (Silberschatz, p.349) . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.21. Los picos y valles en la cantidad de fallos de pgina de un proceso definen a su conjunto activo . . . . . . . . . . . . . . . . . . .
5.22. Marco del stack con llamada a func(1,2,3) en x86-32 . . . . .
5.23. Estado de la memoria despus del strcpy() . . . . . . . . . . .
5.24. Ejecutando el cdigo arbitrario inyectado al buffer . . . . . . . .
5.25. Marco de stack con un canario aleatorio protector de 12 bytes
(qRz2a&5f50s): si este es sobreescrito por un buffer desbordado, se detendr la ejecucin del programa. . . . . . . . . . . .
6.1.
6.2.
6.3.
6.4.
186
187
189
190
192
196
197
198
199
207
207
210
212
213
215
226
235
235
236
240
241
242
243
246
248
NDICE DE FIGURAS
353
327
329
332
334
335
336
338
339
339
354
NDICE DE FIGURAS
C.10.Divisin de datos en franjas, con paridad, para RAID 5 . . . . .
C.11.Para cada franja, el disco de paridad guarda la suma XOR de
los bits de las franjas correspondientes de los otros discos; no
importa cul disco falle, sus datos pueden recuperarse haciendo
un XOR de los datos de los dems. . . . . . . . . . . . . . . . . .
C.12.Cinco discos organizados en RAID 5. La franja de paridad se va
alternando, repartindose entre todos los discos. . . . . . . . . .
C.13.Cinco discos organizados en RAID 6. Al igual que bajo RAID 5,
las franjas de paridad se van alternando entre todos los discos. .
C.14.Seis discos organizados en RAID 1+0 . . . . . . . . . . . . . . . .
C.15.Seis discos organizados en RAID 0+1, ilustrando cmo una combinacin errnea puede reducir la tolerancia mxima a fallos del
arreglo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
340
341
342
342
343
344