Índice. 5. Falhas em sistemas baseados em CPR Aspectos relativos à implementação 8. Chamadas a procedimentos remotos

Transcrição

1 Índice 1. Introdução 2 2. Definição de Chamadas a Procedimentos Remotos 2 3. Funcionamento das Chamadas a Procedimentos Remotos 3 4. Localização do servidor pelo cliente 4 1. Gravar no hardware do cliente o endereço do servidor na rede 4 2. Ligação dinâmica 4 Vantagens 5 Desvantagens 5 5. Falhas em sistemas baseados em CPR 5 O cliente não é capaz de localizar o servidor 6 Perda de mensagem do cliente solicitando serviço 6 Perda de mensagem do servidor como resposta 6 Queda do servidor 7 Queda do cliente 7 6. Aspectos relativos à implementação 8 Protocolos para Chamadas a procedimentos remotos 8 Confirmação de Pacote 9 Caminho Crítico 10 Cópia 10 Gerência do tempo 11 Gláucia Faria Vieira / Hima Carla Belloni Mourão 1

2 Chamadas a Procedimentos Remotos 1. Introdução Um sistema distribuído é estratificado em níveis de abstração. Os níveis menos abstratos do sistema, que incluem o sistema operacional e a rede física, relacionados com o transporte, empacotamento e roteamento de mensagens, devem permanecer transparentes aos processos. No nível da camada de transporte, é oferecido um serviço de troca de mensagens, sendo este o mais baixo nível de comunicação entre processos de um sistema. No nível da camada de apresentação é implementado um serviço de solicitação e resposta via chamada de rotinas, denominado chamada a procedimentos remotos. Este mecanismo conduz as transações, seqüência de solicitações e/ou respostas, da camada de aplicação. Comunicação Aplicação Transações Apresentação Chamadas a procedimentos remotos Transporte Passagem de mensagem S.O.(rede) Conexões de transporte Enlace/Físico Chaveamento de pacotes Tabela: Exemplificação da estratificação Deve ser lembrado que o principal objetivo de projeto de um sistema distribuído é o de se parecer com um sistema centralizado sob a ótica dos usuários. Para se atingir tal objetivo, basearse em conceitos de entrada/saída não é a melhor maneira. Portanto, o conceito de chamada a procedimento remoto, vem tratar de problemas que implicam em um sistema distribuído. 2. Definição de Chamadas a Procedimentos Remotos Chamadas a procedimentos remotos é a chamada de um programa a procedimentos localizados em máquinas diferentes. Sintaticamente, uma chamada a um procedimento remoto é idêntica a uma chamada a um procedimento local. Entretanto, a semântica é diferente, pois envolve atrasos e eventualmente algum tipo de tratamento a falhas. Chamada a procedimentos remotos esconde dos clientes detalhes de chamadas ao sistema, de conversões de dados e de comunicação na rede. Gláucia Faria Vieira / Hima Carla Belloni Mourão 2

3 3. Funcionamento das Chamadas a Procedimentos Remotos Uma chamada a procedimentos remotos é realizada através dos seguintes passos: 1. O procedimento do cliente chama o stub do cliente de maneira usual. 2. O stub do cliente constrói uma mensagem e envia um trap ao kernel. 3. O Kernel envia uma mensagem ao kernel remoto. 4. O kernel remoto entrega a mensagem ao stub do servidor. 5. O stub do servidor desempacota os parâmetros constantes da mensagem e chama o servidor. 6. O servidor realiza o seu trabalho e retorna o resultado para um buffer dentro do stub. 7. O stub do servidor empacota tais resultados em uma mensagem e emite um trap para o kernel. 8. O kernel remoto envia a mensagem para o kernel do cliente. 9. O kernel do cliente entrega a mensagem para o stub do cliente. 10. O stub desempacota os resultados e os fornece ao cliente. Maquina-Cliente Stub de Cliente Stub de Servidor Maquina-Servidora Cliente Chamada Retorno Empacotamento de parâmetros Desempacotamento do resultado Desempacotamento de parâmetros Empacotamento do resultado Chamada Retorno Servidor Kernel Kernel Transporte de mensagem por sobre a rede Figura1: Chamadas e mensagens na chamada remota a procedimento. Gláucia Faria Vieira / Hima Carla Belloni Mourão 3

