Aunque la E/S programada es útil algunas veces, para la
mayor parte de las operaciones de E/S las
interrupciones son un hecho incómodo de la vida y no se
pueden evitar.
Deben ocultarse en la profundidad de las entrañas del sistema operativo, de manera que éste
sepa lo menos posible de ellas.
La mejor manera de ocultarlas es hacer que el controlador
que inicia una operación de E/S se bloquee
hasta que se haya completado la E/S y ocurra la
interrupción.
El controlador se puede bloquear a sí mismo realizando una llamada a down en un
semáforo, una llamada a wait en una variable de condición, una llamada a receive en un mensaje o
algo similar, por ejemplo.
Cuando ocurre la interrupción, el procedimiento de
interrupciones hace todo lo necesario para poder
manejarla. Después puede desbloquear el controlador que la
inició.
En algunos casos sólo completará up en un semáforo. En otros casos realizará una llamada
a signal en una variable de condición en un monitor. En otros más enviará un mensaje al
controlador bloqueado. En todos los casos, el efecto neto de la interrupción será que un
controlador que estaba bloqueado podrá ejecutarse ahora.
Este modelo funciona mejor si los controladores están
estructurados como procesos del
kernel, con sus propios estados, pilas y contadores del
programa.
Desde luego que en realidad esto no es tan simple. Procesar
una interrupción no es cuestión de
sólo tomar la interrupción, llamar a up en algún
semáforo y después ejecutar una instrucción IRET
para regresar de la interrupción al proceso anterior. Hay
mucho más trabajo involucrado para el sistema operativo.
Ahora veremos un esquema de este trabajo como una
serie de pasos que se deben llevar a cabo en el software, una vez que se haya completado
la interrupción de hardware.
A continuación tal vez no sean necesarios en una máquina
específica, y tal vez se requieran otros
que no estén listados. Además, los pasos que se llevan a
cabo pueden estar en distinto orden en algunas máquinas.
1. Guardar los registros (incluyendo el PSW) que no han sido
guardados por el hardware de
la interrupción.
2. Establecer un contexto para el procedimiento de servicio
de interrupciones. Para ello tal
vez sea necesario establecer el TLB, la MMU y una tabla de
páginas.
3. Establecer una pila para el procedimiento de servicio de
interrupciones.
4. Reconocer el controlador de interrupciones. Si no hay un
controlador de interrupciones
centralizado, rehabilitar las interrupciones.
5. Copiar los registros desde donde se guardaron
(posiblemente en alguna pila) a la tabla de
procesos.
6. Ejecutar el procedimiento de servicio de interrupciones.
Éste extraerá información de los
registros del controlador de dispositivos que provocó la
interrupción.
7. Elegir cuál proceso ejecutar a continuación. Si la
interrupción ha ocasionado que cierto
proceso de alta prioridad que estaba bloqueado cambie al
estado listo, puede elegirse para
ejecutarlo en ese momento.
8. Establecer el contexto de la MMU para el proceso que se
va a ejecutar a continuación.
También puede ser necesario establecer un TLB.
9. Cargar los registros del nuevo proceso, incluyendo su
PSW.
10. Empezar a ejecutar el nuevo proceso.
No hay comentarios.:
Publicar un comentario