operating system - interrupts - Enmascaramiento de interrupción: ¿por qué?

interrupt meaning (4)

Estaba leyendo sobre interrupciones. Es posible suspender las interrupciones no críticas a través de una máscara de interrupción especial. Esto se llama enmascaramiento de interrupción. Lo que no sé es cuándo / por qué podría querer o necesita suspender temporalmente las interrupciones? Posiblemente los semáforos, o la programación en un entorno multiprocesador?

Además de las respuestas ya dadas, hay un elemento de prioridad para ello. Hay algunas interrupciones que necesita o desea poder responder lo más rápido posible y otras que le gustaría conocer pero solo cuando no está tan ocupado. El ejemplo más obvio podría ser rellenar el búfer de escritura en una grabadora de DVD (donde, si no lo hace a tiempo, algunos equipos simplemente escribirán el DVD de manera incorrecta) en lugar de procesar un nuevo paquete de la red. Deshabilitaría la interrupción para el último al recibir la interrupción para el primero, y la mantendría inhabilitada durante el tiempo de llenado del búfer.

En la práctica, muchas CPU tienen prioridad de interrupción integrada directamente en el hardware. Cuando se produce una interrupción, los indicadores deshabilitados se configuran para interrupciones menores y, a menudo, se interrumpen al mismo tiempo que se lee el vector de interrupción y se pasa a la dirección correspondiente. Dictando que la recepción de una interrupción también implícitamente las máscaras que interrumpen hasta el final del controlador de interrupción tiene el efecto secundario agradable de aflojar las restricciones en la interrupción de hardware. Por ejemplo, puede decir simplemente que la señal alta activa la interrupción y deja que el hardware externo decida cuánto tiempo quiere mantener la línea alta sin preocuparse por la activación involuntaria de múltiples interrupciones.

En muchos sistemas anticuados (incluidos el z80 y el 6502), suele haber solo dos niveles de interrupción: enmascarable y no enmascarable, que creo que es de donde proviene el lenguaje de habilitar o deshabilitar interrupciones. Pero incluso desde el 68000 original, tiene ocho niveles de interrupción y un nivel de prioridad actual en la CPU que determina qué niveles de interrupción entrante realmente tendrán efecto.

El sistema operativo hace eso cuando se prepara para ejecutar su propio código "vamos a orquestar el mundo".

Por ejemplo, en algún punto el programador de hilos del sistema operativo tiene control. Prepara los registros del procesador y todo lo que se necesita hacer antes de que se ejecute un subproceso para que se configure el entorno para ese proceso y ese subproceso. Luego, antes de dejar que se ejecute ese subproceso, establece una interrupción del temporizador para que se active después del tiempo que pretende dejar que el subproceso haya transcurrido en la CPU.

Una vez transcurrido ese período de tiempo (cuanto), la interrupción aumenta y el programador del sistema operativo vuelve a tomar el control. Tiene que averiguar qué se debe hacer a continuación. Para hacer eso, necesita guardar el estado de los registros de la CPU para que sepa cómo deshacer los efectos secundarios del código que ejecuta. Si se produce otra interrupción por algún motivo (p. Ej., Se completa algún E / S asíncrono) mientras se guarda el estado, esto dejaría al sistema operativo en una situación en la que su mundo no está en un estado válido (en efecto, guardar el estado debe ser una operación atómica).

Para evitar quedar atrapado en esa situación, el kernel del SO, por lo tanto, deshabilita las interrupciones mientras se realizan las operaciones que deben ser atómicas. Después de que haya hecho lo que sea necesario y el sistema vuelva a estar en un estado conocido, vuelve a habilitar las interrupciones.

Imagine que su CPU está en el controlador "int3" ahora y en ese momento sucede "int2" y el "int2" que acaba de suceder tiene una prioridad más baja en comparación con "int3". ¿Cómo manejaríamos esta situación?

Una forma es cuando manejamos "int3", estamos ocultando otros interruptores de prioridad más baja. Es decir, vemos que "int2" está señalizando a la CPU, pero la CPU no se interrumpiría por ello. Después de que terminemos de manejar el "int3", regresamos de "int3" y desenmascaramos los interruptores de prioridad más baja.

El lugar al que volvimos puede ser:

Otro proceso (en un sistema preventivo)
El proceso que fue interrumpido por "int3" (en un sistema no preventivo o sistema preventivo)
Un controlador int que es interrumpido por "int3", digamos el controlador int1.

En los casos 1 y 2, porque desenmascaramos los interruptores de prioridad más baja y "int2" sigue indicando a la CPU: "hola, hay algo que debe manejar de inmediato", luego la CPU se interrumpirá de nuevo cuando esté ejecutando las instrucciones. a partir de un proceso, para manejar "int2"

En el caso 3, si la prioridad de "int2" es mayor que "int1", entonces la CPU se interrumpirá de nuevo, cuando esté ejecutando instrucciones desde el controlador de "int1", para manejar "int2".

De lo contrario, el controlador "int1" se ejecuta sin interrupciones (porque también estamos ocultando los interruptores con prioridad más baja que "int1") y la CPU volverá a un proceso después de manejar "int1" y desenmascarar. En ese momento se manejaría "int2".

Solía programar en una placa ARM que tenía aproximadamente 10 interrupciones que podían ocurrir. Cada programa en particular que escribí nunca estuvo interesado en más de 4 de ellos. Por ejemplo, había 2 temporizadores en la placa, pero mis programas solo usaban 1. Enmascararía la interrupción del segundo temporizador. Si no hubiera ocultado ese temporizador, podría haberse habilitado y continuar haciendo interrupciones que ralentizarían mi código.

Otro ejemplo fue que usaría la interrupción completa de REGISTRO de recepción de UART, por lo que nunca necesitaría que se produjera la interrupción completa de BUFFER de recepción de UART.

Espero que esto te dé una idea de por qué es posible que desees desactivar las interrupciones.