Adaptaes do Linux para Suportar Aplicaes com Requisitos de Tempo Real

Rmulo Silva de Oliveira LCMI-DAS - Universidade Federal de Santa Catarina Caixa Postal 476, Florianpolis-SC, 88040-900
romulo@das.ufsc.br

Abstract. Real-time applications are built more easily if they can take advantage of the services of an operating system. This paper initially discusses constructive aspects of operating systems and their implications in the perspective of real-time theory. After, five Linux adaptations to support realtime applications are described. Resumo. Aplicaes de tempo real so mais facilmente construdas se puderem aproveitar os servios de um sistema operacional. Este artigo inicialmente discute aspectos construtivos de sistemas operacionais e suas implicaes sob a tica da teoria de tempo real. Em seguida, so descritas cinco adaptaes do Linux para suportar aplicaes de tempo real.

1. Introdu o
Na medida que o uso de sistemas computacionais prolifera em nossa sociedade, aplicaes com requisitos de tempo real tornam-se cada vez mais comuns. Estas aplicaes variam muito com relao ao tamanho, complexidade e criticalidade. Entre os sistemas ma is simples esto os controladores embutidos em utilidades domsticas, tais como lavadoras de roupa e videocassetes. Na outra extremidade deste espectro esto os sistemas militares de defesa e o controle de trfego areo. Exemplos de aplicaes crticas so os sistemas responsveis pela monitorizao de pacientes em hospitais e os sistemas embarcados em veculos, de automveis at avies e sondas espaciais. Entre aplicaes no crticas esto os videogames e as aplicaes multimedia. Entre os sistemas de tempo real podemos destacar aqueles identificados como sistemas tempo real embutidos (embedded real-time systems). Um sistema computacional embutido corresponde a um ou mais microprocessadores, um sistema operacional e um software aplicativo que ficam inseridos em um produto maior para processar as funes de controle deste produto. O projeto de um sistema computacional de propsito geral deve considerar as possveis necessidades de um enorme espectro de usurios. Diferentemente, um sistema computacional embutido deve suportar apenas um conjunto restrito de funes, definidas pelo equipamento maior no qual ele est inserido. Uma vez que tanto a aplicao como o sistema operacional (SO) compartilham os mesmos recursos do hardware, o comportamento temporal do SO afeta o comportamento temporal da aplicao. Por exemplo, considere a rotina do sistema operacional que trata as interrupes do relgio de hardware. O projetista da aplicao pode ignorar completamente a funo desta rotina, mas no pode ignorar o seu efe ito temporal, isto , a interferncia que ela causa na aplicao.

A teoria de escalonamento tempo real teve um grande avano nos ltimos anos. Apesar disto, ainda no corrente o uso da teoria de tempo real na modelagem e anlise de sistemas operacionais complexos. Mais do que isto, aplicaes com deadlines crticos ainda hoje empregam apenas pequenos ncleos de tempo real, que implementam um conjunto limitado de servios, mas so capazes de oferecer previsibilidade determinista. Sistemas operacionais com funcionalidade completa, incluindo sistema de arquivos, interface grfica de usurio e protocolos de comunicao, suportam apenas tempo real brando. Este artigo investiga as prticas normalmente usadas na construo de sistemas operacionais. Busca-se determinar os efeitos dos mecanismos empregados, ao mesmo tempo que so feitas indicaes sobre quais mecanismos so mais apropriados para a construo de um sistema operacional que dever suportar aplicaes com requisitos de tempo real. So tambm descritas diversas variaes do sistema operacional Linux para melhor atender as demandas de tempo real. Algumas questes de modelagem discutidas aqui apareceram antes na literatura [AUDSLEY 1993]. Pesquisas recentes focaram alguns dos aspectos construtivos abordados neste artigo. Em [ABENI 2002] so discutidos temporizadores e preempo. Em [CARLSSON 2002] considerado o problema da determinao do tempo de execuo no pior caso do cdigo encontrado em sistemas operacionais. Em [MEHNERT 2002] analisado o custo de manter espaos de endereamento separados. O propsito deste trabalho colaborar para a anlise qualitativa dos ncleos dos sistemas operacionais que pretendem suportar aplicaes de tempo real. Em especial, aqueles sistemas operacionais derivados do Linux. Em [OLIVEIRA 2003] aparece uma verso preliminar dos aspectos construtivos, sem os estudos de caso. A seo 2 discute vrios aspectos construtivos de SO sob a luz da teoria de escalonamento. A seo 3 descreve diversas adaptaes feitas no sistema operacional Linux no sentido do mesmo suportar aplicaes de tempo real. A seo 4 apresenta as concluses.

2. Anlise dos Aspectos Construtivos dos Sistemas Operacionais

Esta seo analisa de que maneiras o sistema operacional impacta o tempo de resposta das tarefas de tempo real. Em outras palavras, quais os aspectos mais relevantes na construo de um sistema operacional de tempo real. 2.1 Algoritmo de Escalonamento Apropriado Ao considerar como o sistema operacional pode afetar o comportamento da aplicao no tempo, o primeiro aspecto lembrado o algoritmo de escalonamento. Do ponto de vista da anlise de escalonabilidade, deseja-se um algoritmo para o qual a literatura oferea um mtodo de anlise e testes de escalonabilidade. A literatura bastante rica nesse sentido, oferecendo um grande leque de possibilidades. No contexto da teoria baseada em prioridades preemptivas, isto no um problema, pois este o algoritmo implementado pela maioria dos sistemas operacionais de tempo real. 2.2 Nveis de Priorida de Suficientes Embora o escalonamento baseado em prioridades seja suportado pela maioria dos sistemas operacionais, o nmero de diferentes nveis de prioridade varia bastante. Por exemplo, o padro POSIX da IEEE exige no mnimo 32 nveis de prioridade. Em

