Sistemas operativos modernos

12.3.6 Estructuras estáticas o dinámicas Los diseñadores de sistemas operativos se ven obligados continuamente a escoger entre estruc­ turas de datos estáticas o dinámicas. Las estáticas siempre son más comprensibles, más fáciles de programar y de uso más rápido; las dinámicas son más flexibles. Un ejemplo obvio es la ta­ bla de procesos. Los primeros sistemas tan sólo asignaban un arreglo fijo de estructuras, de las cuales había una para cada proceso. Si la tabla de procesos tenía 256 entradas, sólo podía haber 256 procesos en cualquier instante dado. Un intento por crear el proceso 257 fi-acasaba por fal­ ta de espacio en tablas. Lo mismo se cumplía para la tabla de archivos abiertos (tanto por usua­ rio como para todo el sistema) y muchas otras tablas del kernel. Una estrategia alterna consiste en construir la tabla de procesos como lista enlazada de mini­ tablas, de las que al principio sólo hay una. Si se llena esta tabla, se asigna espacio para otra a par­ tir de una reserva global de almacenamiento, y esta nueva tabla se enlaza con la primera. De este modo, la tabla de procesos no podrá llenarse a menos que se agote toda la memoria del kemel. Por otra parte, el código para realizar búsquedas en las tablas se vuelve más complicado. Por ejemplo, en la figura 12-4 se da el código para buscar un PID dado, pid, en una tabla de pro­ cesos estática. Este código es sencillo y eficiente. Hacer lo mismo en una lista enlazada de mi­ nitablas requiere más trabajo. found = 0; for (p = &proc_table[0]; p < &proc_table[PROC_TABLE_SIZE]: p++) { if (p->proc_pid == pid) { found = 1; break; } } Figura 12-4. Código para buscar un PID dado en la tabla de procesos. Las tablas estáficas son más recomendables cuando hay memoria de sobra o es posible es­ timar la ufilización de tablas con relativa exactitud. Por ejemplo, en un sistema monousuario es poco probable que el usuario inicie más de 32 procesos a la vez, y la imposibilidad de crear un proceso 33 no constituirá un desastre total. Otra alternativa es ufilizar una tabla de tamaño fijo, pero si ésta llega a llSnarse, asignar una nueva de tamaño fijo de, digamos, el doble. Las entradas actuales se copian en la nueva tabla y la anterior se devuelve a la reserva de almacenamiento libre. Así, la tabla siempre es configua, no enlazada. La desventaja aquí es que se requiere cierta administración del almacenamiento y la dirección de la tabla ahora es una variable, no una constante. Un problema similar se presenta con las pilas de kemel. Cuando un subproceso cambia a mo­ do de kemeU o cuando se ejecuta un subproceso de kemel, se necesita una pila en el espacio de kemel. En el caso de subprocesos de usuario, la pila puede inicializarse de modo que se ejecute en forma descendente a partir de la parte superior del espacio de direcciones virtual; así no será ne-