4 4. Localização do servidor pelo cliente 1. Gravar no hardware do cliente o endereço do servidor na rede Uma possibilidade de o cliente localizar o servidor, é simplesmente gravar no hardware do cliente o endereço do servidor na rede. O problema com esse método é sua inflexibilidade. Se o servidor trocar de lugar ou mesmo se for replicado, ou se sua interface vier a mudar, muitos programas terão de ser recompilados. Para evitar esses tipos de problemas, alguns sistemas distribuídos empregam a chamada Ligação dinâmica. 2. Ligação dinâmica Este conceito se baseia em se ter uma especificação formal do servidor. O principal uso da especificação formal, é o de servir como entrada para o gerador do stub, que produz tanto o stub do servidor quanto o do cliente. Após gerados, ambos são postos na biblioteca de procedimentos. Quando um programa usuário (cliente) chama qualquer dos procedimentos definidos por esta especificação, o procedimento correspondente ao stub do cliente é ligado ao seu código objeto. Da mesma forma, quando o servidor é compilado, os stubs do servidor também são ligados a ele. Para cada um dos procedimentos são especificados os tipos dos parâmetros, caracterizandoos como in, out ou in out. A direção é relativa ao servidor. A direção do envio dos parâmetros é uma informação essencial, de forma que o stub do cliente sabe quais parâmetros devem ser enviados ao servidor, e o stub do servidor sabe quais deles devem ser enviados de volta. Ao iniciar a execução do servidor, a chamada para inicialize exporta a interface do servidor. Isto significa que o servidor envia uma mensagem para um programa chamado ligador (binder) para que este tome conhecimento de sua existência. Esse processo é conhecido como registro do servidor. Para se registrar, o servidor informa ao ligador seu nome, o número de sua versão, um identificador que geralmente é um número de 32 bits, e um manipulador, utilizado para permitir sua localização, o qual é dependente do sistema podendo ser um endereço Ethernet, um endereço IP ou um endereço X.500. Um servidor também pode cancelar seu registro com o ligador quando não estiver mais preparado par prestar o serviço. Com essas informações, quando o cliente chamar um dos procedimentos remotos pela primeira vez, o stub do cliente verifica que ele ainda não esta ligado a um servidor, enviando uma mensagem para o ligador solicitando a importação da versão da interface do file-server. O ligador verifica se um ou mais servidores já exportaram uma interface com esse nome e número de versão Se não houver nenhum servidor disposto, rodando tal interface, a chamada falha. Gláucia Faria Vieira / Hima Carla Belloni Mourão 4

5 Por outro lado, se houver um servidor adequado, o ligador fornece seu manipulador e seu número de identificação ao stub do cliente, que por sua vez usa o manipulador como o endereço ao qual serão enviadas as mensagens solicitando serviços. Essas mensagens contem os parâmetros e o número de identificação, a partir dos quais o kernel do servidor dirige as mensagens entrantes na direção do servidor correto, considerando que mais de um servidor esteja rodando na máquina. Vantagens Este método de importação e exportação de interfaces é altamente flexível. Ele pode tratar de diversos servidores que suportem a mesma interface. Com este método pode se ter uma distribuição de carga, sendo que o ligador pode espalhar os clientes de forma randômica pelos servidores. Pode também melhorar o grau de tolerância a falhas checando os servidores periodicamente e caçando o registro de qualquer servidor que não responda. Além disso, pode ajudar na autenticação, utilizando-se especificações de listas de usuários que podem usar um determinado servidor, fazendo com que o ligador venha a recusar qualquer cliente fora da lista. Desvantagens Um problema encontrado é o overhead gerado pelos procedimentos de importação e exportação, sendo seu efeito significativo quando muitos processos de clientes têm vida curta e precisam ser repetidos várias vezes. Alem disso, o ligador acaba se tornado um gargalo na performance, de maneira que são necessários vários ligadores. Com isso, será necessária uma quantidade substancial de mensagens para manter todos os ligadores sincronizados e atualizados quando uma interface é registrada ou tem seu registro cancelado, gerando mais overhead. 5. Falhas em sistemas baseados em CPR O método de chamada a procedimento remoto faz perfeitamente seu trabalho enquanto tanto o cliente quanto o servidor estiverem funcionando corretamente. Porém, os problemas começam com a ocorrência eventual de erros, sendo por isso difícil de mascarar as diferenças entre chamadas locais e remotas. Abaixo falaremos sobre cinco possibilidades de erros. Gláucia Faria Vieira / Hima Carla Belloni Mourão 5

