Sistemas operativos modernos

tructuras de datos de P estaban en un estado inconsistente en el momento de la interrupción, el manejador las verá en un estado inconsistente y fallará. Un ejemplo obvio de un caso en el que puede suceder esto es si P es el calendarizador. Su­ pongamos que algún proceso agotó su cuanto y el sistema operativo lo estaba pasando al final de su cola. Antes de completarse la manipulación de la fista, se presenta la interrupción, con lo cual algún proceso pasa ai estado listo y ejecuta el calendarizador. Con las colas en un estado incon­ sistente, lo más probable es que el sistema falle. Así pues, incluso en un uniprocesador lo me­ jor es que la mayor parte del sistema operativo sea reentrante, que las estructuras de datos cruciales se protejan con mutex, y que las interrupciones se inhabiliten en los momentos en que no puedan tolerarse. Fuerza bruta El uso de fuerza bruta para resolver un problema ha adquirido connotaciones negativas al pa­ so de los años, pero en muchos casos es lo más recomendable en aras de la sencillez. Todo sis­ tema operativo fiene muchos procedimientos que casi nunca se invocan o que operan con tan pocos datos que no vale la pena opfimizarlos. Por ejemplo, a menudo es necesario explorar di­ versas tablas y arreglos dentro del sistema. El algoritmo de fuerza bruta consiste en dejar la ta­ bla en el orden en que se crearon las entradas y explorarla en forma lineal cuando es necesario encontrar algo. Si el número de entradas es pequeño (digamos, menos de 1(X)), no se gana mu­ cho ordenando la tabla o dispersándola, y el código sería mucho más complicado y propenso a errores. Desde luego, en el caso de funciones que están en la ruta crífica, como la conmutación de contexto, debe hacerse todo lo posible para que sean rápidas, quizá llegando al extremo (Dios no lo quiera) de escribirlas en lenguaje ensamblador. Sin embargo, una buena parte del siste­ ma no está en la ruta crífica. Por ejemplo, muchas llamadas al sistema se invocan rara vez. Si se efectúa un fork cada 10 segundos, y su ejecución tarda 10 ms, lo más que puede ganarse (in­ cluso opfimizándolo para que tarde O segundos) es un 0.1%. Si el código optimizado es más grande y con más errores, podría no valer la pena molestarse en efectuar la opfimización. Verificar primero si hay errores Muchas llamadas al sistema podrían fallar por diversas razones: el archivo que se desea abrir pertenece a otra persona; no puede crearse un proceso porque la tabla de procesos está llena; o no puede enviarse una señal porque no existe el proceso de destino. El sistema operafivo debe verificar en forma minuciosa todos los posibles errores antes de ejecutar la llamada. Muchas llamadas al sistema requieren también obtener recursos, como ranuras de la tabla de procesos, ranuras de la tabla de nodos-i o descriptores de archivo. Un consejo general que pue­ de ahorrar muchos dolores de cabeza es comprobar primero si puede efectuarse en verdad la lla­ mada al sistema, antes de obtener cualquier recurso. Esto implica colocar todas las pruebas al principio del procedimiento que ejecuta la llamada al sistema. Cada prueba debe ser de la forma if (condición_de_error) return(CÓD IGO_DE_ERROR);