1. Descrição do Domínio

A função do tratador de interrupção é saber que dispositivo lançou a interrupção e em quem ponto do sistema operacional está o endereço inicial da rotina para tratar esta interrupção, para que o processador possa executar esta rotina no endereço especificado pelo tratador, e depois deixar que o processador volte ao seu curso normal de execução após a interrupção ter sido resolvida.

Arquiteturas de interrupções mais sofisticadas permitem que o tratamento de uma interrupção prioritária seja processada na frente de uma outra através do esquema de prioridades, onde são assinadas prioridades de execução de acordo com sua importância. Também existem arquiteturas que permitem que as rotinas sejam manipuladas através dos driver's dos dispositivos que controlam suas placas controladoras.

As placas controladoras dos dispositivos possuem uma interface bem definida de operações da qual seu driver possa fazer operações neste dispositivo passando parâmetros ou não. Quando as operações na placa controladora do dispositivo não são simples e exigem um tempo de processamento na placa, o processador pode deixar ela executar as operações e enquanto isso pode fazer outras coisas.

2. Objetivos

Um problema que é freqüentemente observado em sistemas de I/O, é que os tratadores de interrupções sofrem para gerenciar no caso de existirem várias interrupções simultâneas (de um mesmo dispositivo ou não), pois se a taxa de interrupções for muito alta e o tratador não conseguir acompanhar, ou seja, se o tempo do tratamento da interrupção for maior que o tempo médio que uma interrupção é gerada, algumas interrupções poderão ser perdidas.

Também existe o caso em que o tratador de interrupção deixa a aplicação tratar a interrupção apenas repassando o tipo da interrupção para que a aplicação possa executar a rotina tratadora para o tratamento Mas se neste meio tempo for lançada outra interrupção pelo mesmo dispositivo, e o tratador chamar a mesma rotina para esta última, esta última interrupção irá sobrescrever os valores dos registradores que a primeira interrupção calculou e a primeira será perdida.

Este trabalho tenta de alguma forma contornar estes problemas para que não se percam interrupções, que podem ser muito importantes em sistemas tais como de tempo real.

Deveremos analisar e verificar a necessidade de desenvolver o componente para o tratamento de interrupções (sistema EPOS) lançadas pelo hardware de um sistema computacional, afim de estudar novas formas e mais eficientes de executar esta tarefa que é uma das mais importantes em um sistema computacional.

 

3. Lista de Requisitos

O componente desenvolvido deve atender aos seguintes requisitos:

- Fornecer comunicação e gerenciar os dispositivos de I/O através do barramento;

- Aceitar níveis de prioridades de interrupções de acordo com sua importância;

- Pode ocorrer interrupções que deverão ser tratadas de modo síncrona ou assíncrona dependendo do contexto;

- Ter independência de dispositivos;

- Dar suporte aos novos dispositivos que serão anexados ao sistema;

4. Diagramas

4.1 Diagramas de Famílias

A família de tratadores de interrupções faz parte da abstração de I/O. Esta família ficará encarregada de manipular as interrupções geradas por um dispositivo de hardware.

A seguir está especificado a família do tratador de interrupção com os membros envolvidos no tratador.

 

4.2 Diagramas de Componentes

A interação entre aplicações e dispositivos periféricos é gerenciada pela família de abstrações representada na figura abaixo.

Dispositivos periféricos são abstraídos em uma maneira que é conveniente para as aplicações pelos membros da famíla Device. Contudo, sistemas dedicados freqüentemente usam dispositivos dedicados que não serão encontrados nesta família.

Neste contexto, a família Bus é responsável por detectar e ativar dispositivos conectados ao barramento, do qual são abstraídos como membros criados da família de Device.

E a família que será tema de pesquisa se trata da Interrupt_Handler que trata de abstrações que permitem as aplicações tratar as interrupções geradas por um dispositivo.

4.3 Diagramas de Casos de Uso

A funcionalidade principal deste componente é a de trata as interrupções que são geradas pelos dispositivos de entrada/saída.

 

4.4 Diagramas de Classes

Function_IH: Este membro determina uma função fornecida pela aplicação para tratar a interrupção. O sistema transforma tal função em um tratador de interrupção que é chamada toda vez que a interrupção associada é gerada.

Thread_IH: Esta thread é previamente criada pela aplicação no estado de suspenso e é "acordado" toda vez que ocorre a correspondente interrupção. Depois de tratada a interrupção, a thread deve retornar para o estado suspenso novamente pela chamada de uma respectiva operação.

Se uma interrupção tentar ativar uma thread que já esta ativa, simplesmente não tem nenhum efeito, só que esta última interrupção será perdida.

Este membro tem uma ligação com Thread e esta tem ligação com um escalonador de processos que poderá atender o requisito de escalonar a thread dependendo do seu nível de prioridade e escolher se será de modo preemptivo ou não.

Semaphore_IH: O Semaphore_IH serve para prevenir que interrupções não sejam perdidas para no caso de haver interrupções concorrentes. Tem uma ligação com Semaphore para que possa controlar as interrupções concorrentes que terá a função de sincronizar as requisições de pedidos de interrupções.

Semaphore_IH aponta para um semáforo previamente criado por uma aplicação e inicializado com zero. O sistema operacional chama a operação "V" neste semáforo em todas as interrupções, enquanto a thread tratadora chama a operação "P" para esperar por uma interrupção. Esta estratégia dá ao tratamento de interrupção um sabor de produtor/consumidor e previne que as interrupções comecem a serem perdidas.

Generic_IH: Esta classe serve somente de interface para InterruptTable para que esta possa armazenar diferentes tipos de tratadores.

InterruptTable: Esta classe serve somente para estruturar os dados que ficarão em cada linha do vetor de interrupções que ficará na classe Handler. Estes dados especificam o tipo de interrupção que foi armazenada (Function, Thread ou Semaphore), o id da interrupção (posição do vetor de interrupções) e a classe do tipo que foi instanciada.

Handler: Esta classe que recebe o identificador da interrupção e escolhe dentre as armazenadas no seu vetor de interrupções a que corresponde ao id da interrupção (o id da interrupção corresponde à posição do vetor). Esta também deve gerenciar todo o salvamento do contexto dos registradores do processador e depois de tratada a interrupção o retorno do mesmo contexto salvo para que o aplicativo possa voltar executar suas tarefas.

 

4.5 Diagramas de Seqüência

No diagrama de sequência nos da uma noção de como o fluxo de chamadas das funções dos objetos irão ocorrer.

Podemos perceber que antes que o objeto Handler chame a função "TrataInterrupção()" de qualquer um dos tipos de tratadores ele primeiro irá salvar o contexto dos registradores do processador pela função "SalvaContextoProcessador()" e depois retornar o contexto chamando a função "RetornaContextoProcessador()".

obs: O objeto Handler não irá chamar o método "TrataInterrupção()" dos três objetos tratadores e sim um deles por interrupção (dependerá do tipo de interrupção!) .

 

4.6 Diagramas de Atividades

Este diagrama nos dá uma visão das atividades que deverão ser feitas para tratar determinada interrupção.

 

5. Grupo de Trabalho

Carlos Alberto Nakazawa

Márcio Marafon

Márcio Rodrigo de Oliveira