Eventos: traps e interrupciones

 

Tanto traps como interrupciones se exportan a las aplicaciones mediante portales. Esto quiere decir que nadie fuera del núcleo recibe directamente eventos enviados por el hardware. Al contrario, estos eventos se transforman en invocaciones de portales dentro del núcleo.

Podemos clasificar los eventos procedentes del hardware (o por el enviados inicialmente) en dos categorías:

• Eventos síncronos o causados síncronamente respecto de la ejecución del shuttle que los sufre (que ejecuta en el instante en que sucede el evento). Los más conocidos tal vez sean los traps. Llamadas a sistema y excepciones (de fallo de página, instrucción ilegal, etc.) están incluidos en este grupo.

  Su característica más interesante, al menos para la implementación del sistema, es que el shuttle que los sufre no es capaz de continuar su ejecución hasta el punto en que el evento se ha tratado. De hecho estos eventos suelen indicar la necesidad de efectuar algún tipo de tarea antes de poder proseguir con la ejecución del shuttle que los sufrió. No sólo es factible, sino incluso aconsejable, emplear tanto el shuttle que sufrió el evento como el(los) quantums de procesador que dicho shuttle tiene asignados para procesar el evento.

• Eventos asíncronos o causados asíncronamente respecto de la ejecución del shuttle que los sufre. Típicamente interrupciones.

  En este caso el shuttle que los sufre puede perfectamente proseguir su ejecución con independencia del tratamiento del evento. De hecho, lo habitual es que el evento no esté dirigido al shuttle que lo sufre sino a otro cualquiera. Ahora, al contrario que en el caso anterior, no es necesario (de hecho, no suele ser conveniente) emplear el shuttle interrumpido para gestionar el evento.

Para ambos casos, el kernel emplea una tabla para mantener los portales que corresponden a los eventos. Las entradas en esta tabla son susceptibles de asignación de tal modo que el usuario puede pedir la asignación de una línea de interrupción (indicando el portal que debe servirla) o de una excepción. Salvo por la interrupción de reloj (empleada por el servidor de shuttles para implementar quantums, y reexportada a los usuarios mediante temporizadores) y la excepción de fallo de página (empleada por el DMM para implementar las DTLBs), el resto de eventos están disponibles para las aplicaciones.

El tratamiento de eventos síncronos es como sigue (ver figura 3.22:

1. El procesador genera el evento, lo que conduce a la entrada en modo kernel y a la ejecución de una pequeña rutina que llama a shtl_trap_handler, el manejador de excepciones del kernel.
2. El manejador comprueba si la excepción corresponde a una llamada al sistema.
   1. En caso afirmativo se llama directamente a shtl_system_call, que ejecutará la llamada al sistema correspondiente.
   2. En caso negativo se consulta en la tabla de traps y se invoca el manejador correspondiente. Nótese que aunque estamos dentro del kernel estamos ejecutando sobre el shuttle que sufrió la excepción y sujetos a la asignación de procesador determinada por la cola de ejecución que dicho procesador tenga (el kernel es expulsable).

  
Figure 3.22: Manejador de traps del kernel

Cuando el manejador de la excepción retorne se retornará de shtl_trap_handler, lo que conducirá a la reanudación de la ejecución del shuttle interrumpido en el punto en que éste se encontraba antes de la ocurrencia del trap.

El tratamiento de interrupciones es en realidad muy similar, la diferencia principal estriba en que el envío se debe realizar:

• de modo bloqueante (mediante PCTs) si el shuttle que ejecuta tiene menor prioridad que la interrupción considerada (con ello se hace ejecutar el manejador de la interrupción aunque ésto suponga parar temporalmente al shuttle interrumpido).
• de modo no bloqueante si el shuttle que ejecuta tiene mayor prioridad que la interrupción considerada (con ello el manejador de la interrupción debe aguardar hasta que el procesador esté ejecutando un shuttle con menor prioridad que la interrupción).

  Aunque también se podría haber preparado la llamada asíncrona en el shuttle servidor y esperar a que le llegue su turno de ejecución esto supondría emplear más quantum del remitente, razón por la que no se ha hecho así.

Otro pequeño detalle es que la rutina real de tratamiento de interrupciones que invoca a shtl_intr_handler efectúa el acknowledge de la interrupción y la enmascara. Si el manejador de la interrupción desea permitir que ocurran nuevas interrupciones deberá desenmascararla.