6 O cliente não é capaz de localizar o servidor Um dos motivos para que o cliente não consiga localizar o servidor, é que o servidor esteja fora do ar. Outra possibilidade, é quando o servidor evolui e o cliente está usando uma versão antiga de interface, sendo impossível de serem combinados pelo ligador, reportando então a falha. Uma possível solução é o mecanismo que faz com que o erro se torne uma exceção e cada linguagem trate dessas exceções. O problema é que nem toda linguagem suporta exceções. Alem de que escrever um procedimento para tratar exceções joga para o alto a transparência do sistema. Perda de mensagem do cliente solicitando serviço Este aspecto é o mais fácil de tratar. Basta fazer com que o kernel inicialize um temporizador quando do envio de uma mensagem de solicitação. Se o temporizador expirar antes da chegada de uma resposta ou de uma mensagem de reconhecimento, o kernel deve mandar a mensagem novamente. Se ela tiver realmente se perdido na rede, o servidor não será capaz de distinguir entre a mensagem retransmitida e a original. Pode ocorrer o caso da perda de uma serie de mensagens, fazendo com que o Kernel desista das transmissões, e conclua erradamente que o servidor saiu do ar. Perda de mensagem do servidor como resposta È mais difícil de se tratar. O uso do temporizador não funciona aqui. O cliente não sabe o motivo pelo qual a resposta não chegou. Se foi a solicitação que se perdeu pela rede, ou a resposta, ou se o servidor que é muito lento. Portanto, uma solução é a repetição da requisição, sendo que essa repetição não cause problemas para o sistema. Esse tipo de requisição é chamada de idempotente. Porem, em certas aplicações essa solução não é viável, tal como para um servidor de um banco comercial comandando a transferência de dinheiro. Outro método para a solução desse problema, é fazer com que cada kernel do cliente atribua a cada requisição um numero seqüencial. Se cada kernel de servidor passar a controlar esta numeração, mantendo o ultimo numero da seqüência de cada kernel de cliente, o kernel do servidor vai poder descobrir a diferença entre uma requisição original e uma retransmissão, podendo recusar-se a realizar uma dada requisição pela segunda vez. Alem disso pode ser mantido um bit no cabeçalho da mensagem para distinguir a mensagem original da retransmissão. Gláucia Faria Vieira / Hima Carla Belloni Mourão 6

7 Queda do servidor A ordem normal dos eventos em um servidor é: chega uma requisição, a seguir ela é executada, e finalmente uma resposta é enviada de volta. A queda do servidor pode ocorrer em dois pontos. Um, é quando o servidor sai do ar antes de enviar uma resposta da requisição executada. Outro, é quando o servidor pára de funcionar antes de processar a requisição. No primeiro caso, o sistema deve reportar a falha de volta ao cliente, provocando por exemplo, uma exceção, enquanto no segundo, ele pode simplesmente retransmitir a requisição. O problema é que o kernel não consegue distinguir isso. Ele só sabe que o tempo programado do temporizador já se esgotou. Existem três modos de tratamento para isso. Uma é a semântica de no mínimo uma vez, que diz que o kernel do cliente deve continuar tentando ate receber uma resposta. Outra é semântica de no máximo uma vez, que defende que o kernel deve desistir imediatamente e reportar o problema. A ultima é a de não garantir nada. Temos então, que no primeiro caso, se o servidor cair o cliente também cai, não havendo possibilidade de implementar procedimentos de recuperação. Já no segundo é possível e necessário tomar algum tipo de providencia. Queda do cliente Quando um cliente manda uma mensagem para um servidor solicitando algum trabalho, e sai do ar antes que o servidor tenha podido responder, ocorre a realização de um processamento sem que nenhum pai esteja esperando por ele. Tal processamento é denominado processamento órfão, que deve ser evitado, pois causam muitos problemas. No mínimo estes processos gastam tempo do processador. Podem também, bloquear arquivos ou ocupar recursos escassos e valiosos. O pior é quando o cliente se recupera e faz uma nova chamada remota, e a resposta do processamento órfão chega logo depois ao cliente. Algumas soluções para isso são comentadas a seguir. A primeira é chamada de Extermínio e diz que antes que o stub de cliente envie uma mensagem de chamada a procedimento remoto, ele deve gravar em um arquivo a informação do que pretende obter com a chamada, este é mantido em um disco ou em outro meio de armazenamento que sobreviva as eventuais quedas. Após um novo boot, o arquivo é repassado e os órfão são assassinados um a um. Uma desvantagem é o desperdício de disco. Outra, é que estes órfãos podem fazer outras chamadas remotas, criando outros órfãos dependentes e impossíveis de serem localizados. Alem disso, a rede pode ser dividida com a queda de um gateway, tornado impossível que os órfãos sejam exterminados mesmo sendo localizados. A segunda solução é denominada Reencarnação. Aqui, não há a necessidade de utilizar registros em discos. Ela divide o tempo em é poças numeradas seqüencialmente. Ao se recuperar Gláucia Faria Vieira / Hima Carla Belloni Mourão 7