[CAYSSIALS 1999] mostrado que, quando o nmero de nveis de prioridade disponveis menor do que o nmero de tarefas, passa a ser necessrio agrupar vrias tarefas no mesmo nvel, o que diminui a escalonabilidade do sistema. Ainda em [CAYSSIALS 1999] apresentado um algoritmo para calcular o nmero mnimo de nveis de prioridade onde o sistema ainda escalonvel, quando Taxa Monotnica usada como poltica de atribuio de prioridades. Em [AUDSLEY 2001] o mesmo problema atacado, mas a partir de um algoritmo timo para atribuio de prioridades. Em termos de modelagem, o ideal que o nmero de nveis de prioridade seja igual ao nmero de tarefas no sistema. 2.3 Alterao das Prioridades pelo Sistema Operacional Muitos sistemas operacionais manipulam por conta prpria as prioridades das tarefas. Por exemplo, o mecanismo de envelhecimento (aging) usado por vezes para aumentar temporariamente a prioridade de uma tarefa que, por ter prioridade muito baixa, nunca consegue executar. Muitos sistemas operacionais de propsito geral (SOPG) tambm incluem mecanismos que reduzem automaticamente a prioridade de uma thread na medida que ela consome tempo de processador. Este mecanismo utilizado para favorecer as tarefas com ciclos de execuo menor e diminuir o tempo mdio de resposta no sistema. Esses mecanismos fazem sentido em um SO de propsito geral, quando o objetivo estabelecer um certo grau de justia entre tarefas e evitar postergao indefinida. No contexto de tempo real no existe preocupao com justia na distribuio dos recursos mas sim com o atendimento dos deadlines. Para efeitos de anlise, esses mecanismos, alm de no contribuir para a qualidade temporal, tornam mais complexo o esforo de modelagem e devem ser evitados. 2.4 Tratadores de Interrupes Parte importante de qualquer sistema operacional a execuo dos tratadores de interrupo. Eles so responsveis pela ateno do sistema a eventos externos, como alarmes ou a passagem do tempo. Ao mesmo tempo, eles so uma importante fonte de interferncia sobre as demais tarefas. Para efeito de modelagem, cada tratador de interrupo considerado como tarefa de prioridade mais alta do que tarefas normais. Muitos tratadores de interrupo apresentam comportamento espordico, como aqueles associados com teclados, controladores de disco e de rede. Embora difcil, o estabelecimento de um intervalo mnimo entre ativaes para esses tratadores uma necessidade matemtica para a anlise quantitativa do sistema. A prtica corrente dos SOPG no colocar restries quanto a freqncia de interrupes de qualquer tipo. Entretanto, a pseudo-tarefa tratador de interrupo tem uma alta prioridade no sistema e sua capacidade de gerar interferncia grande. Ela deve ser controlada em sistemas operacionais para aplicaes de tempo real. 2.5 Latncia dos Tratadores de Interrupes O tempo entre a sinalizao de uma interrupo no hardware e o inicio da execuo de seu tratador normalmente chamado de latncia do tratador de interrupo. A latncia no disparo de um tratador de interrupo inclui o tempo que o hardware leva para realizar o processamento de uma interrupo, isto , salvar o contexto atual (program

counter e flags) e desviar a execuo para o cdigo do tratador. Tambm necessrio incluir o tempo mximo que as interrupes podem ficar desabilitadas. Por vezes, trechos de cdigo do sistema operacional precisam executar com as interrupes desabilitadas. Por exemplo, quando acessada uma estrutura de dados tambm usada por tratadores de interrupo. O atraso no reconhecimento da interrupo pode ser modelado como um release jitter associado com cada pseudo-tarefa tratador de interrupo. Muitas arquiteturas associam prioridades aos diversos tipos de interrupo. Dessa forma, uma interrupo de alto nvel pode suspender temporariamente a execuo do tratador da interrupo de baixo nvel. Esta situao coerente com a idia de uma pseudo-tarefa de prioridade alta interferindo com uma pseudo-tarefa de prioridade baixa. Por outro lado, o incio do tratador de interrupo de baixo nvel pode ser obrigado a esperar a concluso do tratador da interrupo de alto nvel. Para efeitos de modelagem, uma pseudo-tarefa associada com um dado tratador de interrupo recebe interferncia quando atrapalhada por um tratador de interrupo mais prioritria, mas sofre release jitter quando atrasa em funo de uma tarefa de prioridade mais baixa desabilitar interrupes. 2.6 Threads de Kernel Muitos sistemas operacionais incluem threads de kernel com execuo peridica, responsveis pelas tarefas de manuteno. Por exemplo, escrever partes da cache do sistema de arquivos para o disco, atualizar contabilizaes, etc. importante que essas threads de kernel faam parte do esquema global de prioridades. Dado o carter essencial de algumas dessas atividades, pode ser necessrio que elas possuam prioridade superior s tarefas da aplicao. Isto no um problema, desde que fique bem caracterizado quais so essas tarefas, com o perodo, o tempo mximo de computao e a prioridade de cada uma. Uma soluo paliativa, adotada em sistemas que no suportam threads de kernel, anotar trabalhos a serem feitos em listas, e depois execut- los em momentos pr-estabelecidos, tais como uma chamada de sistema ou uma interrupo de hardware. Esta soluo de projeto dificulta a modelagem, pois o trabalho em questo representa uma carga que executa no conforme a sua prioridade, mas conforme a dinmica do sistema. Por exemplo, se um trabalho for executado no mo mento que a tarefa executando faz uma chamada de sistema, ele ter a prioridade da tarefa executando. Se ele for executado na prxima interrupo de relgio, ele ter a prioridade da pseudotarefa tratador do relgio. Esse esquema efetivamente cria tarefas no s com prioridades variveis, mas com prioridades que variam conforme a dinmica do sistema, tornando muito difcil qualquer anlise. 2.7 Implementao das Filas Tradicionalmente, so utilizados algoritmos e estruturas de dados convencionais, tais como listas encadeadas, na implementao das filas dentro dos sistemas operacionais, por exemplo filas de espera e a prpria fila do processador. O processamento de listas encadeadas introduz substancial overhead em cenrios de pior caso, como na liberao simultnea de vrias tarefas peridicas. A complexidade computacional desta operao est associada com O(n2 ), pois no pior caso necessrio mover n tarefas da lista

