Sistemas operativos modernos

no se atenderá por el momento. En este caso, el dispositivo seguirá aplicando una señal de in­ terrupción al bus hasta que la CPU le haga caso. Para manejar la interrupción, la controladora coloca un número en las líneas de dirección para especificar cuál dispositivo requiere servicio y aplica una señal que interrumpe a la CPU. La señal de interrupción hace que la CPU deje lo que estaba haciendo y comience a hacer otra cosa. El número que está en las líneas de dirección se usa como índice para consultar una ta­ bla llamada vector de interrupciones y traer un nuevo contador de programa, ei cual apunta al principio del procedimiento que da servicio a la interrupción correspondiente. Por lo regular, las interrupciones de sistema y de dispositivo utilizan el mismo mecanismo a partir de este punto, y a menudo comparten el vector de interrupciones. La ubicación del vector puede estar incorpora­ da al hardware o en cualquier lugar de la memoria, en cuyo caso un registro de la CPU (cargado por el sistema operativo) apuntará a su origen. Poco después de comenzar a ejecutar, el procedimiento de servicio de interrupción acusa recibo de la interrupción, escribiendo cierto valor en uno de los puertos de E/S de la controla­ dora de interrupciones. Este acuse le dice a la controladora que está en libertad de generar otra interrupción. Al hacer que la CPU aplace este acuse hasta que esté lista para manejar la siguien­ te interrupción pueden evitarse condiciones de competencia en las que intervengan múltiples interrupciones casi simultáneas. Por cierto, algunas computadoras (antiguas) no tienen una controladora centralizada de interrupciones, así que cada controladora de dispositivo solicita sus propias interrupciones. El hardware siempre guarda cierta información antes de iniciar el procedimiento de servi­ cio. La naturaleza de esa información y el lugar donde se guarda varían de manera considera­ ble de una CPU a otra. Como mínimo, hay que guardar el contador de programa para que el proceso interrumpido pueda reiniciarse. En el otro extremo, podrían guardarse todos los regis­ tros visibles y un gran número de registros internos. El problema es dónde guardar esta información. Una opción sería colocarla en registros in­ ternos que el sistema operativo pueda leer cuando los necesite. Este enfoque tiene la desventa­ ja de que no se podrá enviar el acuse a la controladora de interrupciones hasta no haber leído toda la información pertinente, pues una segunda interrupción podría sobrescribir los registros internos donde se guarda el estado. Tal estrategia causa largos tiempos muertos, durante los que las interrupciones están inhabilitadas, con la posible pérdida de interrupciones y datos. Por ello, la mayoría de las CPUs guarda la información en la pila. Sin embargo, este enfo­ que también tiene problemas. Por principio de cuentas, ¿la pila de quién? Si se usa la pila ac­ tual, bien podría ser una de proceso de usuario. Cabe la posibilidad de que el apuntador de pila ni siquiera sea válido, lo cual causaría un error fatal cuando el hardware trate de escribir pala­ bras en ella. Además, podría apuntar al final de una página. Después de varias escrituras en la memoria podría rebasarse la frontera de la página y generarse un fallo de página. Un fallo de este tipo que se presenta mientras el hardware está procesando una interrupción crea un pro­ blema mayor: ¿dónde se guardará el estado para manejar el fallo de página? Si se usa la pila del kernel, aumenta mucho la probabilidad de que el apuntador de pila sea válido y apunte a una página sujeta. Sin embargo, el cambio a modo de kernel podría requerir un cambio de contexto de la MMU y probablemente anularía la validez de la mayor parte o la