8 de uma falha, o cliente envia uma mensagem em broadcast para todas as máquinas da rede, informando o inicio de uma nova época, assim todos os processamentos remotos anterior mente solicitados por este cliente, serão eliminados. Mesmo assim, poderão restar alguns processamentos órfãos se a rede for particionada com a falha de um gateway, mas ao receber seus resultados, o cliente observará o numero de uma época obsoleta, não os considerando. Uma variação da idéia acima, é a Reencarnação branda. Aqui, ao receberem a mensagem de broadcast, as maquinas verificam se existem algum processamento remoto solicitado, e se houver tenta localizar o seu proprietário, e somente se este não puder ser localizado é que o processamento é descartado. A ultima solução é chamada expiração, na qual é dada uma fatia de tempo T a cada chamada remota, para que elas possam realizar seu trabalho. Se neste tempo o trabalho não terminar, é preciso solicitar explicitamente um novo quantum de tempo. Por outro lado, se após uma queda o servidor esperar por um tempo T antes de entrar novamente no ar, terá a certeza de que todos os processamentos órfãos terão sido eliminados. O problema é a escolha de T, tarefa não muito fácil, em razão da natureza completamente diversa das chamadas a procedimento. 6. Aspectos relativos à implementação O sucesso ou fracasso de um sistema distribuído depende fundamentalmente de sua performance. Por sua vez, a performance do sistema depende da velocidade da comunicação entre suas partes componentes. O segredo de uma boa velocidade de comunicação esta muito mais ligado aos aspectos de implementação do que aos princípios abstratos. A seguir serão analisados estes aspectos. Protocolos para Chamadas a procedimentos remotos O primeiro ponto a ser analisado, é quanto ao uso de protocolo orientado a conexão ou que não requer conexão explicita entre as partes comunicantes. No primeiro caso, a partir do momento em que o cliente se liga ao servidor, fica estabelecida uma conexão explicita entre eles, e todo o trafego passa por ela, em ambas as direções. A vantagem da conexão é que ela torna a comunicação muito mais fácil. O kernel ao enviar uma mensagem, não precisa aguardar uma confirmação e nem se preocupar se ela se perdeu, pois isso é tratado pelo software que roda em baixo nível. Esta vantagem é muito importante para redes de longa distância. Porém, para uma rede local, a garantia de haver perda de pacotes, não é muito importante, sendo que a própria rede é confiável, é por isso o uso desse protocolo provoca uma queda de performance nesse tipo de rede, o que é uma desvantagem. Portanto, sistemas distribuídos locais, usam protocolos sem conexão. Gláucia Faria Vieira / Hima Carla Belloni Mourão 8