encadeada de espera (por exemplo, a lista de espera pela passagem de tempo) para a lista encadeada que representa a fila do processador [KATCHER 1993]. Segundo [ANGELOV 2002], o problema do overhead associado com a liberao de tarefas pode ser minimizado atravs da substituio da tradicional implementao da fila do processador como uma lista encadeada. No lugar, a fila do processador pode ser pensada como um conjunto de vetores booleanos, resultando em operaes rpidas e tempo de execuo constante, independente do nmero de tarefas envolvidas. 2.8 Tempo de Chaveamento entre Tarefas Uma mtrica muito citada no mercado de sistemas operacionais o tempo para chaveamento de contexto entre duas tarefas. Este tempo inclui salvar os registradores da tarefa que est executando e carregar os registradores com os valores da nova tarefa, incluindo qualquer informao necessria para a MMU ( emory management unit) m funcionar corretamente. Em geral, esta mtrica no inclui o tempo necessrio para decidir qual tarefa vai executar, uma vez que isto depende do algoritmo de escalonamento utilizado. Em termos de modelagem, o tempo de chaveamento pode ser somado ao tempo mximo de execuo de cada tarefa. Necessariamente, cada ativao de cada tarefa dever carregar o seu contexto. Se a tarefa em questo preemptada por outra, a interferncia que ela sofre da outra incluir o tempo de chaveamento de contexto, o qual foi tambm somado no tempo mximo de execuo da outra tarefa. 2.9 Temporizadores de Alta Resoluo Sistemas operacionais em geral oferecem temporizadores para as tarefas da aplicao, que armam temporizaes ao final das quais uma determinada ao ocorre. Essa ao pode ser o envio de um sinal Unix ou a liberao da tarefa aps um sleep. Temporizadores so utilizados na implementao de time-out e tarefas peridicas. Nos SOPG temporizadores so implementados atravs de interrupes peridicas geradas por um relgio de hardware. Por exemplo, a cada 10ms uma interrupo gerada. Essa implementao pode gerar erros grosseiros. Suponha que um sleep(15ms) solicitado imediatamente aps a ocorrncia de uma interrupo do relgio. A tarefa em questo vai esperar 10ms at a prxima interrupo, quando o sistema inicia a contagem do tempo. E dever esperar mais 20ms, pois as interrupes acontecem de 10 em 10ms. Ao final, a espera de 15ms consumiu um total de 30ms. SOTR utilizam temporizadores de alta resoluo, baseados em interrupes aperidicas. O relgio de hardware no gera interrupes peridicas mas programado para gerar uma interrupo no prximo momento de interesse. Considerando o exemplo anterior e supondo ser esta espera o prximo evento de interesse, o relgio do hardware seria programado para gerar uma interrupo exatamente no momento esperado pela tarefa em questo. O tratador de interrupes de relgio peridicas pode ser modelado como uma tarefa peridica cujo perodo o intervalo entre interrupes, o tempo de execuo a durao do cdigo do tratador e o release jitter corresponde a latncia de interrupes do sistema. Entretanto, o temporizador de alta resoluo no peridico, mas sim

espordico. Alm disso, seu intervalo mnimo entre ativaes depende da dinmica das tarefas do sistema. Como esse tratador sempre executado em funo de uma temporizao solicitada por uma tarefa, mais apropriado model- lo associado com as prprias tarefas. Para efeitos de anlise temos uma relao de precedncia entre a pseudo-tarefa tratador da interrupo e a tarefa executada depois. O perodo no determinado pelo tratador mas sim pela tarefa que solicita a temporizao. A latncia de interrupes continua sendo um release jitter para o tratador. O tempo de computao necessrio para manipular as filas associado com o tratador, enquanto o tempo necessrio para carregar o contexto da tarefa somado ao tempo de execuo dela. As prioridades so diferentes, pois o tratador possui prioridade alta no sistema, enquanto a tarefa em si pode possuir qualquer prioridade, coerente com o fato de a execuo da tarefa liberada poder no ser imediata, dependendo da prioridade da tarefa em execuo. 2.10 Comportamento das Chamadas de Sistema no Pior Caso Para as aplicaes de tempo real, o tempo de execuo no pior caso mais relevante do que o tempo de execuo no caso mdio. Em geral, a implementao das chamadas de sistema feita de maneira a minimizar o tempo mdio. Aplicaes de tempo real so beneficiadas quando o cdigo que implementa as chamadas de sistema apresenta bom comportamento tambm no pior caso. Na construo de um SOTR devem ser evitados algoritmos que apresentam excelente comportamento mdio porm um pssimo comportamento de pior caso decorrente de uma situao cuja probabilidade de ocorrer muito baixa, porm no nula. Busca-se aqui reduzir o tempo mximo de execuo de uma tarefa que, como parte de sua execuo, faz uma chamada de sistema. O maior problema est na dependncia que pode haver entre o tempo de execuo da chamada de sistema e o estado do SO quando a chamada feita. Quanto mais complexo for o SO, mas difcil calcular este tempo. 2.11 Preempo de Tarefa Executando Cdigo do Sistema Um kernel no preemptivo capaz de gerar grandes inverses de prioridade. Suponha que uma tarefa de baixa prioridade faa uma chamada de sistema e, enquanto o cdigo do kernel executado, ocorre a interrupo de hardware que deveria liberar uma tarefa de alta prioridade. Nesse tipo de kernel a tarefa de alta prioridade ter que esperar at que a chamada de sistema da tarefa de baixa prioridade termine, para ento executar. Temos ento que o kernel est executando antes o pedido de baixa prioridade, em detrimento da tarefa de alta prioridade. Um kernel com pontos de preempo reduz o problema, mas ainda permite a inverso de prioridades, quando a chamada de sistema de baixa prioridade prossegue sua execuo em detrimento da tarefa de alta prioridade at encontrar um ponto de preempo. Um SOTR deve ser preemptivo, ainda que em determinados momentos interrupes precisem ser desabilitadas em funo das estruturas de dados acessadas. 2.12 Mecanismos de Sincronizao Apropriados A literatura de tempo real rica em mecanimos de sincronizao apropriados para tempo real, como mutexes que incorporam herana de prioridade, priority ceiling, etc. Recursos semelhantes existem para sincronizao tempo real baseada em mensagens,

