Sistemas operativos modernos

El principio de localidad también es válido para los archivos. Una vez que un proceso ha seleccionado su directorio de trabajo, es probable que muchas de sus referencias futuras sean a archivos que están en ese directorio. Si se colocan todos los nodos-i y archivos de cada di­ rectorio cercanos entre sí en el disco, podrá mejorarse el desempeño. Este principio es la base del Fast File System de Berkeley (McKusick et al., 1984). Otra área en la que la localidad desempeña un papel es la calendarización de subprocesos en multiprocesadores. Como vimos en el capítulo 8 , una forma de calendarizar subprocesos en un multiprocesador es tratar de ejecutar cada subproceso en la última CPU que usó, con la es­ peranza de que algunos de sus bloques de memoria todavía estén en el caché de memoria. 12.4.7 Optimización del caso común En muchos casos es recomendable distinguir entre el caso más común y el peor caso posible y tratarlos de distinta manera. Con frecuencia el código para los dos casos es muy diferente. Es importante lograr que el caso común sea rápido. El peor caso, si no se presenta a menudo, só­ lo tiene que manejarse en forma correcta. Como primer ejemplo, consideremos el ingreso en una región crítica. Casi todo el tiempo, el ingreso se logra, sobre todo si los procesos no pasan demasiado tiempo dentro de regiones críticas. Windows 2000 aprovecha esta expectativa ofreciendo una llamada EnterCriticalSec- tion en la API Win32 que prueba de manera atómica una etiqueta en modo de usuario (em­ pleando TSL o su equivalente). Si la prueba resulta favorable, el proceso simplemente entra en la región crítica y no es necesaria una llamada al kernel. Si la prueba falla, el procedimiento de bibUoteca ejecuta down con un semáforo para bloquear el proceso. Así, en el caso normal no se requiere una llamada al kernel. Como segundo ejemplo, consideremos la puesta de una alarma (empleando señales en UNIX). Si ninguna alarma está pendiente, es sencillo crear una entrada y colocarla en la cola del temporizador. En cambio, si ya hay una alarma pendiente, debe encontrarse y sacarse de la cola del temporizador. Como la llamada alarm no especifica si ya hay o no una alarma establecida, el sistema tiene que suponer el peor caso, que sí hay una. Sin embargo, dado que por lo regular no hay alarmas pendientes, y en vista de lo costoso que resulta eliminar una alarma existente, es una buena idea distinguir estos dos casos. Una forma de hacerlo es mantener un bit en la tabla de procesos que indique si hay una alarma pendiente. Si el bit está apagado, se seguirá el camino fácil (tan sólo añadir una nueva entrada a la cola del temporizador, sin examinarla). Si el bit está encendido, habrá que exami­ nar la cola del temporizador. 12.5 ADMINISTRACION DE PROYECTOS Los programadores son optimistas perpetuos. Casi todos piensan que la forma de escribir un programa es correr al teclado y comenzar a escribir. Poco fiempo después el programa depura­ do por completo estará listo. En el caso de programas muy grandes, la cosa no funciona así. En