9 Outra questão é a escolha de um protocolo-padrão, ou um especialmente projetado para CPR. Para se tem um protocolo customizado, é necessário o desenvolvimento de seu próprio protocolo. Porém, alguns sistemas distribuídos utilizam o IP (e UDP) como protocolo básico, por ser um protocolo já desenvolvido, economizando trabalho, além de serem aceitos por sistemas UNIX e redes já existentes, como a Internet. Um último aspecto é o tamanho dos pacotes e das mensagens transferidas. Sendo que um sistema de CPR gera um overhead grande e fixo, é importante que tanto o protocolo quanto a rede permitam a transmissão de um grande volume de dados. Por exemplo, ler um arquivo de 64K em uma única chamada remota que transfira os 64K de uma vez, é muito mais eficiente que fazer 64 chamadas de 1k. Confirmação de Pacote Quanto à confirmação de pacotes, há duas estratégias conhecidas. Uma delas é a chamada Protocolo Pare-e-espere, faz com que o cliente envia um pacote e espera uma confirmação, e só após isso, envia outro pacote, sendo isso feito até o último ser enviado. Neste caso, se um pacote for danificado ou perdido, o cliente tem como saber qual é o pacote e retransmiti-lo, pois não irá receber a confirmação em tempo. Outra estratégia é o Protocolo em Rajadas que diz que o cliente deve enviar todos os pacote tão rápido quanto puder. Neste caso o servidor reconhece a mensagem inteira, quando todos os pacotes forem recebidos. Portanto, se um pacote 1 foi perdido, mas o pacote 2 chega sem problemas, o servidor pode aguardar que a temporização do cliente expire e que este retransmita toda mensagem. Uma outra alternativa, é que o servidor pode guardar os pacotes recebidos em buffer e então solicitar que o cliente retransmita apenas o pacote perdido, essa técnica é chamada de repetição seletiva. Um aspecto importante relacionado com a confirmação de pacotes é o fluxo de controle. Muitos chips de interface de rede são capazes de enviar pacotes consecutivamente sem quase nenhum intervalo entre eles, mas estes mesmos chips normalmente não têm como receber um numero ilimitado de pacotes, devido à sua capacidade de armazenamento ser finita. Quando um pacote chega e o receptor não esta preparado para aceitá-lo, vai haver a indicação de um erro especifico, denominado erro causado por excesso de pacotes, e o pacote é perdido. Com o protocolo pare-e-espere não há possibilidade de ocorrência deste erro, pois o segundo pacote não é enviado ate que o receptor tenha indicado explicitamente que ele está pronto par recebe-lo. Já com o protocolo em rajadas, esse erro é possível, porem pode ser lidado com a introdução de um retardo entre o envio de dois pacotes consecutivos. Se o retardo necessário for pequeno, o transmissor pode aguardar em um loop de espera ocupada, se for grande, ele pode setar um temporizador e ir fazer alguma outra coisa até que o temporizador o interrompa. Se o retardo for médio, a melhor opção é a espera ocupada. Gláucia Faria Vieira / Hima Carla Belloni Mourão 9

10 Caminho Crítico A seqüência de instruções que é executada a cada chamada remota é denominada de Caminho Crítico. Começa na chamada do cliente ao stub do cliente e termina no servidor que executa o trabalho solicitado e despacha a resposta através do caminho inverso. O principal interesse, é saber em que parte do caminho critico é consumido mais tempo. Portanto, vale ressaltar alguns pontos deste caminho. Um, por exemplo, é após a chamada ao stub do cliente, quando é adquirido um buffer para que o cliente possa montar a mensagem entrante. Em certos sistemas, o stub do cliente dispõe de um buffer fixo, utilizado em cada chamada. Porem um método mais interessante para economia de tempo, quando o formato do pacote tem um número substancial de campos que devem ser preenchidos, mas que não mudam de uma chamada para outra, é a presença de um pool de buffers que são alocados aos servidores quando necessário. Após o kernel do usuário ser interrompido por um trap, e este entregar a mensagem à interface de rede para que ela seja transmitida, termina o caminho critico do cliente. Nada que o kernel faça agora afeta o tempo necessário para o pacote chegar ao servidor. Portanto, após inicializar o temporizador de retransmissor, o kernel pode entrar num loop de espera ocupada para esperar pela resposta, ou chamar o escalonador de processos a fim de escolher um outro processo para rodar. A primeira escolha acelera o processamento da resposta, mas inibe qualquer possibilidade de multiprogramação. Uma análise feita para chamadas remotas nula e com parâmetros, mostra que na primeira os custos de tempo dominantes dizem respeito a troca de contexto para o stub do servidor quando o pacote chega, à rotina de tratamento de interrupção, e ao movimentos dos pacotes para a interface de rede. Já na chamada remota com parâmetro, o grande gasto de tempo é o de transmissão pela Ethernet, e com o tempo de movimentação de pacotes de/par a interface de rede vindo logo atrás. Cópia A questão das cópias é um aspecto que com freqüência domina os tempos gastos na execução das chamadas remotas. O numero de vezes que uma mensagem precisa ser copiada varia de uma a oito, dependendo do hardware, do software e dotipo de chamada. No melhor caso, o chip de interface de rede pode receber diretamente a mensagem do stub de cliente (cópia 1), usando a técnica DMA (Acesso direto a memória) e depois depositando-a na memória do kernel do servidor em tempo real, ou seja, a interrupção da chegada do pacote ocorre poucos microsegundos após o ultimo bit ser retirado por DMA da memória do stub do cliente. Então o kernel inspeciona o pacote e mapeia a pagina que o contem no espaço de endereçamento Gláucia Faria Vieira / Hima Carla Belloni Mourão 10