tais como mensagens com prioridades, priority ceiling para threads tratando mensagens, etc. Tais mecanismos reduzem a inverso de prioridades dentro do kernel, reduzindo o tempo de bloqueio sofrido por tarefas que fazem chamadas de sistema. 2.13 Granularidade das Sees Crticas dentro do Kernel Um kernel preemptivo capaz de chavear imediatamente para a tarefa de alta prioridade quando o mesmo liberado. Entretanto, inverso de prioridade dentro do kernel ainda possvel quando a tarefa de alta prioridade recm ativada faz uma chamada de sistema mas bloqueada em funo da necessidade de acessar, dentro do kernel, uma estrutura de dados compartilhada que foi anteriormente alocada por uma tarefa de mais baixa prioridade. Mesmo mecanismos apropriados de sincronizao no c onseguem evitar esta situao, decorrente do fato de duas tarefas acessarem a mesma estrutura de dados. Manter uma granularidade fina para as sees crticas dentro do kernel, embora aumente a complexidade do cdigo, reduz o tempo que uma tarefa de alta prioridade precisa esperar at que uma tarefa de baixa prioridade libere a estrutura de dados compartilhada. Em termos de modelagem, temos a reduo do tempo de bloqueio sofrido pela tarefa mais prioritria. 2.14 Gerncia de Recursos em Geral Todos os sistemas operacionais desenvolvidos ou adaptados para tempo real mostram grande preocupao com a diviso do tempo do processador entre as tarefas. Entretanto, o processador apenas um recurso do sistema. Memria, perifricos, controladores, servidores tambm deveriam ser escalonados visando atender os requisitos temporais da aplicao. Muitos sistemas ignoram isto e tratam os demais recursos da mesma maneira empregada por um SOPG, isto , tarefas so atendidas pela ordem de chegada. Todas as filas do sistema deveriam respeitar as prioridades das tarefas, e no apenas a fila do processador. Por exemplo, as requisies de disco deveriam ser ordenadas conforme a prioridade e no pela ordem de chegada ou para minimizar o tempo de acesso. Quando um recurso acessado pela ordem de chegada temos a possibilidade de bloqueio da tarefa mais prioritria pela menos prioritria. Este bloqueio pode ser devastador para a escalonabilidade, pois sua durao est associada com toda a fila de tarefas que existia quando a tarefa de alta prioridade solicitou o recurso. 2.15 Tratadores de Dispositivos (Device-Drivers) Por vezes a execuo de uma tarefa de alta prioridade suspensa temporariamente, quando ocorre uma interrupo de perifrico. O processador passa a executar o tratador de interrupo includo em device-driver associado com o perifrico em questo. Muitos sistemas no limitam o tempo de execuo desse tratador, permitindo na prtica que o cdigo associado com o device-driver em questo tenha uma prioridade maior do que qualquer tarefa no sistema e execute por quanto tempo quiser. Em termos de modelagem, isto significa uma tarefa com tempo de execuo possivelmente longo e alta prioridade, gerando interferncia em todas as tarefas do sistema, sendo sua alta prioridade decorrente no de uma poltica de prioridades explcita, mas de um efeito colateral da construo do SO. Em um SOTR, os tratadores de interrupo associados com device-drivers simplesmente devem liberar threads de kernel as quais seriam responsveis pela

execuo do cdigo que efetivamente responde ao sinal do perifrico. Fazendo com que as threads de kernel respeitem a estrutura de prioridades do sistema, fica restaurado o desejo do programador com respeito aos tempos de resposta das tarefas. Por exemplo, o teclado pode ser considerado um perifrico de baixa prioridade. Caso acontea uma interrupo de teclado durante a execuo da tarefa de alta prioridade, o tratador de interrupes do teclado simplesmente coloca a thread Atende Teclado na fila do processador e retorna. A tarefa de alta prioridade pode concluir sua execuo e depois disso o atendimento ao teclado propriamente dito ser feito pela thread correspondente.

3. Exemplos de Suportes para Tempo Real Baseados no Linux

Existem dezenas seno centenas de suportes para tempo real, nos mais variados nveis de preo, robustez, funcionalidade e previsibilidade temporal. O conjunto de solues escolhido para ser apresentado aqui procura ilustrar os tpicos apresentados nas sees anteriores, sem ter a preteno de ser um levantamento preciso do mercado. Sero descritas variaes do Linux para tempo real, cada uma alterando o kernel convencional do Linux de uma maneira especfica. Linux um sistema operacional com fonte aberto, estilo Unix, originalmente criado por Linus Torvalds a partir de 1991 com o auxlio de desenvolvedores espalhados ao redor do mundo [BOVET 2001]. Linux "free software" no sentido que pode ser copiado, modificado, usado de qualquer forma e redistribudo sem nenhuma restrio. Entretanto, ningum criando uma adaptao do Linux pode tornar o produto resultante proprietrio, pois o mesmo desenvolvido sob o "GNU General Public License". O Linux convencional segue o estilo de um kernel Unix tradicional, no baseado em microkernel, e no apropriado para aplicaes de tempo real [EULER 1999]. Entretanto, o kernel do Linux possui um recurso que facilita sua adaptao para o contexto de tempo real. Embora o kernel ocupe um nico espao de endereamento, ele aceita mdulos carregveis em tempo de execuo, os quais podem ser includos e excludos do kernel sob demanda. Estes mdulos executam em modo privilegiado e so usados normalmente na implementao de tratadores de dispositivos (device-drivers), sistemas de arquivos e protocolos de rede. No caso dos sistemas de tempo real, esta caracterstica facilita a transferncia de tecnologia da pesquisa para a prtica. Solues de escalonamento tempo real podem ser implantadas dentro do kernel de um sistema operacional de verdade. Como o cdigo fonte do Linux aberto, possvel estudar o seu comportamento temporal, algo que impossvel com SOTR comerciais cujo kernel tipicamente uma caixa preta. 3.1 KURT Linux O KURT-Linux [SRINIVASAN 1998], ou "Kansas University Real Time Linux" um sistema operacional de tempo real que permite o escalonamento explcito e relativamente preciso no tempo de qualquer evento, inclusive a execuo de tarefas com restries de tempo real. KURT-Linux uma modificao do kernel convencional, onde destaca-se o aumento na preciso da marcao da passagem do tempo real atravs do emprego de temporizadores com alta resoluo. Como conseqncia, tem-se uma maior preciso nas

