Examinamos a multitarefa, a propriedade do sistema operacional para executar vários programas quase independentes ao mesmo tempo. Antes de examinarmos de perto as tarefas, precisamos lidar com os termos.
Artigos anteriores da série:
Artigo 2. RTOS: estrutura e modo em tempo real
Artigo 1. RTOS: introdução.
Usamos a palavra "tarefa", embora não tenha um significado exato. Outros termos, "fluxo" e "processo", são mais especializados e você deve entender o que eles significam e como eles diferem.
Muitos RTOSs usados em aplicativos incorporados usam um modelo multithread. Vários threads podem ser executados simultaneamente, ocupando o mesmo espaço de endereço:
Isso significa que a alternância de contexto é, em primeiro lugar, alternar de um conjunto de registradores de processador para outro. É simples e rápido. O perigo potencial é que cada thread possa acessar a memória que pertence a outros threads ou ao próprio RTOS.
Uma alternativa é o modelo de múltiplos processos. Se vários processos estiverem em execução, cada processo terá seu próprio espaço de endereço e você não poderá acessar a memória associada a outros processos ou RTOS:
Isso torna a alternância de contexto mais difícil e demorada, pois o sistema operacional deve configurar adequadamente a unidade de gerenciamento de memória, o gerenciador de memória (English Memory Management Unit, MMU). Obviamente, essa arquitetura só é possível com um processador que suporta MMU. Os processos são suportados pelo RTOS de "alto desempenho" e pela maioria dos sistemas operacionais de desktop. Além disso, cada processo pode suportar a divisão em vários encadeamentos, mas essa propriedade raramente é usada em aplicativos incorporados comuns.
Se uma MMU estiver disponível, um compromisso poderá ser alcançado:
Muitos RTOSs de "streaming" oferecem suporte a MMUs para proteger a memória contra acesso não autorizado. Assim, enquanto a tarefa está em contexto, apenas uma parte do seu código / dados e as seções necessárias do RTOS são "visíveis"; os blocos de memória restantes estão desabilitados e uma tentativa de acesso causará uma emergência (para pessoas comuns) / exceção (para programadores). Isso torna a troca de contexto um pouco mais difícil, mas o aplicativo em si é mais seguro. Este modo pode ser chamado de "Modo protegido por thread" ou "Modo de processo leve".
Planejadores
Como sabemos, a ilusão da execução simultânea de tarefas é alcançada alocando tempo do processador para concluir cada uma das tarefas. Esta é a função principal do kernel. O método de distribuir o tempo entre as tarefas é chamado de "planejamento". Programador - software que determina para qual próxima tarefa transferir o controle. A lógica do planejador e o mecanismo que determina quando e o que deve ser executado é o algoritmo de planejamento. Nesta seção, examinamos vários algoritmos de planejamento. O planejamento de tarefas é um tópico extenso, e muitos livros são dedicados a ele. Forneceremos o mínimo necessário para entender o que um RTOS específico pode oferecer a esse respeito.
Executar para o Agendador de Conclusões (RTC)
O planejador RTC (execução até a conclusão) é muito simples e consome recursos mínimos. Este é um serviço ideal se atender aos requisitos do aplicativo. Abaixo está um gráfico para um sistema usando o agendador RTC:
O agendador alterna-se invocando as funções de nível superior de cada tarefa. A tarefa controla o processador (o interrompe) até que a função de nível superior execute o retorno da instrução de retorno. Se o RTOS suportar a suspensão de tarefas, qualquer tarefa atualmente suspensa não será executada. Este tópico é discutido no artigo abaixo, consulte "Pausando uma Tarefa".
Uma grande vantagem do agendador RTC, além da simplicidade, é uma única pilha e portabilidade do código (a montagem não é necessária). A desvantagem é que a tarefa pode "levar" o processador, sendo necessário um desenvolvimento cuidadoso do programa. Apesar de cada vez que a tarefa é executada desde o início (diferentemente de outros agendadores, que permitem iniciar o trabalho a partir do ponto de parada), você pode obter mais flexibilidade com a ajuda de variáveis estáticas do "estado", que determinam a lógica de cada chamada subseqüente.
Agendador Round Robin (RR)
O agendador RR ("carrossel") é semelhante ao RTC, mas mais flexível e, portanto, mais complexo:
No entanto, no caso do planejador RR, a tarefa não precisa executar a instrução de retorno na função de nível superior. Ela pode liberar o processador a qualquer momento, fazendo uma chamada RTOS. Essa chamada faz com que o kernel salve o contexto da tarefa atual (todos os registradores, incluindo o ponteiro da pilha e o ponteiro do comando) e carregue o contexto da próxima tarefa na fila. Em alguns RTOSs, o processador pode ser liberado (pausar a tarefa) antecipando a disponibilidade do recurso do kernel. Isso é mais complicado, mas o princípio é o mesmo.
A flexibilidade do planejador RR é determinada pela capacidade de continuar executando tarefas a partir do momento da suspensão, sem fazer alterações no código do aplicativo. Para flexibilidade, você deve pagar menos portabilidade do código e uma pilha separada para cada tarefa.
Agendador de fatias de tempo (TS)
Planejador TS (intervalo de tempo - "intervalo de tempo") para um nível mais complexo que o RR. O tempo é dividido em slots (intervalos, intervalos de tempo), onde cada tarefa pode ser executada dentro do intervalo designado:
Além da capacidade de liberar voluntariamente o processador, a tarefa pode ser interrompida por uma chamada ao agendador executada pelo manipulador de interrupção do timer do sistema. A idéia de atribuir um período de tempo fixo a cada tarefa é muito atraente (sempre que possível): é fácil de entender e é muito previsível.
A desvantagem do agendador TS é que a porcentagem de tempo de CPU alocada para cada tarefa pode diferir, dependendo de outras tarefas serem suspensas e outras partes dos slots serem livres:
O agendador TS pode se tornar mais previsível se tarefas em segundo plano forem implementadas. A tarefa em segundo plano pode ser executada em vez de qualquer tarefa suspensa e ocupar o intervalo de tempo em que a tarefa é liberada (ou faz uma pausa).
Obviamente, a tarefa em segundo plano não deve executar trabalhos críticos em termos de tempo, pois a parte do tempo do processador alocada é absolutamente imprevisível: nunca pode ser agendada.
Essa solução pressupõe que cada tarefa possa prever quando será planejada novamente. Por exemplo, se você tiver slots para 10 ms e 10 tarefas, a tarefa saberá que, se for liberada, continuará sendo executada após 100 ms. Com esta solução, você pode obter uma configuração mais flexível de ciclos de tempo (tempos) para tarefas do aplicativo.
O RTOS pode fornecer horários diferentes para cada tarefa. Isso oferece mais flexibilidade, mas também é previsível como com um tamanho de intervalo fixo. Outra opção é alocar mais de um intervalo para a mesma tarefa, se você precisar aumentar a proporção do tempo alocado do processador.
Programador prioritário
A maioria dos RTOS oferece suporte ao planejamento baseado em prioridades. A idéia é simples: a cada tarefa é dada prioridade e a qualquer momento a tarefa que tem a maior prioridade e está "pronta" para a execução é transferida para o processador:
O agendador inicia quando ocorre um evento (por exemplo, uma interrupção ou chamada para um serviço de kernel específico) que força uma tarefa com alta prioridade a ficar "pronta". Há três circunstâncias em que o planejador começa a funcionar:
• a tarefa está suspensa; o planejador deve agendar a próxima tarefa.
• Uma tarefa prepara uma tarefa de prioridade mais alta (usando uma chamada de API).
• Um manipulador de interrupção (Rotina de serviço de interrupção, ISR) prepara uma tarefa de maior prioridade. Pode ser um manipulador de interrupção para um dispositivo de E / S ou o resultado de um timer do sistema.
O número de níveis de prioridade varia (de 8 a várias centenas), os valores limite também variam: alguns RTOS percebem a prioridade mais alta como 0, enquanto em outros 0 indica a prioridade mais baixa.
Alguns RTOS permitem apenas uma tarefa em cada nível de prioridade; outros permitem alguns, o que complica bastante as estruturas de dados associadas. Muitos sistemas operacionais permitem alterar as prioridades das tarefas em tempo de execução, o que complica ainda mais os processos.
Agendador composto
Examinamos vários planejadores, no entanto, muitos RTOS comerciais oferecem soluções ainda mais sofisticadas que têm as características de vários algoritmos ao mesmo tempo. Por exemplo, um RTOS pode suportar várias tarefas em cada nível de prioridade e, em seguida, usar o TS para dividir o tempo entre várias tarefas prontas no nível mais alto.
Estados da tarefa
A qualquer momento, apenas uma tarefa é executada. Além do tempo do processador gasto no manipulador de interrupções (mais sobre isso no próximo artigo) ou no planejador, a tarefa "atual" é aquela cujo código está em execução no momento e cujos dados são caracterizados pelos valores atuais do registro. Pode haver outras tarefas "prontas" para o lançamento e elas serão levadas em consideração pelo agendador. Em um RTOS simples usando o agendador RTC, RR ou TS, isso é tudo. Porém, mais frequentemente, e sempre com um agendador de prioridade, as tarefas também podem estar em um estado suspenso, o que significa que elas não são levadas em conta pelo agendador até serem retomadas e entrarem em um estado de "prontidão".
Pausar uma tarefa
Pausar uma tarefa pode ser bastante simples: a tarefa pausa sozinha (chamando a API) ou outra tarefa a pausa. Por meio de outra chamada de API, uma tarefa suspensa pode ser retomada por outra tarefa ou manipulador de interrupções. Esta é uma suspensão "incondicional" ou "pura". Alguns sistemas operacionais chamam essa tarefa de "adormecida".
O RTOS pode fornecer à tarefa a capacidade de pausar (adormecer) por um determinado período de tempo, após o qual é retomada (de acordo com o relógio do sistema). Isso pode ser chamado de "adormecer".
Se o RTOS suportar chamadas de API de "bloqueio", uma suspensão mais sofisticada poderá ser usada. Essa chamada permite que a tarefa solicite um serviço ou recurso que receberá imediatamente se estiver disponível. Caso contrário, ele será suspenso até ficar disponível. Os tempos limites também podem ser definidos nos quais a tarefa será retomada se o recurso estiver indisponível por um determinado período de tempo.
Outros estados da tarefa
Muitos RTOS suportam outros estados, mas os conceitos e definições variam amplamente. Por exemplo, o estado está "concluído", o que significa simplesmente que a função externa da tarefa foi encerrada (retornando o código ou apenas completando o bloco de funções externas). Para que a tarefa concluída comece a ser executada novamente, provavelmente precisará ser redefinida de alguma forma.
Outra opção é o estado finalizado. É semelhante a uma suspensão completa (pura), exceto que a tarefa deve ser redefinida para reiniciar.
Se o RTOS oferecer suporte à criação e exclusão dinâmicas de tarefas (consulte o artigo a seguir), isso implica outro estado possível da tarefa - "excluída".
Quando trabalhamos em nosso próprio sistema operacional OSRV MAX em tempo real (artigos publicados anteriormente sobre ele), nossa equipe encontrou o blog de Colin Walls, especialista em microeletrônica e firmware da Mentor Graphics. Os artigos pareciam interessantes, os traduziam por si mesmos, mas, para não "escrever para a mesa", eles decidiram publicar. Espero que eles também sejam úteis para você. Nesse caso, planejamos publicar todos os artigos traduzidos da série.
Sobre o autor: Colin Walls trabalha na indústria eletrônica há mais de trinta anos, dedicando a maior parte de seu tempo ao firmware. Ele agora é engenheiro de firmware na Mentor Embedded (uma divisão da Mentor Graphics). Colin Walls frequentemente fala em conferências e seminários, autor de vários artigos técnicos e dois livros sobre firmware. Vive no Reino Unido. Blog profissional de Colin: blogs.mentor.com/colinwalls , e-mail: colin_walls@mentor.comO primeiro e o segundo artigos do ciclo são publicados
aqui.