11 do servidor.e este tipo de mapeamento não for possível de ser realizado, o kernel copia o pacote para o stub do servidor (copia 2). No pior caso, o kernel copia a mensagem do stub do cliente para um buffer do kernel para posterior transmissão por não ser conveniente realizar a transmissão diretamente do espaço do usuário ou porque a rede esta ocupada no momento (cópia 1). Mais tarde o kernel copia a mensagem por software para um buffer em hardware na interface de rede (copia 2). Neste momento o hardware é inicializado, fazendo com que o pacote seja transferido através da rede para a place de interface de rede na maquina-destino (copia 3). Quando a interrupçao de chegada de pacote ocorrer na maquina servidora, o kernel deve copiar a mensagem para um buffer interno, provavelmente por ele não ter onde guardá-la para exame (copia 4). Finalmente a mensagem deve ser copiada para o stub do servidor (copia 5). Alem disso, se a chamada envolver um array deve ser copiado na pilha do cliente para chamar o stub, da pilha para o buffer de mensagens durante a ordenação dentro do stub do cliente, e da mensagem entrante para o stub do servidor, ou seja, mais três copias, perfazendo um total de oito. Uma característica do hardwre que ajuda muito na eliminação de copias desnecessárias, é chamado scatter-gather. A vantagem desse método reside em poder construir o cabeçalho do pacote no espaço do kernel, deixando os dados do usuário no stub do cliente, com o hardware sendo responsável por coloca-los juntos quando o pacote for enviado. Usando hardware apropriado, um cabeçalho de pacote reutilizável armazenado no kernel e um buffer de dados no espaço do usuário podem ser entregues a rede sem a necessidade de copias internas, no lado do transmissor. No entanto, ao chegar no receptor, nem mesmo um hardware inteligente será capaz de descobrir a qual servidor entregar este pacote, de maneira que o melhor a ser feito pelo hardware é colocar o pacote no buffer do kernel, e deixar que o kernel descubra o que deve ser feito com ele. Gerência do tempo A maioria dos protocolos inicializa um temporizador sempre que uma mensagem é expedida e uma resposta é esperada. Se a resposta não chegar em determinado tempo, o temporizador sinaliza, e a mensagem original é transmitida. A sinalização de um temporizador, requer a construção de uma estrutura de dados que especifica quando ao temporizador deve sinalizar. A estrutura de dados é então inserida em uma lista de todas as outras temporizações pendentes. Em geral a lista é mantida pelo tempo, com a próxima temporização a expirar ocupando a cabeça da lista, e mais distante no fim da lista. Quando chegam um reconhecimento ou uma resposta antes da temporização correspondente expirar, a entrada na lista referente a esta temporização deve ser localizada e removida. Gláucia Faria Vieira / Hima Carla Belloni Mourão 11

12 Valores muito baixos vão fazer com que os temporizadores expirem muito rapidamente, resultando em transmissões desnecessárias. Por outro lado, valores muito altos causam um retardo desnecessariamente grande quando o pacote for realmente perdido. Uma forma diferente e mais eficiente de tratar os temporizadores é utilizada por vários sistemas. Estes sistemas mantêm uma tabela de processos, onde cada entrada possui informações sobre cada um dos processos. Ao invés de armazenar temporizações em uma lista ordenada, cada entrada da tabela de processos tem um campo para armazenar suas temporizações. A inicialização de um temporizador para determinada chamada remote, agora consiste simplesmente em colocar no campo apropriado da tabela de processos, o valor do tempo escolhido. Para zerar um temporizador, basta armazenar o valor zero no campo correspondente. Desta forma, as operações de inicializar e zerar temporizadores ficam reduzidas a umas poucas instruções de maquina. O kernel deve periodicamente, uma vez por segundo, percorrer toda a tabela, verificando o estado de cada um dos temporizadores, e confrontando-os com o tempo real. Qualquer valor não nulo e menor ou igual ao tempo real corresponde a um temporizador expirado, que deve ser então processado e resetado. Algoritmos como este, são chamados de sweep algorithms. Gláucia Faria Vieira / Hima Carla Belloni Mourão 12