aes associadas com a passagem do tempo. Uma importante constatao foi que a programao explcita do relgio de hardware para cada evento de interesse, usando uma resoluo de microsegundos, gerou uma carga adicional pequena para o sistema. Vrias tcnicas foram usadas em conjunto para obter maior preciso de relgio e manter funcionando o cdigo do kernel que supe interrupes peridicas de relgio. No KURT-Linux, mdulos de tempo real pertencentes a aplicao so incorporados ao kernel. Eles executam em modo kernel e podem acessar todos os recursos do sistema. O escalonamento feito atravs de uma lista que informa qual rotina presente em um mdulo de tempo real deve executar quando. Toda rotina de tempo real executa a partir da hora marcada e suspende a si prpria usando uma chamada de sistema apropriada. Desta forma, a preciso do relgio transferida para o comportamento das tarefas. O sistema operacional supe que os mdulos de tempo real so bem comportados e no vo exceder o tempo de processador previamente alocado. Embora este tipo de escalonamento seja menos flexvel do que o baseado em prioridades, ele ainda suficiente para um grande conjunto de aplicaes. Os autores do KURT-Linux atestam que nunca foi o objetivo do projeto suportar todos os algoritmos de escalonamento tempo real presentes na literatura. Tarefas de tempo real peridicas tambm so aceitas. Elas definem o perodo desejado e so ativadas pelo KURT-Linux no incio de cada perodo. Quando a tarefa completa uma dada ativao, ela suspende a si mesma, para ser acordada pelo sistema no incio do prximo perodo. Uma extenso ao modelo original permite que uma tarefa programada como um lao infinito (um servidor) execute em determinados momentos previamente reservados. Por exemplo, execute 100 microsegundos dentro de cada milisegundo. Solues de escalonamento baseadas no conceito de utilizao do processador podem ser implementadas atravs deste mecanismo. KURT-Linux capaz de prover uma excelente preciso com respeito ao instante de liberao das tarefas de tempo real. Atravs da construo e manuteno de uma escala de execuo apropriada, a interferncia entre tarefas de tempo real pode ser resolvida. Entretanto, o esquema adotado limitado pelo cdigo convencional do kernel do Linux, o qual capaz de gerar bloqueios e inverses de prioridade significativas, quando uma tarefa de tempo real solicita algum servio. Tambm os devices-drivers so capazes de reduzir a preciso do sistema atravs da desabilitao de interrupes. Seu momento de execuo no definido pela escala construda, mas sim pelas interrupes de hardware. Mesmo os processos convencionais do Linux podem atrapalhar a execuo das tarefas de tempo real, quando utilizam recursos do kernel que essas necessitam. O sistema permite que a execuo de processos Linux convencionais seja proibida, reduzindo assim as pertubaes sobre os tempo de resposta das tarefas de tempo real. KURT-Linux est baseado no conceito de escala de execuo. Mas, constri a escala de execuo sem considerar as ativaes assncronas dos tratadores de interrupes associados com devices-drivers. Tambm ignora os bloqueios possveis em funo de recursos compartilhados dentro do kernel. Logo, o comportamento do sistema ser tanto melhor quanto as tarefas no utilizarem os servios do kernel do Linux e perifricos no forem utilizados. Seu comportamento ideal acontece quando as tarefas de tempo real realizam suas computaes sem fazer chamadas de sistema e devicedrivers no incluem tratadores de interrupes. Em [SRINIVASAN 1998] sugerido

que os construtores de aplicaes selecionem para uso apenas os subsistemas do Linux cujo efeito sobre o comportamento das tarefas de tempo real seja tolervel. 3.2 Linux/RK Linux/RK foi desenvolvido no Real-time and Multimedia Systems Laboratory na Carnegie Mellon University. Linux/RK implementa no Linux o conceito de resource kernel [OIKAWA 1998] [OIKAWA 1999]. Ele insere no kernel convencional do Linux um mdulo cha mado Portable Resource Kernel, o qual controla o acesso aos recursos fsicos, provendo garantias e ao mesmo tempo impondo limites a esses acessos. Basicamente, aplicaes devem solicitar reservas para determinadas quantidades de cada recurso e o kernel ento garante que os recursos associados com as reservas confirmadas estaro disponveis no momento certo. Em termos de implementao, Linux/RK corresponde a um mdulo carregado no kernel, alm da insero de chamadas em pontos especficos do kernel Linux convencional. O conceito de resource kernel no novo. Existem trabalhos que implementam esta idia no RT-Mach [RAJKUMAR 1998], para processador, disco e rede local. No contexto de um resource kernel, uma reserva representa uma fatia de algum recurso computacional, tal como tempo de processador, memria fsica ou tempo do controlador de disco. A entidade reserva implementada pelo kernel, o qual monitora o seu uso, garantindo a disponibilidade dos recursos para atender as reservas feitas, ao mesmo tempo que impede o uso dos recursos alm dos limites das reservas. Alguns recursos podem ser multiplexados no tempo, como processador, meio de comunicao e acesso ao disco. Cada reserva de recurso multiplexado no tempo caracterizada por um perodo P, um tempo de utilizao C e um deadline D, sendo D? P. Recursos como espao em memria so dedicados, isto , no so multiplexados no tempo. Um conjunto de reservas (resource set usado no original) associado com um ou mais programas e permite o uso exclusivo da quantidade reservada de recursos por estes programas. Um conjunto de reservas agrupa as reservas para os programas associados, permitindo que o kernel detecte qualquer uso indevido de recursos por parte da aplicao. O conjunto de reservas um conceito mais apropriado para o nvel da aplicao, alm de facilitar a implementao dos mecanismos. Por exemplo, cada processo Linux est associado com um conjunto de reservas. O cdigo de aplicao acessa as facilidades do mdulo RK atravs de uma interface composta pelas funes: cria conjunto de reservas, destri conjunto de reservas, associa processo com conjunto de reservas, desassocia processo de um conjunto de reservas, cria uma reserva. No contexto do Linux/RK, o mdulo RK inserido no kernel convencional do Linux responsvel por implementar reservas e conjuntos de reservas, alm dos mecanismos para controle de admisso (decidir se uma reserva aceita ou no), escalonamento de recursos (quando exatamente cada reserva satisfeita), monitorao de uso (quanto de sua reserva cada programa usou) e imposio das reservas (no permitir que programas usem recursos alm do permitido). Em pontos apropriados do kernel do Linux so introduzidas chamadas para o mdulo RK, o qual fornece uma interface apropriada e, por sua vez, utiliza funes do prprio Linux para controlar entidades do kernel, tais como processos e device-drivers. Chamadas para o mdulo RK foram colocadas dentro da funo de escalonamento schedule() do Linux, no atendimento de uma interrupo, no trmino do atendimento

das interrupes e na sada do kernel, quando a execuo passa de modo kernel para modo usurio. Linux/RK tambm utiliza o recurso Proc do sistemas de arquivos para fornecer informaes sobre o sistema, tais como situao das reservas e dos recursos. Um temporizador de alta preciso utilizado para garantir os limites das reservas aceitas. O relgio do hardware sempre programado para gerar uma interrupo no prximo instante de interesse, evitando os erros associados com temporizadores que geram interrupes peridicas. Entretanto, como o kernel do Linux espera interrupes de timer peridicas, o mdulo RK faz a propagao das mesmas para o kernel do Linux nos momentos apropriados. O trabalho realizado no Linux/RK considerou basicamente a questo do compartilhamento do processador. Entretanto, em sistemas operacionais complexos, muitos outros recursos so disputados pelas tarefas. A pesquisa associada com o Linux/RK continua, e pretende integrar a reserva de tempo de acesso ao disco e tempo de acesso a rede. No momento que vrios recursos so gerenciados, necessrio considerar o co-escalonamento de mltiplos recursos, isto , considerar que o processo em questo pode precisar utilizar suas reservas dos vrios recursos simultaneamente para realizar o seu trabalho. O mecanismo de reservas limitado para o caso de tarefas espordicas, isto , tarefas cujo momento de ativao no conhecido, embora exista um intervalo mnimo de tempo entre ativaes. Sistemas baseados em prioridades conseguem lidar naturalmente com este tipo de tarefa. A principal classe de aplicaes para o Linux/RK so aquelas que lidam com audio e vdeo [RAJKUMAR 1998]. Essas aplicaes possuem basicamente tarefas peridicas, o que torna esta limitao um problema menor. 3.3 RED-Linux O propsito do RED-Linux (Real- Time and Embedded Linux), desenvolvido na Universidade da California em Irvine, suportar aplicaes embutidas atravs de um kernel eficiente e flexvel [WANG 1999]. Em termos de eficincia, ele implementa temporizao de alta resoluo e mecanismos para reduzir a latncia das interrupes. Em termos de flexibilidade, o projeto RED- Linux fornece suporte de escalonamento tempo real para o Linux, atravs da integrao de escalonadores baseados em prioridade, baseados em compartilhamento de recursos e baseados na construo de escalas. O objetivo suportar algoritmos de escalonamento dependentes da aplicao, os quais podem ser colecionados em uma biblioteca e reusados em outras aplicaes. RED-Linux implementa um mecanismo subjacente capaz de suportar os trs paradigmas de escalonamento tempo real mais populares. No escalonamento baseado em prioridades, cada tarefa recebe uma prioridade e a tarefa com prioridade mais alta sempre escolhida para execuo. No escalonamento baseado no compartilhamento, cada tarefa de tempo real possui uma fatia dos recursos (um nvel de utilizao), e todas as tarefas compartilham os recursos respeitando esta diviso pr-estabelecida. No escalonamento baseado em escalas de execuo, os instantes de tempo nos quais cada tarefa inicia, suspensa, retoma sua execuo e termina so previamente calculados e implementados atravs de uma escala de execuo construida pelo escalonador. Para suportar os trs paradigmas, cada ativao de cada tarefa possui como atributos uma prioridade, um tempo de incio, um tempo de fim e um oramento. Os tempos de incio e de fim definem juntos o intervalo de tempo potencial para execuo

da ativao. A prioridade especifica a ordem relativa para execuo das mesmas. O oramento especifica o tempo total de execuo permitido para cada ativao. Uma definio cuidadosa dessas quatro atributos para cada tarefa da aplicao permite a efetiva implementao de cada um dos trs paradigmas de escalonamento citados antes, e tambm solues resultantes da mistura de dois deles ou mesmo de todos os trs. O mecanismo implementado no RED-Linux dividido em dois componentes: o Alocador e o Disparador. O Disparador implementa o mecanismo de escalonamento bsico, respeitando os atributos de cada tarefa. O Alocador implementa a poltica que gerencia o tempo do processador e os recursos do sistema com o propsito de atender aos requisitos temporais das tarefas da aplicao, atravs da definio dos vrios atributos. A poltica de escalonamento (Alocador) pode ser modificada sem alterar os mecanismos de escalonamento de baixo nvel (Disparador). O Disparador implementado como um mdulo do kernel. Ele responsvel por escalonar tarefas de tempo real que foram registradas com o Alocador, isto , determinar a sua ordem de execuo. Tarefas convencionais so escalonadas pelo escalonador original do Linux quando nenhuma tarefa de tempo real estiver pronta para executar ou durante o tempo reservado para tarefas convencionais pela poltica em uso. O Alocador utilizado para definir os atributos de escalonamento de cada nova tarefa tempo real. Na maioria das aplicaes ele pode executar fora do kernel, como tarefa da aplicao ou um servidor auxiliar. Executando fora do kernel ele pode ser mais facilmente substituido pelo desenvolvedor da aplicao, se isto for necessrio. O REDLinux inclui uma API para que o Alocador possa interagir com o Disparador. Por exemplo, uma poltica de escalonamento adaptativa pode obter informaes do Disparador e com isto alterar os atributos em vigor. Tarefas de tempo real inicialmente registram-se com o Alocador que, por sua vez, informa os atributos delas para o Disparador. O Alocador executa como a tarefa tempo real de mais alta prioridade e faz o mapeamento da poltica de escalonamento como selecionada pela aplicao para o mecanismo disponvel no kernel do RED-Linux. 3.4 Real-Time Linux O RT-Linux [YODAIKEN 1997] uma extenso do Linux que se prope a suportar tarefas com restries temporais crticas. O seu desenvolvimento iniciou no "Department of Computer Science" do "New Mexico Institute of Technology". Atualmente o sistema mantido principalmente pela empresa FSMLabs. O RT-Linux um sistema operacional no qual um microkernel de tempo real coexiste com o kernel do Linux. O objetivo deste arranjo permitir que aplicaes utilizem os servios sofisticados e o bom comportamento no caso mdio do Linux tradicional, ao mesmo tempo que permite tarefas de tempo real operarem sobre um ambiente mais previsvel e com baixa latncia. O microkernel de tempo real executa o kernel convencional como sua tarefa de mais baixa prioridade (Tarefa Linux), usando o conceito de mquina virtual para tornar o kernel convencional e todas as suas aplicaes completamente interrompveis. Todas as interrupes so inicia lmente tratadas pelo microkernel de tempo real, e so passadas para a Tarefa Linux somente quando no existem tarefas de tempo real para executar. Para minimizar mudanas no kernel convencional, o hardware que controla interrupes emulado. Quando o kernel convencional "desabilita

interrupes", o software que emula o controlador de interrupes passa a enfileirar as interrupes que acontecerem e no forem completamente tratadas pelo microkernel de tempo real. Tarefas de tempo real no podem usar as chamadas de sistema convencionais nem acessar as estruturas de dados do kernel Linux que podem gerar bloqueios. Tarefas de tempo real e tarefas convencionais podem comunicar-se atravs de filas sem bloqueio e memria compartilhada. As filas, chamadas de RT-FIFO, so na verdade buffers utilizados para a troca de mensagens, projetadas de tal forma que tarefas de tempo real nunca so bloqueadas. Uma aplicao tempo real tpica consiste de tarefas de tempo real incorporadas ao sistema na forma de mdulos de kernel carregveis. Em termos de espao de endereamento, tanto o microkernel como as tarefas de tempo real habitam o espao de sistema do Linux. Aplicaes tambm incluem tarefas Linux convencionais, as quais so responsveis por funes tais como o registro de dados em arquivos, atualizao da tela, comunicao via rede e outras funes sem restries temporais. Um exemplo tpico so aplicaes de aquisio de dados. Observe que tanto as tarefas de tempo real como o prprio microkernel so carregadas como mdulo s adicionais ao kernel convencional. Os servios oferecidos pelo microkernel de tempo real so mnimos: tarefas com escalonamento baseado em prioridades fixas e alocao esttica de memria. A comunicao entre tarefas de tempo real utiliza memria compartilhada e a sincronizao pode ser feita via desabilitao das interrupes de hardware. Existem mdulos de kernel opcionais que implementam outros servios, tais como um escalonador EDF e implementao de semforos. O mecanismo de mdulos de kernel do Linux permite que novos servios sejam disponibilizados para as tarefas de tempo real. Entretanto, quanto mais complexos estes servios mais difcil ser prever o comportamento das tarefas de tempo real. Ao prover apenas servios mnimos, o microkernel do RT-Linux consegue excelente determinismo temporal, sendo capaz de suportar tarefas com perodos da ordem de dezenas de microsegundos em um microcomputador de mesa tpico. A descrio feita aqui refere-se a primeira verso do RT-Linux, a qual provia apenas o essencial para tarefas de tempo real. A segunda verso manteve o projeto bsico mas aumentou o conjunto de servios disponveis para tarefas de tempo real, ao mesmo tempo que procurou fornecer uma interface Posix tambm a nvel do microkernel. A incluso do Posix deve-se principalmente demanda de empresas que gostariam de portar aplicaes existentes para este sistema, e a disponibilidade de uma interface Posix no microkernel torna este trabalho mais fcil. O sistema RTAI outra variao do Linux para tempo real que utiliza uma abordagem similar a do RT-Linux. Informaes sobre o RTAI podem ser encontradas em http://www.rtai.org. 3.5 Monta Vista Linux O Linux kernel preemptability enhancement um projeto de cdigo aberto cuja proposta deixar o kernel do Linux completamente preemptvel [WEINBERG 2001]. O projeto patrocinado pela empresa Monta Vista Software, tendo sido incorporado ao kernel oficial do Linux a partir da verso v2.5.4.

O modelo de preempo usado permitir que o kernel seja preemptado a qualquer momento, com algumas rpidas excees. A preempo continua proibida quando um tratador de interrupo est executando, na realizao de processamento associado com tratadores de interrupo que foram postergados (bottom half), quando a thread atual mantm a posse de mecanismos de sincronizao do kernel tais como spinlock, writelock e readlock (nesses momentos o cdigo do kernel no reentrante) e, finalmente, quando o escalonador est executando. Nos demais momentos, e quando uma dessas condies deixa de ser verdadeira, o processo executando cdigo do kernel pode ser preemptado. A abordagem da Monta Vista concentra as alteraes do cdigo do kernel nos tratadores de interrupes, no funcionamento dos mecanismos de bloqueio usados dentro do kernel e na programao do escalonador (o algoritmo em si continua baseado em prioridades fixas). No longo prazo, MontaVista investiga se os pontos onde preempo proibida podem ser completamente eliminados, protegendo as sees crticas de curta durao com spinlocks que tambm desabilitam interrupes no processador local, e protegendo as sees crticas de longa durao com mutexes (aquelas maiores que dois chaveamentos de contexto). O overhead ser reduzido pois no ser mais necessrio testar por preempo no final de um trecho do cdigo onde a preempo estava proibida. A preempo ocorreria automaticamente como parte do servio de atendimento de interrupes que liberam um processo de maior prioridade.

4. Concluses
Na literatura de tempo real existe teoria suficiente para a construo de um sistema operacional capaz de atender com qualidade os requisitos temporais das aplicaes. Entretanto, para que isto seja possvel, so necessrias certas disciplinas de projeto, como descritas neste artigo. Embora seja difcil aplicar a teoria em sistemas operacionais antigos, construdos sem preocupaes de tempo real, possvel adaptar sistemas operacionais existentes para melhorar o seu comportamento. Este artigo discutiu vrios aspectos construtivos relevantes, ao mesmo tempo que descreveu vrias adaptaes existentes do Linux. razovel esperar que, em alguns anos, existiro verses do Linux com capacidade de suportar com preciso tarefas de tempo real, ao mesmo tempo que disponibilizam todos os servios usuais de um kernel completo.

Referncias
[ABENI 2002] L. Abeni, A. Goel, C. Krasic, J. Snow, J. Walpole. A Measurement-Based Analysis of the Real-Time Performance of Linux. Proc. of the Real-Time Technology and Applications Symposium, 2002. [ANGELOV 2002] C. K. Angelov, I. E. Ivanov, A. Burns. HARTEX - a safe realtime kernel for distributed computer control systems. Software - Practice and Experience 32(3): 209-232, 2002. [AUDSLEY 1993] N. C. Audsley, A. Burns, M. F. Richardson, K. Tindell, A. J. Wellings. Applying New Scheduling Theory to Static Priority Pre-emptive Scheduling. Software Engineering Journal, Vol. 8, No. 5, pp.284-292, 1993.

[AUDSLEY 2001] N. C. Audsley. On Priority Assignment in Fixed Priority Scheduling. Information Processing Letters, vol. 79, number 1, pages 39-44, 2001. [BOVET 2001] D. P. Bovet, M. Cesati. Understanding the Linux Kernel. 2nd edition, OReilly, 2001. [CARLSSON 2002] M. Carlsson, J. Engblom, A. Ermedahl, J. Lindblad, B. Lisper. Worst-Case Execution Time Analysis of Disable Interrupt Regions in a Commercial Real-Time Operating System. 2nd Work. on Real- Time Tools, Denmark, Aug. 2002. [CAYSSIALS 1999] R. Cayssials, J. Orozco, J. Santos, R. Santos. Rate Monotonic scheduling of real- time control systems with the minimum number of priority levels. The 11th Euromicro Conf. on Real-Time Systems (ECRTS99), York, June 1999. [EULER 1999] J. Euler, M. do C. Noronha, D. M. da Silva, Estudo de Caso: Desempenho do Sistema Operacional Linux para Aplicaes Multimdia em Tempo Real. Anais do II Workshop de Tempo Real, Salvador-BA, 25-28 de maio de 1999. [KATCHER 1993] D. Katcher, H. Arakawa, J. Strosnider. Engineering and Analysis of Fixed-Priority Schedulers. IEEE Trans. on Soft. Eng., Vol. 19, pp. 920-934, 1993. [MEHNERT 2002] F. Mehnert, M. Hohmuth, H. Hartig. Cost and benefit of separate address spaces in real-time operating systems. 23rd IEEE Real- Time Syst. Symp., Texas, Dec. 2002. [OIKAWA 1998] S. Oikawa, R. Rajkumar. Linux/RK: A portable resource kernel in Linux. IEEE Real- Time Systems Symposium, work- in-progress section, Madrid, December 1998. [OIKAWA 1999] S. Oikawa, R. Rajkumar. Portable RK: A portable resource kernel for guaranteed and enforced behavior. IEEE Real-Time Technology and Applications Symposium, Vancouver, June 1999. [OLIVEIRA 2003] R. de Oliveira. Aspectos Construtivos dos Sistemas Operacionais de Tempo Real. Workshop de Tempo Real, Natal- RN, maio 2003. Submetido. [RAJKUMAR 1998] R. Rajkumar, K. Juvva, A. Molano, S. Oikawa. Resource kernels: a resource-centric approach to real-time systems. Proc. of the SPIE/ACM Conference on Multimedia Computing and Networking, January 1998. [SRINIVASAN 1998]B. Srinivasan, S. Pather, R. Hill, F. Ansari, D. Niehaus. A Firm Real-Time System Implementation Using Commercial Off- The-Shelf Hardware and Free Software. Proc. of the Real- Time Technology and App. Symp., june 1998. [WANG 1999] Y.-C. Wang, K.-J. Lin. Implementing a General Real-Time Scheduling Framework in the RED-Linux Real- Time Kernel. Proc. of the Real-Time Systems Symposium, December 1999. [WEINBERG 2001] B. Weinberg, C. Lundholm. Embedded Linux Ready for RealTime. Third Real- Time Linux Workshop, Milano, Italy, Nov. 2001. [YODAIKEN 1997] V. Yodaiken, M. Barabanov. A Real-Time Linux. Proc. of the Linux App. Development and Deployment Conference (USELINUX), Anaheim, CA, Jan. 1997.