Sistemas de Tempo Real

Prévia do material em texto

Sistemas de Tempo Real
Material Teórico
Responsável pelo Conteúdo:
Prof. Dr. Cléber Silva Ferreira da Luz
Revisão Textual:
Prof.ª Dr.ª Selma Aparecida Cesarin
Definição de Conceitos Básicos e da Importância de 
Sistemas Computacionais para aplicações Tempo Real
• Introdução;
• Sistemas de Tempo Real Crítico e Não Crítico;
• Classificação dos Sistemas de Tempo Real;
• Classificação de Eventos;
• Confiabilidade;
• Tolerância e Falhas;
• Conclusões e Resumo da Unidade.
 · Apresentar a definição, os conceitos e a classificação de Sistemas de 
Tempo Real;
 · Apresentar a importância de Sistemas Computacionais de Tempo Real.
OBJETIVO DE APRENDIZADO
Defi nição de Conceitos Básicos e da Importância De 
Sistemas Computacionais para aplicações Tempo Real
Orientações de estudo
Para que o conteúdo desta Disciplina seja bem 
aproveitado e haja maior aplicabilidade na sua 
formação acadêmica e atuação profissional, siga 
algumas recomendações básicas:
Assim:
Organize seus estudos de maneira que passem a fazer parte 
da sua rotina. Por exemplo, você poderá determinar um dia e 
horário fixos como seu “momento do estudo”;
Procure se alimentar e se hidratar quando for estudar; lembre-se de que uma 
alimentação saudável pode proporcionar melhor aproveitamento do estudo;
No material de cada Unidade, há leituras indicadas e, entre elas, artigos científicos, livros, vídeos 
e sites para aprofundar os conhecimentos adquiridos ao longo da Unidade. Além disso, você 
também encontrará sugestões de conteúdo extra no item Material Complementar, que ampliarão 
sua interpretação e auxiliarão no pleno entendimento dos temas abordados;
Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de discus-
são, pois irão auxiliar a verificar o quanto você absorveu de conhecimento, além de propiciar o 
contato com seus colegas e tutores, o que se apresenta como rico espaço de troca de ideias e 
de aprendizagem.
Organize seus estudos de maneira que passem a fazer parte 
Mantenha o foco! 
Evite se distrair com 
as redes sociais.
Mantenha o foco! 
Evite se distrair com 
as redes sociais.
Determine um 
horário fixo 
para estudar.
Aproveite as 
indicações 
de Material 
Complementar.
Procure se alimentar e se hidratar quando for estudar; lembre-se de que uma 
Não se esqueça 
de se alimentar 
e de se manter 
hidratado.
Aproveite as 
Conserve seu 
material e local de 
estudos sempre 
organizados.
Procure manter 
contato com seus 
colegas e tutores 
para trocar ideias! 
Isso amplia a 
aprendizagem.
Seja original! 
Nunca plagie 
trabalhos.
UNIDADE Definição de Conceitos Básicos e da Importância 
De Sistemas Computacionais para aplicações Tempo Real
Introdução
Vivemos numa era em que a informação é valiosa e, diariamente, milhares de 
informações estão disponíveis a cada segundo. 
A informação ajuda na tomada de decisões, que muitas vezes não precisam ser 
tomadas rápido e que podem possuir impactos imensuráveis. 
Na Sociedade da Informação, o termo tempo real se refere ao tempo em que 
uma decisão foi tomada, isto é, analisar a informação e, logo em seguida, tomar 
uma decisão. 
Dessa forma, pode-se dizer que a informação está associada à decisão e ao tem-
po. Todavia, há um paradigma na Sociedade da Informação, que envolve informa-
ção, decisão e tempo. 
As decisões precisam ser tomadas o mais rápido possível, isto é, quanto me-
nos tempo possível para tomar uma decisão, melhor. Todavia, como analisar uma 
quantidade imensa de informação e tomar uma decisão em pouco tempo? 
Esse paradigma está presente a todo o momento, na vida do ser humano.
Atualmente, a Tecnologia se tornou uma grande aliada da informação e possibilita 
armazenar, analisar e disponibilizar informações. 
Além disso, Sistemas Computacionais são responsáveis por realizar diversas 
atividades importantes na Sociedade. É possível dizer que vivemos numa Sociedade 
informatizada em que os Sistemas Computacionais são essenciais para realizar 
diversas atividades que, que muitas vezes, têm restrições temporais, isto é, as 
atividades devem ser realizadas num determinado intervalo de tempo. 
Existem Sistemas Computacionais que são responsáveis por realizar atividades 
temporais de extrema cautela, nas quais a ocorrência de uma falha pode resultar 
em danos irreversíveis.
Habitualmente, o tempo é um fator crítico nessa categoria de Sistemas Com-
putacionais. As tarefas realizadas pelo Sistema Computacional precisam ser rea-
lizadas num intervalo de tempo definido; caso as tarefas não ocorram dentro do 
intervalo de tempo determinado, resultará numa falha no Sistema.
Podem ocorrer falhas toleradas, ou irreversíveis. As falhas toleradas são 
falhas que, caso ocorram, os resultados são aceitáveis, isto é, os danos não são de 
extrema preocupação. Já as falhas irreversíveis são falhas que podem trazer danos 
irreversíveis, até mesmo fatais. 
Um Sistema Computacional se preocupa em realizar e concluir tarefas. Todavia, 
quando o Sistema Computacional se preocupa em concluir a tarefa e também, com 
o tempo da conclusão da tarefa, ele é classificado como Sistema de Tempo Real [2].
8
9
Em um Sistema de Tempo Real, o fator tempo é muito importante. O Sistema 
deve responder a determinadas requisições numa pequena fração de tempo.
Um Sistema de Tempo Real responde a requisições pré-determinadas, nas quais 
a velocidade da resposta tende a ser muita rápida. 
O tempo de resposta a uma requisição do Sistema é chamado de prazo, isto é, 
toda tarefa realizada pelo Sistema tem de ser cumprida num prazo de tempo. 
O termo “perda de prazo” corresponde a um não cumprimento de uma tarefa 
dentro de um intervalo de tempo determinado. 
A perda de um prazo corresponde a uma falha do Sistema [1]. Em outras palavras, 
um Sistema de Tempo Real é um Sistema que realiza diversas tarefas em prazos de 
tempo, e o não comprimento das tarefas num prazo é uma falha do Sistema.
Habitualmente, um Sistema de Tempo Real interage com o seu ambiente. O Sis-
tema responde a estímulos do ambiente externo, isto é, o ambiente ao seu redor re-
aliza um estímulo e o Sistema responde a esse estímulo em um determinado prazo. 
Um Sistema de Tempo Real é caracterizado como um Sistema previsível, isto é, 
um Sistema que conhece todas as ações que irão acontecer e é capaz de antecipar 
as suas ações. 
Para isso, o desenvolvimento de um Sistema de Tempo Real deve ser muito bem 
feito. No desenvolvimento do Sistema, deve-se especificar todas as ações que ele 
terá de tomar em situações adversas [3]. 
Num Sistema de Tempo Real, frequentemente, o processamento é especializado 
e curto. O Sistema obtém um estímulo e o responde logo em seguida, isto é, a 
tarefa correspondente ao estímulo deve ser executada no prazo definido. 
Em Sistemas com essas características, há forte tendência em executar as tarefas 
em paralelo, estabelecendo uma política de prioridade entre tais atividades. 
Nesse cenário, uma tarefa com prioridade maior pode interromper o processa-
mento de outra tarefa, com prioridade menor. Quando as tarefas são executadas 
em paralelo, é necessário implementar uma sincronização entre elas[4].
Algumas definições de Sistemas de Tempo Real podem ser encontradas na 
Literatura, como as propostas por Young (1982) e Randell (1995). 
Na definição proposta por Young (1982), um Sistema de Tempo Real é “Um 
Sistema que gera uma saída em um determinado tempo para uma entrada externa 
ao Sistema”. 
Outra definição é proposta por Randell (1995) e diz que “Um Sistema de 
Tempo Real é um Sistema que responde a um estímulo do seu ambiente em um 
determinado intervalo de tempo”. 
9
UNIDADE Definição de Conceitos Básicos e da Importância 
De Sistemas Computacionais para aplicações Tempo Real
Segundo Martins[6], um Sistema de Tempo Real é um Sistema que recebe dados, 
analisa e executa uma ação ou retorna um resultado rapidamente, e a sua ação 
afeta o funcionamento do ambiente naquele momento [6] .
A IEEE também tem uma definiçãode Sistemas de Tempo Reais. Segundo a 
IEEE, um Sistema de Tempo Real é aquele em que o resultado computacional 
pode ser usado para controlar, monitorar ou responder a um evento externo num 
determinado intervalo de tempo. 
Sugiram muitas outras definições de Sistemas de Tempo Real. Todavia, a definição 
feita por Laplante [7] está mais adequada para os Sistemas de tempo real da atualidade. 
Segundo Laplante, “Um Sistema de Tempo Real é aquele que deve satisfazer 
explicitamente restrições de tempo de resposta, podendo ter consequências de 
riscos ou falhas, não satisfazendo suas restrições”[7].
Muitas vezes, um Sistema de Tempo Real é projetado utilizando ferramentas 
convencionais de verificação e desenvolvimento. 
As Tecnologias e as Ferramentas utilizadas na projeção e no desenvolvimento de 
um Sistema de Tempo Real variam de acordo com o seu propósito. 
No desenvolvimento dessa classe de Sistema, é possível utilizar Linguagens de 
Programação de alto e baixo nível. Por exemplo, muitos Sistemas de Tempo Real 
são implementados em chips, na forma de Sistemas embarcados. 
Nesse cenário, são utilizadas Linguagens de baixo nível, tais como Assembly e 
C. Por outro lado, o desenvolvimento de um Sistema de Tempo de Real de previ-
são de tempo, por exemplo, é desenvolvido utilizando Linguagens de alto nível, tais 
como Java e C#, entre outras. 
Habitualmente, no desenvolvimento de um Sistema de Tempo Real, são utilizados 
diversos algoritmos determinísticos, isto é, algoritmos que fornecem sempre uma 
resposta certa e confiável. 
A utilização de algoritmos determinísticos se faz necessária pelo fator da “tomada 
de decisão”. A decisão que o Sistema deve tomar deve ser a mais adequada e certa 
possível e, também, no menor tempo possível. 
No desenvolvimento de Sistema de Tempo Real, as maiores preocupações 
consistem em fornecer a resposta certa no menor tempo possível. 
Vale ressaltar que o tempo é estritamente relacionado ao problema em questão. 
Por exemplo, um Sistema de controle aéreo deve fornecer uma resposta em frações 
de milésimos de segundos. Por outro lado, um Sistema de previsão de tempo, por 
exemplo, pode fornecer uma resposta em frações de segundos. 
Dessa forma, ao se escolher a Tecnologia de Desenvolvimento do Sistema, de-
ve-se observar a característica do problema. Por exemplo, a Linguagem C é mais 
rápida que a Linguagem Java. Dessa forma, para o Sistema de Controle Aéreo, 
por exemplo, a Linguagem C é mais indicada do que a Linguagem Java. 
10
11
Figura 1 – Implementação de um Sistema de Tempo Real em chips
Fonte: iStock/Getty Images
Habitualmente, um Sistema de Tempo Real realiza atividades repetidas com um 
intervalo de tempo definido. O aspecto mais importante num Sistema de Tempo 
Real é o fato de as atividades serem deterministas, isto é, as atividades devem 
sempre ter o mesmo resultado. 
Um Sistema Computacional é caracterizado como um Sistema de Tempo Real 
se a dimensão de erro de tempo no intervalo da realização de uma tarefa é pré-
definida, podendo ser sempre repetida. Esse aspecto mede o quanto o erro varia, 
isto é, tratando-se do jitter [7].
Um jitter é definido como uma variação do comportamento inesperado, relacio-
nado a algum período de tempo. Em um Sistema de Tempo Real, um jitter pode 
ser causado por vários motivos. Em um Sistema de Tempo Real,ele pode ser um 
comportamento inesperado do Sistema, durante a realização de uma atividade [7].
Um Sistema de Tempo Real é usado quando há necessidade de realizar tarefas 
na quais o tempo é uma questão importante. 
Alguns exemplos de Sistemas de Tempo Real são: Sistemas que controlam Ex-
perimentos Científicos; Sistemas de Processamento de Imagens Médicas; Sistemas 
de Controle Ferroviário, Sistemas de Controle de Fluxo de Carros; Sistemas de 
Controle Industrial e Sistema de Controle Marítimo, entre outros. 
Habitualmente, um Sistema de Tempo Real tem a característica de “controlar”, 
“monitorar”. 
Boa parte dos Sistemas de Tempo Real são projetados para monitorar determi-
nados eventos. 
É normal um Sistema de Tempo Real ter sensores que recebem estímulos do 
ambiente externo, analisam e, logo em seguida, realiza uma ação.
A Figura 2 ilustra esses procedimentos. 
11
UNIDADE Definição de Conceitos Básicos e da Importância 
De Sistemas Computacionais para aplicações Tempo Real
Sensores Sensores Sensores Sensores
AçãoAçãoAçãoAção
Sistema de tempo real
Figura 2 – Sistema Tempo Real
Sistemas de Tempo Real estão presentes em várias Áreas, em nosso dia a dia. 
A seguir, são apresentados alguns exemplos desse tipo de Sistemas.
Um Sistema de Controle Aéreo é um exemplo de Sistemas de tempo real. Ele 
monitora e gerencia todos os voos realizados no Aeroporto. Por sua vez, um Sis-
tema de Controle Ferroviário é responsável por monitorar todos os trens de uma 
Rede de Ferrovia e, também, é um exemplo de Sistema de Tempo Real. 
Figura 3 – Exemplo de Sistema de Tempo Real: Sistema de Controle Aéreo
Fonte: Wikimedia Commons
Outro exemplo de Sistema de Tempo Real que está presente em nosso coti-
diano é o Sistema de Controle Ferroviário. Tanto no cenário de controle aéreo, 
quanto no cenário de controle ferroviário, o Sistema deve fornecer uma resposta 
totalmente confiável. 
Caso o Sistema forneça uma resposta errada ou, ainda, o Sistema apresentar 
uma falha, pode impactar em resultados irreversíveis, ou até mesmo fatais, pois 
vidas estarão em jogo. 
12
13
Figura 4 – Exemplo de Sistema de Tempo Real: Sistema de Controle Ferroviário
Fonte: iStock/Getty Images
Sistemas de Tempo Real estão presentes até mesmo no campo de Inteligência. 
Por exemplo, um Sistema de Tempo Real pode ser implementado num robô que 
recebe determinados estímulos do seu ambiente externo e os responde com deter-
minadas ações.
Figura 5 – Exemplo de Sistema de Tempo Real: Sistema Computacional de um robô
Fonte: iStock/Getty Images
Outro exemplo de Sistema de Tempo Real é o Sistema de Controle de Frequ-
ência de Batimentos Cardíacos. Imagine que um paciente está internado na UTI e 
o caso clínico dele é grave. De repente, a frequência do batimento cardíaco do pa-
ciente começa cair. O Sistema de Controle de Frequência de Batimento Cardíaco 
deve gerar um alerta imediatamente. 
Figura 6 – Exemplo de Sistema de Tempo Real
Fonte: iStock/Getty Images
13
UNIDADE Definição de Conceitos Básicos e da Importância 
De Sistemas Computacionais para aplicações Tempo Real
O desenvolvimento de um Sistema de Tempo Real é multidisciplinar; envolve 
diversas áreas da Computação e da Engenharia. 
A Figura 7 ilustra a natureza interdisciplinar envolvida no desenvolvimento de 
um Sistema de Tempo Real.
Sistemas de
Tempo Real
Linguagens de 
Programação
Teoria de
Controle
Estruturas
de Dados
Arquitetura de
Computadores Algoritmos
Teoria de
Escalonamento
Sistemas
Operacionais
Engenharia
de Software
Figura 7 – Ilustração dos conceitos interdisciplinares envolvidos em Sistemas de tempo real
Sistemas de Tempo Real Crítico e Não Crítico
Os Sistemas de Tempo Real podem ser classificados a partir do ponto de vista 
de segurança (Safety). Considerando o ponto de vista de segurança, os Sistemas 
de Tempo Real podem ser classificados em: 
• Críticos;
• Não críticos.
Os Sistemas de Tempo Real Críticos também são chamados de Sistemas de 
Tempo Real Rígidos. Sistemas de Tempo Real com essa classificação devem obe-
decer ao intervalo de tempo para a realização da tarefa, isto é, não pode haver 
perda de prazo na realização de uma tarefa. 
O termo crítico é imprecado no sentido de que o Sistema não pode apresentar 
falhas, ou seja, todas as tarefas devem ser realizadas no prazo determinado. 
O não cumprimento dos prazos pode gerar resultados fatais. Por exemplo, o 
Sistema de freios de um trem não pode falhar; caso falhe, isso pode resultar num 
grave acidente. Podemos imaginar outros exemplos mais trágicos.
Imagine um avião prestes a realizar o seu pouso: o piloto aciona o Sistema de 
trem pouso, mas ele não abre atempo do pouso; isso pode resultar em milhares 
de mortes. 
14
15
Figura 8 – Exemplo de Sistema de Tempo Real crítico
Fonte: Wikimedia Commons
Um Sistema de Tempo Real crítico possui a característica de ser ultraconfiável. 
Caso ocorram falhas, o Sistema deve corrigi-las em frações de milissegundos, 
senão, pessoas podem se machucar.
Os Sistemas de tempo real críticos podem ser subdivididos em:
• Seguro caso de falha (fail safe);
• Operacional em caso de falha (fail operational).
Um Sistema é classificado como Seguro Caso de Falha se uma falha ocorrer 
e ele conseguir atingir um ou mais estados seguros. Por exemplo, considere uma 
linha ferroviária: caso aconteça uma falha no Sistema ferroviário, é possível fazer 
uma parada obrigatória. 
Um Sistema de Tempo Real pode ser classificado como Operacional em Caso 
de Falha se, na presença de falhas parciais, o Sistema puder se degradar fornecen-
do alguma forma de serviço mínimo. Por exemplo, considere o Sistema de controle 
aéreo: caso ocorra alguma falha, o Sistema consegue se degradar e fornece algum 
tipo de serviço mínimo. 
Figura 8 – Exemplo de Sistema de Tempo Real não crítico
Fonte: Wikimedia Commons
15
UNIDADE Definição de Conceitos Básicos e da Importância 
De Sistemas Computacionais para aplicações Tempo Real
Um Sistema de Tempo Real não crítico também é chamado de Sistema de 
Tempo Real Moderado. No Sistema de Tempo Real moderado, o tempo também 
é o fator mais importante; todavia, se ocorrerem falhas, elas são aceitáveis. Dessa 
forma, se o Sistema não cumprir a tarefa no prazo determinado, os danos não 
serão letais. Assim, é possível ter perda de prazo sem maiores resultados.
Habitualmente, o Sistema de Tempo Real moderado processa grande volume de 
dados, ao contrário do Sistema de Tempo Real crítico. 
Os Sistemas de tempo real críticos são inflexíveis; o prazo não pode ser ultrapassa-
do. Ao contrário, os Sistemas de tempo real não críticos oferecem alguma flexibilidade 
no não cumprimento de um prazo. Como exemplo de um Sistema de Tempo Real 
moderado, podemos mencionar um aparelho de leitor de DVD de um Computador. 
O Sistema recebe um estímulo do seu ambiente, isto é, recebe uma ação para 
abrir a bandeja e o usuário colocar o DVD, mas, o Sistema não responde ao even-
to no prazo de tempo adéqua; nesse caso, essa falha é aceitável, pois não houve 
danos irreversíveis.
Classificação dos Sistemas de Tempo Real
Os Sistemas de tempo real são classificados em: 
• Hard Real-Time;
• Soft Real-Time;
• Real Real-Time;
• Firm Real-Time.
A classificação Hard Real-Time significa que o Sistema deve respeitar todos os 
prazos de forma absoluta, isto é, a perda de prazo não é tolerada. O Sistema deve 
respeitar todos os prazos de forma rigorosa.
Soft Real-Time significa que se o Sistema perder algum prazo final, 
ocasionalmente, será tolerável. Nesse caso, é tolerado que o Sistema termine a 
atividade num prazo maior do que o definido. 
Os Sistemas classificados como Real Real-Time são Sistemas Hard Real-
Time, que possuem prazos de respostas extremamente curtos. 
Na classificação Firm Real-Time estão os Soft Real-Time que não possuem 
benefícios de entrega de serviço sem atraso. 
Na Literatura, há autores que ainda classificam os Sistemas de Tempo Real 
considerando suas implementações. Essas classificações correspondem a:
• Sistema de Resposta Garantida ( Guaranteed Response System);
• Sistema de melhor Esforço (Best Effort System). 
16
17
Um Sistema de Tempo Real é classificado como Sistema de “Resposta Garantida” 
quando, no Sistema, existem recursos suficientes para suportar a carga de trabalho 
e, também, todos os cenários de falhas são definidos. 
Já a classificação “Melhor Esforço” é aplicada a Sistemas que possuem estratégia 
de alocação dinâmica de recurso que se baseia em estudos probabilísticos sobre a 
carga de trabalho esperada. Nessa classificação, as falhas são aceitáveis. 
Atualmente, o desenvolvimento de um Sistema de Tempo Real considera o 
contexto em que irá atuar. Por exemplo, os Sistemas de tempo real não críticos são 
desenvolvidos utilizando o paradigma de “Melhor Esforço” e os Sistemas de tempo 
real críticos são desenvolvidos utilizando o paradigma de “Resposta Garantida”. 
Classifi cação de Eventos
Os eventos que o Sistema de Tempo Real pode responder são classificados como:
• Eventos periódicos;
• Eventos aperiódicos. 
Os eventos periódicos ocorrem num intervalo de tempo regular, isto é, num 
intervalo regular. O Sistema recebe estímulos do seu ambiente externo e os responde 
no prazo de tempo determinado. 
Os eventos aperiódicos ocorrem de maneira imprevisível, isto é, não há 
intervalo de tempo regular para os eventos ocorrerem. A ocorrência dos eventos é 
totalmente incerta. 
Um Sistema de Tempo Real pode responder a múltiplos fluxos de eventos 
periódicos. É possível calcular quantos eventos periódicos o Sistema pode atender 
num intervalo de tempo definido. 
Com esse cálculo, é possível dizer se o Sistema consegue manipular todos os 
eventos ou não. Por exemplo, se houver m eventos periódicos e o evento i ocorre 
com o período Pi e requer Ci segundos para responder o evento, então, o Sistema 
só pode gerenciar todos os eventos se:
Se o Sistema satisfizer esse critério, ele é classificado como um Sistema de 
Tempo Real agendável.
Para melhorar o entendimento, vamos utilizar um exemplo. Considere um 
Sistema de Tempo Real Soft Real-Time com três eventos periódicos, com períodos 
de 100, 200 e 500ms, respectivamente. 
17
UNIDADE Definição de Conceitos Básicos e da Importância 
De Sistemas Computacionais para aplicações Tempo Real
Se esses eventos exigirem 50, 30 e 100ms de tempo para serem processados, 
respectivamente, o Sistema será agendável porque 0,5 + 0,15 + 0,2 < 1. 
Se um quarto evento com um período de 1ms for adicionado, o Sistema per-
manecerá agendável, contanto que esse evento não precise de mais de 150ms de 
tempo de processamento por ocorrência.
Confiabilidade
Um Sistema de Tempo Real é caracterizado como um Sistema totalmente 
confiável. O termo confiabilidade caracteriza um Sistema de tempo real. 
Suas respostas devem ser totalmente corretas e o Sistema nunca deve apresen-
tar falhas. Se ocorrerem falhas, o Sistema deve então, identificá-las e as corrigir. 
Como mencionado na Seção 1.1, no desenvolvimento de um Sistema de Tem-
po Real, normalmente, são utilizados algoritmos determinísticos: algoritmos que 
sempre fornecem as respostas corretas, para que a confiança no Sistema seja alta. 
Na fase de projeção do Sistema, deve-se realizar o mapeamento de todas as 
falhas possíveis e realizar um plano de contingência caso elas ocorram. 
Habitualmente, um Sistema de Tempo Real é um Sistema de alta disponibili-
dade. Se uma falha for tão grave a ponto derrubar o Sistema, deve-se pensar em 
utilizar um plano de Redundância. 
Redundância é a forma mais confiável e simples de manter um Sistema com alta 
disponibilidade. Por exemplo, continuando com o Sistema de Controle Aéreo, é 
comum que esse Sistema seja executado em dois computadores diferentes: o com-
putador A e o computador B. Caso ocorra uma falha no computador A, o controle 
aéreo é automática e rapidamente transferido para o Sistema que está sendo exe-
cutado no computador B.
Existem duas formas de redundância: a temporal e a espacial. A redundância 
temporal é quando a falha ocorre e logo em seguida é tomada uma ação corretiva. 
Por exemplo, caso a falha ocorra, a atividade é repetida.
Esse tipo de redundância é menos aplicada em Sistemas de tempo real críticos, 
porque a repetição da ação irá violar a restrição do tempo, ou seja, haverá perda 
de prazo. 
Já na redundância espacial, uma mesma ação crítica é executada por vários re-
cursos replicados, isto é, caso a falha ocorra, a ação é continuada logo em seguida 
por outros recursos. Nesse cenário, a falha pode ser mascarada, pois outro recurso 
continuará a ação de onde ela parou. 
Nesse sentido, a probabilidade de perdade prazo é pequena, porque o outro 
recurso irá continuar a tarefa no ponto em que o recurso anterior parou.
18
19
Geralmente, a redundância espacial é utilizada em Sistemas de tempo real críti-
cos. Essa redundância permite não gerar atrasos no tempo de resposta, isto é, não 
há perda de prazo ao se implementar a redundância espacial. 
Tolerância e Falhas
Um Sistema de Tempo Real deve ser totalmente tolerante a falhas. Como men-
cionado na seção anterior, o Sistema deve ser totalmente confiável e, também, na 
fase de projeção, deve-se mapear todas as falhas possíveis, isto é, criar um Modelo 
de Falhas. 
Com o modelo de falhas pronto, o próximo passo é determinar uma ação de 
contingência para cada falha, caso elas ocorram. É importante ressaltar que na 
ação tomada, caso ocorra uma falha, deve-se respeitar o prazo de resposta da ação 
original, isto é, caso ocorra uma falha, o prazo não pode ser pedido. 
O modelo de falhas deve ser elaborado cuidadosamente. Uma falha pode ocor-
rer por diversos motivos, tais como, falha no hardware, falha no software, falha 
humana, falha do próprio Sistema por processar algum dado errado, enfim, são 
diversas razões para ocorrer uma falha. Todavia, independentemente da origem da 
falha, deve-se elaborar uma ação para todas as falhas possíveis. 
Para realizar um bom modelo de falhas, é necessário definir todas as hipóteses 
de tipo de falhas possíveis que podem acontecer durante a execução do Sistema. 
A construção do modelo de falha é essencial para que os mecanismos de tole-
rância às falhas possam ser testados e validados. Quando o mapeamento for rea-
lizado, devem ser implementado de forma mais precisa possível, para permitir a 
implementação dos mecanismos de tolerância às falhas, isto é, o mapeamento das 
falhas deve ser feito o mais claro possível para permitir um mecanismo de tolerân-
cia à falha mais seguro e confiável. 
Na teoria, as falhas não mapeadas não devem ocorrer. Todavia, caso ocorram, 
serão eventos raros.
Conclusões e Resumo da Unidade
Sistemas de Tempo Real são Sistemas voltados para aplicações nas quais a 
confiabilidade é de extrema importância. O Sistema deve fornecer uma saída total-
mente correta, e não deve falhar. 
As tarefas devem ser realizadas num determinado período de tempo, que é cha-
mado de prazo. O não cumprimento de um prazo, isto é, se o Sistema não realizar 
19
UNIDADE Definição de Conceitos Básicos e da Importância 
De Sistemas Computacionais para aplicações Tempo Real
a tarefa num determinado prazo, é gerada uma falha. O termo “perda de prazo” se 
refere a uma tarefa que não foi realizada no período de tempo estipulado. 
Um Sistema de Tempo Real é caracterizado por ser previsível, um Sistema que 
conhece todas as ações que irão acontecer, e é capaz de antecipar as suas ações. 
Habitualmente, um Sistema de Tempo Real recebe um estímulo do seu ambiente 
externo, analisa e gera uma saída, isto é, uma ação. 
Um Sistema de Tempo Real pode ser classificado como crítico e não crítico. 
Um Sistema de Tempo Real crítico é caracterizado por não haver perda de pra-
zo. Caso haja perda de prazo, pode resultar em danos irreversíveis e fatais. 
Já num Sistema de Tempo Real não crítico, a perda de tempo é tolerada, isto é, 
caso alguma ação não seja tomada durante um intervalo de tempo, as consequên-
cias não serão tão severas. 
Também é possível classificar os Sistemas de Tempo Real considerando o tempo 
de resposta de uma atividade. 
Um Sistema de Tempo Real pode ser classificado como Hard Real-Time, Soft 
Real-Time, Real Real-Time e Firm Real-Fime.
A classificação Hard Real-Time diz que o Sistema deve respeitar todos os prazos 
de forma absoluta, isto é, a perda de prazo não é tolerada. 
A classificação Soft Real-Time significa que a perda de algum prazo final, 
ocasionalmente, é tolerável. 
Os Sistemas classificados como Real Real-Time são Sistemas Hard Real-Time, 
que possuem prazos de respostas extremamente curtos.
Na classificação Firm Real-Time estão os Soft Real-Time, que não possuem 
benefícios de entrega de serviço sem atraso. 
Um Sistema de Tempo Real pode, ainda, ser classificado considerando suas 
implementações. 
Um Sistema de Tempo Real pode ser classificado como Sistema de Respos-
ta Garantida (Guaranteed Response System) e Sistema de Melhor Esforço (Best 
Effort System). 
Um Sistema de Tempo Real se encaixa na classificação “Resposta Garantida” 
quando no Sistema existem recursos suficientes para suportar a carga de trabalho 
e, também, todos os cenários de falhas são definidos. 
Já a classificação “Melhor Esforço” é aplicada aos Sistemas que possuem uma 
estratégia de alocação dinâmica de recurso que se baseia em estudos probabilísticos 
sobre a carga de trabalho esperada. Nessa classificação, as falhas são aceitáveis.
Um Sistema de Tempo Real sempre responde a um evento do seu ambiente. 
Um evento pode ser classificado como periódico ou aperiódico. 
20
21
Um evento periódico ocorre um intervalo de tempo regular e um evento ape-
riódico ocorre de maneira inesperada, isto é, não há intervalo de tempo definido 
para o evento ocorrer.
Um Sistema de Tempo Real deve possuir grande confiabilidade, isto é, o 
Sistema deve ser totalmente confiável; todas as atividades realizadas por ele devem 
ocorrer de forma rigorosa. 
O Sistema deve conter vários mecanismos de tolerância às falhas. Um mecanis-
mo simples e eficaz de tolerância às falhas é a redundância. 
Existem duas formas de redundância, a temporal e a espacial. A redundância 
temporal é quando a falha ocorre e logo em seguida é tomada uma ação corretiva. 
Por exemplo, a repetição da ação. 
Já na redundância espacial, uma mesma ação crítica é executada por vários 
recursos replicados, isto é, caso a falha ocorra, a ação é continuada logo em seguida 
por outros recursos.
Nesse cenário, a falha pode ser mascarada, pois outro recurso continuará a 
ação de onde ela havia parado. Nesse sentido, a probabilidade de perda de prazo 
é muito pequena, porque o outro recurso irá continuar a tarefa no ponto em que 
o recurso anterior parou.
Na fase de projeção de um Sistema de Tempo Real, deve-se mapear todas as 
falhas possíveis, ou seja, realizar um Modelo de Falhas. Com o modelo de falhas 
pronto, o próximo passo é determinar uma ação de contingência para cada falha, 
caso elas ocorram. 
É importante ressaltar que, na ação tomada, caso ocorra uma falha, deve-se 
respeitar o prazo de resposta da ação original, isto é, caso ocorra uma falha, o 
prazo não pode ser pedido. 
Na sociedade, eventos que necessitam de uma resposta rápida ocorrem a todos 
os momentos e em todas as áreas. Há casos em que, se esses eventos não obti-
verem uma resposta rápida e eficaz, danos irreversíveis e fatais podem ocorrer, e 
também há casos em que o não recebimento de uma resposta não é tão crucial. 
Todavia, esses eventos sempre devem ser respondidos num intervalo de tempo 
determinado. Sistemas Computacionais se mostraram grandes aliados no monitora-
mento e no controle desses eventos. Em nosso dia a dia, isto é facilmente percebido. 
Sistemas Computacionais de Tempo Real estão presentes no Campo Aéreo, 
Ferroviário, Industrial, Alimentício, Bancário e Hospitalar, entre outros. 
É possível dizer que muitos eventos críticos ou não críticos não poderiam ser 
controlados sem o auxílio de Sistemas Computacionais.
Em suma, Sistemas Computacionais são de extrema importância para controlar 
eventos de Tempo Real. 
21
UNIDADE Definição de Conceitos Básicos e da Importância 
De Sistemas Computacionais para aplicações Tempo Real
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
 Sites
Sistemas de Tempo Real – Parte 1
https://goo.gl/K29zuC/
 Vídeos
Sistema em Tempo Real - SO
https://youtu.be/gaO9o-ZfMiU
Sistemas de tempo real
https://youtu.be/HTLZUCkdQbA
 
 Leitura
Sistemas de Tempo Real
https://goo.gl/ZCsfnn
22
23
Referências
[1] ALMEIDA, M. B. de. Implementando Sistemas operacionais de tempo realem microcontroladores. Local: Amazon, ano. (eBook Kindle). 
[2] SHAW, A. C. Sistemas e Software de Tempo Real. Local: Bookman, 2003. 
[3] CAURIN, G. A. P. Análise de Sistemas operacionais de tempo real para 
aplicações de robótica e automação. 2008. 154p. (Dissertação de mestrado) 
– Departamento de Engenharia da Escola de Engenharia /Universidade de São 
Paulo, São Paulo, 2008.
[4] Farines, J. M., Fraga, J. S. e Oliveira, R. S. - Sistemas de Tempo Real. 
Departamento de Automação e Sistemas. Universidade Federal de Santa 
Catarina, Florianópolis, julho de 2000. 
[5] TANENBAUM, A. S. Sistemas Operacionais Modernos. 2.ed. São Paulo: 
Pearson Prentice Hall, 2003.
[6] MARTIN, T. Design of Real Time Systems. New Jersey: Prentice-Hall Inc., 2013.
[7] CEDE NO, W.; LAPLANTE, P. A. An overview of real-time operating systems, 
Journal of the Association for Laboratoty Automation, Local, n.12, p. 40-
45, 2007.
23
Sistemas de 
Tempo Real
Material Teórico
Responsável pelo Conteúdo:
Prof. Dr. Cléber Silva Ferreira da Luz
Revisão Textual:
Prof.ª Dr.ª Selma Aparecida Cesarin
Apresentação das Principais Metodologias 
e Tecnologias de Desenvolvimento
• Introdução;
• Requisitos e Especificação de 
Sistemas de Tempo Real;
• Linguagens de Programação;
• Arquitetura de Sistema de Tempo Real;
• Falhas de Softwares – Prevenção, 
Detecção e Recuperação;
• Conclusões e Resumo da Unidade.
 · Apresentar Metodologias e Tecnologias de desenvolvimento;
 · Fornecer todos os detalhes sobre o desenvolvimento de Sistemas de 
Tempo Real.
OBJETIVO DE APRENDIZADO
Apresentação das Principais 
Metodologias e Tecnologias 
de Desenvolvimento
Orientações de estudo
Para que o conteúdo desta Disciplina seja bem 
aproveitado e haja maior aplicabilidade na sua 
formação acadêmica e atuação profissional, siga 
algumas recomendações básicas: 
Assim:
Organize seus estudos de maneira que passem a fazer parte 
da sua rotina. Por exemplo, você poderá determinar um dia e 
horário fixos como seu “momento do estudo”;
Procure se alimentar e se hidratar quando for estudar; lembre-se de que uma 
alimentação saudável pode proporcionar melhor aproveitamento do estudo;
No material de cada Unidade, há leituras indicadas e, entre elas, artigos científicos, livros, vídeos 
e sites para aprofundar os conhecimentos adquiridos ao longo da Unidade. Além disso, você 
também encontrará sugestões de conteúdo extra no item Material Complementar, que ampliarão 
sua interpretação e auxiliarão no pleno entendimento dos temas abordados;
Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de discus-
são, pois irão auxiliar a verificar o quanto você absorveu de conhecimento, além de propiciar o 
contato com seus colegas e tutores, o que se apresenta como rico espaço de troca de ideias e 
de aprendizagem.
Organize seus estudos de maneira que passem a fazer parte 
Mantenha o foco! 
Evite se distrair com 
as redes sociais.
Mantenha o foco! 
Evite se distrair com 
as redes sociais.
Determine um 
horário fixo 
para estudar.
Aproveite as 
indicações 
de Material 
Complementar.
Procure se alimentar e se hidratar quando for estudar; lembre-se de que uma 
Não se esqueça 
de se alimentar 
e de se manter 
hidratado.
Aproveite as 
Conserve seu 
material e local de 
estudos sempre 
organizados.
Procure manter 
contato com seus 
colegas e tutores 
para trocar ideias! 
Isso amplia a 
aprendizagem.
Seja original! 
Nunca plagie 
trabalhos.
UNIDADE Apresentação das Principais Metodologias 
e Tecnologias de Desenvolvimento
Introdução
Nesta aula, iremos estudar aspectos sobre o desenvolvimento de Sistemas 
de Tempo, bem com as Linguagens de Programação mais utilizadas no Desen-
volvimento, as Técnicas de Desenvolvimento, os Requisitos mais importantes 
no Desenvolvimento.
O desenvolvimento de um Sistema de Tempo Real é semelhante ao desenvol-
vimento de um Sistema Convencional. Todavia, no desenvolvimento de Sistemas 
para aplicações de Tempo Real, alguns aspectos a mais devem ser considerados, 
tais como o tempo e a tolerância às falhas. 
No desenvolvimento do Sistema deve-se dar o máximo de atenção a esses 
dois aspectos. 
O principal foco desta aula é mostrar os principais aspectos de desenvolvimento 
em Sistemas de Tempo Real. 
Iremos estudar as principais linguagens de programação utilizadas em aplica-
ções de Tempo Real, alguns métodos para controlar e manipular falhas e os prin-
cipais requisitos e as especificações que um Sistema de Tempo Real deve possuir. 
Iremos começar nosso estudo pelos Sistemas Embarcados. Muitos Sistemas de 
Tempo Real são implementados na forma de Sistemas Embarcados, que podem ser 
vistos como Sistemas Computacionais implementados em dispositivos específicos 
(hardwares), que realizam tarefas pré-definidas e repetidas vezes. Habitualmente, 
são desenvolvidos para uma atividade específica. (ALMEIDA, M.B.) 
Por exemplo, considere um aparelho cuja única função é controlar a tempera-
tura de um ambiente. Esse aparelho possui um Sistema de Tempo Real que realiza 
o controle da temperatura e deve manter o ambiente numa temperatura de 25°C. 
O aparelho possui sensores que capturam a temperatura do ambiente e enviam 
para o sistema de controle de temperatura, que processa a informação capturada 
pelos sensores. 
Após o processamento, o Sistema deve realizar uma ação, Nesse cenário, caso 
necessário, o sistema de controle poderia aumentar ou diminuir a temperatura do 
ambiente, sempre com o objetivo de manter o ambiente com a temperatura de 25°C.
Esse cenário caracteriza bem um Sistema de Tempo Real: o Sistema recebe 
eventos do ambiente externo, processa tais eventos e realiza uma ação, modi-
ficando o ambiente externo. 
Outro aspecto interessante nesse exemplo é que o sistema de controle de tem-
peratura é implantado em um chip, caracterizando um Sistema de Tempo Real 
na forma de Sistema Embarcados.
8
9
Figura 1 – Exemplo de Sistema de Tempo Real na forma de Sistemas Embarcados
Fonte: iStock/Getty Images
Outro exemplo de Sistemas de Tempo em forma de Sistema Embarcado 
pode ser facilmente abstraído considerando um Sistema de Controle Automo-
tivo. Habitualmente, um Sistema de Controle Automotivo é implementado em 
chips que são responsáveis por controlar todo o Sistema do carro. 
Figura 2 – Exemplo de Sistema de Tempo Real na forma de Sistemas Embarcados (Controle Automotivo)
Fonte: iStock/Getty Images
O desenvolvimento de um Sistema de Tempo Real, seja ele na forma de Sis-
tema Embutido ou não, segue o mesmo paradigma de desenvolvimento de um 
Sistema Convencional. 
Todavia, o desenvolvimento deve considerar aspectos relacionados a um even-
to de Tempo Real, tais como tempo de processamento, prazo e tolerância a fa-
lhas, entre outros. 
A próxima seção apresenta alguns requisitos e especificações necessárias, que 
devem ser contemplados no desenvolvimento de um Sistema de Tempo Real. 
9
UNIDADE Apresentação das Principais Metodologias 
e Tecnologias de Desenvolvimento
Requisitos e Especificação de 
Sistemas de Tempo Real
O desenvolvimento de um Sistema de Tempo Real requer métodos de análise 
de requisitos semelhantes ao desenvolvimento de um Sistema Comum.
Todavia, no desenvolvimento de um Sistema de Tempo Real, a análise de al-
guns requisitos e a especificação do Projeto deve ser realizada rigorosamente, a 
fim de evitar fracassos no desenvolvimento do Sistema.
Na maioria dos fracassos no desenvolvimento de Sistemas de Tempo Real, as 
especificações são inconsistentes, ambíguas, incompletas ou não descrevem corre-
tamente as ações que o Sistema deve tomar. Muitos erros de especificações levam 
a falhas que poderiam ser descobertas por meio de uma especificação, análise e 
simulações. (CAURIN, 2008)
Os principais requisitos de um Sistema de Tempo Real são:
• Funcionais;
• Temporais;
• Dependabilidade.
Os requisitos Funcionais descrevem as funcionalidades que o Sistema deve 
realizar. Na especificação dos requisitos funcionais deve-sedefinir quem são as 
entidades de Tempo Real, isto é, definir quais são os eventos de Tempo Real que 
o Sistema deve controlar. 
Cada entidade de Tempo Real possui uma validade temporal limitada devido à 
dinâmica física do Processo, isto é, cada entidade de Tempo Real deve ocorrer num 
intervalo de tempo definido e a definição desse intervalo de tempo é definida pela di-
nâmica em que ela ocorre.
O conjunto das entidades de Tempo Real define a base de dados de Tempo Real. 
Essa base deve ser atualizada sempre que houver mudança de valor numa entidade. 
Um Sistema de Tempo Real é usado para controlar ou monitorar eventos. 
Normalmente, os Requisitos Temporais são relacionados à dinâmica do pro-
cesso físico que o Sistema pretende controlar, isto é, os requisitos temporais 
são relacionados à frequência e à dinâmica com que os eventos ocorrem. Esses 
requisitos devem realizar restrições quanto a:
• Atrasos na detecção dos eventos;
• Atrasos no processamento; 
• Atrasos na resposta dos eventos.
Requisitos de Dependabilidade são usados para definir a confiabilidade do Sistema. 
Sistemas de Tempo Real devem ser altamente confiáveis. Nessa análise de 
requisitos, deve-se ressaltar aspectos de disponibilidade e de mantenabilida-
de. Mantenabilidade é a propriedade que define se um Sistema possui condi-
ções de executar as suas tarefas.
10
11
Linguagens de Programação
Aplicações de Tempo Real requerem Linguagens de Programação com as mes-
mas características que as Linguagens de propósitos gerais possuem.
Todavia, essas aplicações necessitam de algumas características adicionais que, 
em muitos casos, não são encontradas nas Linguagens de propósitos gerais. 
Algumas dessas características são:
• Acesso e controle de tempo;
• Controle de concorrência;
• Tratamento de exceções.
Com o intuito de abstrair tais características, nos últimos anos, muitas Lingua-
gens de Programação sofreram modificações, justamente para abstrair caracterís-
ticas relacionadas a aspectos de eventos de Tempo Real. Por exemplo, a Lingua-
gem Java possui uma extensão para aplicações de Tempo Real. Também foram 
criadas diversas linguagens para aplicações de Tempo Real, as Linguagens Real-
-Time Euclid, Esterel e CSP são exemplos de Linguagens criadas especialmente 
para aplicações de Tempo Real.
Aspectos como tempo, concorrência, tolerância às falhas e funcionalidades 
bem definidas são aspectos inerentes a uma aplicação de Tempo Real.
Dessa forma, é importante que as Linguagens de Programação utilizadas em apli-
cações de Tempo Real forneçam mecanismos capazes de controlar tais aspectos.
Em relação ao aspecto de tempo, uma Linguagem de Programação para apli-
cação de Tempo Real deve fornecer Mecanismos ou Primitivas capazes de con-
trolar e monitorar o tempo em que as tarefas ocorrem. 
Essas Primitivas devem ser capazes de lidar tanto com tempos absolutos como 
tempos relativos e, geralmente, são implementadas como um servidor de relógio. 
Algumas dessas Primitivas são:
• set() – Para ajustar o tempo de uma tarefa um relógio ou timer;
• read() – Para ler o tempo de uma tarefa;
• delay() – Para retardar um tempo de uma tarefa;
• sleep() – Para colocar uma tarefa para dormir.
Vale lembrar que, em uma aplicação de Tempo Real, o tempo é um aspecto de 
extrema importância. Dessa forma, é de suma importância que as Linguagens de Pro-
gramação forneçam primitivas ou mecanismos para controlar e monitorar o tempo.
Todas as Linguagens de Programação para aplicação de Tempo Real devem 
fornecer mecanismos capazes de controlar eventos concorrentes. Devem ser 
fornecidos recursos para sincronização, escalonamento e execução de tarefas 
em paralelo e a comunicação entre elas. 
11
UNIDADE Apresentação das Principais Metodologias 
e Tecnologias de Desenvolvimento
Dessa forma, as Linguagens de Programação devem ser altamente paralelas, ca-
pazes de processar várias tarefas em paralelo. Um Sistema de Tempo Real deve 
realizar as tarefas o mais rápido possível, ou melhor, no prazo determinado. Assim, 
o paralelismo é o elemento chave no processamento de tarefas. Com ele, é possível 
aumentar o desempenho no processamento.
Um Sistema de Tempo Real é caracterizado por ser altamente confiável. O Sistema 
deve ser totalmente tolerante a falhas, caso elas ocorram. Tanto as falhas de hardwares 
como as de softwares devem ser tratadas elegantemente, caso ocorram. 
Dessa maneira, é importante que as Linguagens de Programação forneçam 
mecanismos capazes de controlar e manipular as falhas.
Na fase de projeção do Sistema, todas as falhas devem ser mapeadas e con-
tornadas. Em tese, se as falhas foram mapeadas, elas não devem ocorrer, certo? 
Se ocorrerem, podem ser consideradas casos caros. Todavia, deve-se usar uma 
linguagem capaz de detectar e manipular falhas.
Esterel
Esterel é uma linguagem orientada para evento. Seu uso é bastante significante 
na programação “reativa” de uma aplicação, isto é, ela é muito usada para intera-
gir, aceitar, monitorar e controlar sinais e eventos do ambiente externo. 
Esterel é baseada em Modelo de Computação com grande similaridade com 
grafos de estados. Uma Linguagem para Programação baseada em estados re-
cebe um estímulo do ambiente externo e reage logo em seguida, isto é, de um 
estado passa para outro estado. 
A Esterel foi projetada para ser usada em conjunto com uma Linguagem hos-
pedeira com propósito geral, que seja responsável pela manipulação dos dados e 
dos aspectos computacionais mais convencionais de uma aplicação.
Enquanto a Esterel cuida de monitorar e controlar os eventos, outra Lingua-
gem de propósito geral cuida de processar os dados, por exemplo. 
Para entender um Programa Esterel funcional é fácil imaginar uma máquina 
de estado. O Sistema de Tempo Real está num estado atual, até que um ou mais 
eventos ocorrem. 
Esses eventos fazem com que o Sistema sofra uma “reação” e com isso entre 
em outro estado. A reação deve gerar uma ação ou ações (saída). Essa saída cor-
responde à aceitação do evento de entrada. 
Se o Sistema aceitou o evento de entrada, deve respondê-lo logo em seguida 
com uma ação. É importante ressaltar que a aceitação do evento de entrada gera 
uma ação (uma saída); todavia, enquanto o Sistema está processando essa saída, 
outros eventos de entrada podem influenciar a ação do primeiro evento.
Dessa forma, o Sistema encontra-se num estado atual ao receber o evento 
de entrada, sofre uma mudança e passa para outro estado; ao receber novos 
eventos de entradas, o Sistema passa para novos estados. Uma ação termina 
num ponto definido ou quando não se tem mais ações para serem executadas.
12
13
O objetivo de um Sistema de Tempo Real é responder aos eventos eternos do 
ambiente, certo? 
Dessa maneira, habitualmente, um Sistema de Tempo Real possui sensores 
para capturar os eventos do ambiente.
A Linguagem Esterel funciona como uma interface entre o ambiente e o Sis-
tema, fornecendo várias funções para monitorar e capturar os eventos externos.
Java com Extensão a Tempo Real
Atualmente, Java é a Linguagem Orientada a Objeto mais usada no mundo 
inteiro. É uma linguagem bem completa e com vários recursos voltados para o 
desenvolvimento de Sistemas. 
Fortemente influenciada pela Linguagem C++ e seu conceitos de orienta-
ção a objeto, Java se tornou muito usual no desenvolvimento de Sistemas nos 
últimos anos, consequência de seus excelentes recursos de desenvolvimento e, 
também, por sua capacidade de fácil portabilidade.
Programação concorrente é fortemente presente em aplicações de Tempo Real 
e Java permite programação concorrente por meio da criação de vários Threads. 
Geralmente, um programa possui uma única linha de execução; na progra-
mação concorrente, é possível criar vários Threads, isto é, é possível criar várias 
linhas de execuções paralelas e concorrentes. 
Desse modo, uma tarefa pode ser dividida entre duas Threads; com isso, o 
tempo de execução da tarefa é menor, porque a execução será dividida entre 
as duasThreads. 
A programação concorrente em Java é extremamente sólida e eficaz. Assim, a 
Linguagem Java acaba sendo uma Linguagem muito atrativa para aplicações de 
Tempo Real.
Programa
Thread 1 Thread 2 Thread 3 Thread 4 Thread 5
Figura 3 – Programação concorrente
13
UNIDADE Apresentação das Principais Metodologias 
e Tecnologias de Desenvolvimento
O foco desta seção é apresentar algumas funções do Java para a Programação 
Concorrente: funções que são constantemente utilizadas no desenvolvimento de 
aplicações de Tempo Real.
Java é fundamentalmente orientado a objetos e, com isso, o modelo emprega-
do na Programação Concorrente é orientado a objetos.
Nesse modelo, existe a classe Threads. Para criar Threads, uma classe prin-
cipal deve estender a classe Thread (utilizando a palavra reservada extends) e 
programar um método run para o novo objeto. O método run contém o código 
executável do Thread.
Uma instância de um Thread é ativada chamando o método star. Essa chamada 
invoca o método run do Thread. Por exemplo, a chamada:
Produtor.start();
tornaria o Thread Produtor habilitado para execução.
O código de Produtor, seu método run poderia fazer alguma computação 
e, então, inserir dados m em um buffer por meio de uma chamada ao método 
Deposita de um objeto Buffer. Por exemplo, com:
Buffer.Depista(m);
O objeto Buffer poderia ser uma instância de uma classe geral de buffers limi-
tados. Por exemplo, BB, e declarados com o código:
BB Buffer = new BB();
Na classe Threads, há muitos outros métodos para gerenciar threads, entre 
os quais está o método join(), que faz um invocador esperar até que um thread 
termine antes de continuar sua execução. 
Considere a thread Processa_Dados, a qual deve esperar até que a 
thread Obtém_Dados termine antes que ela possa continuar. Para realizá-lo, 
Processa_Dados chamaria:
Obtem_Dados.join();
A rotina join também pode receber por parâmetro o tempo máximo que ela 
deve esperar. 
Outros métodos interessantes que Java disponibiliza são:
• Wait;
• Notify;
• NotifyAll;
• Synchronized.
O método wait() bloqueia sempre a thread chamadora e libera o controle, isto 
é, a thread que chama o método fica em modo de espera e libera o controle para 
as outras threads.
Já o método notify() despertará a thread chamadora, ou seja, desbloqueará uma 
thread que estava esperando (thread que ficou bloqueado com o método wait).
O método notifyAll() desbloqueia todas as threads que estavam bloqueadas.
Já o método synchronized é utilizado para criar e sincronizar as threads.
14
15
Real-Time Euclid
A linguagem Real-Time Euclid é uma linguagem de pesquisa projetada para 
previsibilidade; ela também, possui grande facilidade na integração e na interação 
de componentes de sistemas.
O seu objetivo é garantir que os programas tenham suas restrições temporais 
satisfeitas. Real-Time Euclid é uma extensão de Tempo Real da Linguagem de 
Programação paralela Concurrent Euclid.
A Linguagem Real-Time Euclid permite programação concorrente. Nessa 
Linguagem, os processos, semelhante ao Java, são encarados como objetivos 
ativos concorrentes.
Tais objetos podem ser sincronizados, como também os recursos podem ser 
compartilhados. Essa linguagem disponibiliza o método wait semelhante ao 
Java, e também o método signal sobre variáveis de condições.
Um wait sobre uma variável de condição faz o processo invocador e bloqueia-
-se na variável. Um signal sobre uma variável de condição despertará um pro-
cesso bloqueado; se não existem processos sobre a variável de condição, uma 
operação signal é ignorada. (CAURIN, 2008)
Os processos em Real-Time Euclid podem também se comunicar fora de moni-
tores por meio de Primitivas wait e signal similares e de um brodcast.
Determinismo temporal é obtido por restrições sobre a Linguagem e por adição 
da informação temporal a algumas estruturas-chave. Processos e Estruturas de Dados 
são definidos estaticamente e não podem ser criados ou modificados dinamicamente.
Um wait numa variável de condição tem um tempo de espera associado. Por 
exemplo, a chamada wait:
WaitvcnoLongerThan 15 : vc_expirada
faz o invocador bloquear-se na variável de condição vc.
O comando também indica que a exceção vc_expirada é sinalizada se o 
processo invocador (e em espera) não for despertado dentro de 15 unidades 
de tempo.
Assumindo que esse é o único processo esperando em vc, o despertador ocor-
re se e quando outro processo emite uma operação de signal sobre vc.
signal vc.
Nessa linguagem, laços são limitados especificando um número máximo de 
iterações, usando uma expressão de limite, exp1 ... exp2, em que as duas ex-
pressões exp1 ... exp2 são avaliadas para inteiros em tempo de compilações 
|exp1 ... exp2| + 1 é o limite superior do contador de iteração. 
15
UNIDADE Apresentação das Principais Metodologias 
e Tecnologias de Desenvolvimento
Por exemplo, o código:
For i : 15 .. n
lista_comandos
end for
faria iteração sobre a lista_comandos não mais do que (n-15)+1 vezes, onde n 
é conhecido em tempo de compilação (saídas anteriores ao término do laço podem 
ser feitas com um comando exit).
Os processos podem ser periódicos ou esporádicos. Um quadro de tempo asso-
ciado a cada processo define seu período e prazo-limite (processo periódico) ou seu 
tempo de separação mínimo e prazo limite (processo esporádico). 
Pré e pós condições que devem ser satisfeitas em cada ativação podem ser es-
pecificadas. Exceções são identificadas e tratadas por meio de três métodos: 
1. Um comando kill faz o processo em questão terminar após ter indicado 
uma exceção;
2. Um comando de activate determina o quadro corrente do processo;
3. Um comando except salva o estado de processo, chama um tratador de 
exceção e retorna a execução do processo em execução.
Programas Real-Time Euclid são analisados para escalonabilidade por meio 
de um processo complexo e exaustivo que simula, essencialmente, todos os pos-
síveis caminhos e disputas por recursos. 
Iniciando no nível de instrução de máquina, limites de tempo para segmentos 
não iterativos de programas compilados são estimados.
Indeterminismos de hardware, tais como aqueles causados por operações de ca-
che e DMA, são ignorados e assumidos como não tendo efeito sobre os resultados. 
Atrasos e disputas são delimitados numa segunda fase. O mecanismo de esca-
lonamento subjacente é o prazo-limite mais cedo primeiro (EDF), o enfileiramento 
de chaveamentos de monitores e de varáveis de condição é realizado pela regra 
primeiro que entra, primeiro que sai (FIFO).
Arquitetura de Sistema de Tempo Real 
Uma descrição arquitetônica de um Sistema especifica a estrutura e o estilo dos 
elementos que compreende. 
Arquiteturas de softwares para Sistema de Tempo Real abrangem, também, 
os tipos possíveis de componentes de software, como esses componentes podem 
ser organizados, como eles interagem entre si e as abstrações e modelos subja-
centes. (CAURIN, 2008)
16
17
Um Sistema de Tempo é visto como um mundo fechado contendo dois 
componentes:
• Um ambiente; 
• Um Sistema Computacional.
Que interagem por meio de mensagens, sinais ou eventos, através de sua 
interface. Em outra visão, um Sistema de Tempo Real pode estar num conjunto 
de estados. 
Geralmente, cada estado denota um conjunto particular de valores de variá-
veis ou um conjunto de relações entre variáveis que representam o ambiente e 
o computador. 
O Sistema muda de estado devido a eventos que alteram os valores das variáveis 
de um estado. Essa mudança de estado é chamada de transição de estado. Os even-
tos causadores de transição podem ser eventos de interface, que são transmitidos do 
ambiente para o Sistema Computacional.
O modelo mais comum para Sistemas de Tempo Real é o adaptado de um mo-
delo usado em Sistemas Operacionais e Programação Concorrente.
O Sistema que implementa estados e transições é composto por um conjunto 
de processos interativos; processos interagem enviando mensagem entre si, com-
partilhando hardware, softwaree recursos. 
O Processo é o objeto ativo de um Sistema e é a unidade lógica de trabalho 
escalonada pelo Sistema Operacional.
Ele tem um “estado”, normalmente representado por um Descritor de Dados 
ou Bloco de Controle de Processos. O descritor armazena informações, como os 
valores das variáveis do processo, seu contador de instruções e os recursos que 
foram alocados para ele.
Processos Periódicos e Esporádicos
Sistemas de Tempo Real, geralmente, contêm dois tipos de processos :
• Periódicos;
• Esporádicos.
Processos periódicos são ativados de forma regular entre intervalos fixos de 
tempo. Em geral, são usados para monitoramento sistemático ou amostragem de 
informação a partir de sensores, por um intervalo longo de tempo. 
Processos esporádicos são dirigidos por eventos. Eles são ativados por um 
sinal externo ou uma mudança de alguma relação. Um processo esporádico 
pode ser usado para reagir a um evento indicando uma falha de alguma peça 
de equipamento.
17
UNIDADE Apresentação das Principais Metodologias 
e Tecnologias de Desenvolvimento
Falhas de Softwares – Prevenção, 
Detecção e Recuperação
Um Sistema de Tempo Real deve ser totalmente tolerante a falhas. Na fase de 
projeção de um Sistema de Tempo Real, todas as falhas devem ser mapeadas, para 
que, na fase de desenvolvimento, todas elas sejam controladas. Os maiores proble-
mas encontrados em um sistema tolerante a falhas são prevenção, isto é, evitar 
falhas; detecção, avaliação de falhas, recuperação e correção de falhas. 
Para um sistema ser tolerante a falhas, a melhor solução é a prevenção. Esse as-
pecto deve ser muito bem pensando na fase de projeção. 
Na fase de análise de requisitos, as especificações do Sistema e os próprios re-
quisitos devem ser bem elaborados. Boa parte das falhas possíveis, ou quase todas 
as falhas de um Sistema, são descobertas na fase de requisitos e especificações. 
Todavia, dada uma especificação correta, ainda é possível ocorrerem falhas por 
causa de erros de implementações. 
Erros de Programação podem ser encontrados e controlados por meio de fer-
ramentas convencionais de depuração de Programa. Porém, mesmo se usar todas 
as técnicas e ferramentas possíveis para encontrar os erros, um Sistema não esta-
ria livre da ocorrência de falhas. 
Algoritmos podem ser implementados incorretamente; todos os possíveis erros 
que podem ocorrer num Sistema podem não ser conhecidos ainda, e o comporta-
mento do ambiente com o software pode ocorrer de formas incorretas.
É importante termos em mente que erros de softwares e erros de hardwares 
são coisas diferentes e ocorrem por motivos diferentes.
Habitualmente, erros de hardwares são mais fáceis de encontrar e manipular. 
Já erros de softwares são mais difíceis de serem descobertos.
Todavia, tanto erros de softwares como erros de hardwares podem ocorrer em 
tempo de execução. Formalmente, uma falha de execução ocorre quando alguma 
asserção ao Sistema é violada, isto é, alguma regra do Sistema é violada. Portan-
to, a Detecção de erros envolve a avaliação de algumas condições Booleanas em 
tempo ou local apropriado. 
Caso ocorra uma falha, o prejuízo causado pode ser determinado a partir dos 
valores das variáveis de estados no momento da detecção.
Infelizmente, uma falha é frequentemente detectada algum tempo após ela ter 
inicialmente ocorrido e após ela ter produzido dano adicional que, geralmente, 
mascara a causa original.
Em aplicações de Tempo Real, Recuperação e Correção de erros coloca o Sis-
tema em um estado consistente. Corrigir e isolar o erro, se possível, de tal maneira 
que a falha não torne a ocorrer imediatamente e não ocorra novamente. 
18
19
Nesses aspectos, dois métodos são importantes para recuperar as falhas.
São eles:
• Recuperação de falhas por avanço (forwad);
• Recuperação por retrocesso (backward).
O método por retrocesso é semelhante ao adotado na maioria dos Sistemas Ope-
racionais. Nesse método, os estados do Sistema são armazenados ou “checados” 
em determinados pontos em intervalos freqüentes; ocorrendo um erro, o estado é 
“trazido de volta”, ao ponto de checagem mais recente e a computação é repetida. 
Esse método é interessante e atraente, mas nem sempre é possível usá-lo numa 
aplicação de Tempo Real. 
O estado pode ser irrecuperável, especialmente se uma operação afetou o 
ambiente físico. Por exemplo, considere um robô que executa alguma operação 
de manufatura; corta um plano para a confecção de uma roupa. Se o corte foi 
realizado errado, não há como voltar atrás. 
Situações semelhantes a essa ocorrem frequentemente em aplicações de Tem-
po Real. Dessa forma, esse método pode ser inviável para aplicações de Tempo 
Real, sem contar que, muitas vezes, o ato de voltar o Sistema para um estado 
anterior pode levar muito tempo e o fator tempo é um aspecto de grande impor-
tância em aplicações de Tempo Real.
No método de recuperação avançada, um futuro estado consistente é deter-
minado, o Sistema é forçado ou colocado nesse estado e a execução é retomada 
desse ponto. Considerando o exemplo do robô, se ele realizou um corte errado, 
um novo corte pode ser realizado na mesma peça, dando um novo visual para a 
peça de roupa. Tipicamente, o tempo de recuperação por avanço é mais previsível 
e mais rápido do que o tempo para voltar a um estado anterior consistente.
Em ambos os métodos de recuperação, alguma intervenção não computado-
rizada pode ser necessária para isolar, reparar ou determinar a causa da falha, 
ou para recuperar o Sistema. Por exemplo, considere um Sistema de Controle 
de Tráfego Aéreo ou um Sistema de Controle de vôo a bordo. Num determinado 
momento, o Sistema de Controle poderia trocar o modo automático para o ma-
nual, quando certas falhas são detectadas.
Diversos métodos para o problema de tolerância a falhas de software foram 
desenvolvidos ao longo dos anos. Um conjunto de técnicas emprega as ideias 
de processamento de transições desenvolvidas para Sistemas para aplicações 
de Tempo Real.
Esse conjunto envolve controle de concorrência, atomicidade, capacidade 
de serialização e consistência. Um exemplo é o paradigma do objeto sensível 
ao tempo, que define uma visão centrada em dados de Sistemas de Tempo Real 
como uma alternativa à visão comum baseada em processamento de tarefa.
19
UNIDADE Apresentação das Principais Metodologias 
e Tecnologias de Desenvolvimento
O método da computação imprecisa também foi proposto para evitar e tra-
tar falhas temporais. Nesse método, uma tarefa pode ser decomposta em duas 
partes: uma parte obrigatória e uma parte opcional, que pode ser saltada se não 
houver tempo suficiente para completá-la.
Em outra variação da técnica da computação imprecisa, uma tarefa pode ter 
versões diferentes, cada uma executando com diferentes durações de tempo e pro-
duzindo resultados com precisões diferentes.
A versão selecionada para execução depende do tempo disponível. Essa última 
alternativa é um exemplo de projeto diversificado.
Conclusões e Resumo da Unidade
O desenvolvimento de um Sistema de Tempo Real segue os mesmos para-
digmas de desenvolvimento de um Sistema Convencional. Todavia, o desenvol-
vimento deve considerar aspectos relacionados ao evento de Tempo Real, tais 
como tempo de processamento, prazo e tolerância a falhas, entre outros.
No desenvolvimento de Sistemas de Tempo Real, os requisitos e as especifica-
ções devem ser realizados com bastante criticidade. 
Os requisitos e as especificações devem considerar aspectos para manipular 
eventos de Tempo Real, tais como tempo, prazo e tolerância a falhas.
Os principais requisitos de um Sistema de Tempo Real são:
• Funcionais;
• Temporais;
• Dependabilidade.
Os requisitos funcionais descrevem as funcionalidades que o Sistema deve rea-
lizar. Um Sistema de Tempo Real é usado para controlar ou monitorar eventos. 
Normalmente, os Requisitos Temporais são relacionados à dinâmica do pro-
cesso físico que o Sistema pretende controlar, isto é, os requisitos temporaissão 
relacionados à frequência e à dinâmica com que os eventos ocorrem. Requisitos de 
Dependabilidade são usados para definir a confiabilidade do Sistema.
Aplicações de Tempo Real requerem Linguagens de Programação com as mes-
mas características que as Linguagens de Propósitos Gerais possuem
Todavia, essas aplicações necessitam de algumas características adicionais que, 
em muitos casos, não são encontradas nas Linguagens de Propósitos Gerais. 
Algumas dessas características são:
• Acesso e controle de tempo;
• Controle de concorrência;
• Tratamento de exceções e previsibilidade.
20
21
Existem diversas linguagens para aplicações de Tempo Real, entre as quais se 
encontram, Esterel, Java e Real-Time Euclid. 
Esterel é uma linguagem orientada a evento. Seu uso é bastante significante na 
programação “reativa” de uma aplicação, isto é, ela é muito usada para interagir, 
aceitar, monitorar e controlar sinais e eventos do ambiente externo.
Esterel é baseada em modelo de computação com grande similaridade com 
grafos de estados. Uma linguagem para programação baseada em estados. 
Recebe um estímulo do ambiente externo e reage logo em seguida, ou seja, 
de um estado, passa para outro estado. 
Atualmente, Java é a linguagem orientada a objeto mais usada no mundo inteiro.
Java é uma linguagem bem completa e com vários recursos voltados para o 
desenvolvimento de sistemas. Fortemente influenciada pela Linguagem C++ e 
seu conceitos de orientação a objeto, Java se tornou muito usual no desenvolvi-
mento de Sistemas nos últimos anos e permite a Programação Concorrente. 
A Programação Concorrente em Java é extremamente sólida e eficaz. Dessa 
forma, a Linguagem Java acaba sendo uma Linguagem muito atrativa para apli-
cações de Tempo Real.
A Linguagem Real-Time Euclid é uma Linguagem de Pesquisa projetada para 
previsibilidade, ela também tem grande facilidade na integração e na interação de 
componentes de Sistemas. 
Seu objetivo é garantir que os programas tenham suas restrições temporais 
satisfeitas. Real-Time Euclid é uma extensão de Tempo Real da Linguagem de 
Programação paralela Concurrent Euclid.
Sistemas de Tempo Real geralmente contêm dois tipos de processos:
• Periódicos;
• Esporádicos.
Processos periódicos são ativados de forma regular entre intervalos fixos de 
tempo. Em geral, são usados para monitoramento sistemático ou amostragem 
de informação a partir de sensores, por um intervalo longo de tempo.
Processos esporádicos são dirigidos por eventos; eles são ativados por um sinal 
externo ou uma mudança de alguma relação.
Um Sistema de Tempo Real deve ser totalmente tolerante a falhas. Na fase de 
projeção de um Sistema de Tempo Real, todas as falhas devem ser mapeadas, para 
que na fase de desenvolvimento todas elas sejam controladas. 
Os maiores problemas encontrados num Sistema tolerante a falhas são preven-
ção, isto é, evitar falhas, detecção, avaliação de falhas, recuperação e correção 
de falhas. 
21
UNIDADE Apresentação das Principais Metodologias 
e Tecnologias de Desenvolvimento
Para um Sistema ser tolerante a falhas, a melhor solução é a prevenção. 
Esse aspecto deve ser muito bem pensando na fase de projeção. 
Em aplicações de Tempo Real, recuperação e correção de erros colocam o Sis-
tema num estado consistente. Deve-se corrigir e isolar o erro, se possível, de tal 
maneira que a falha não torne a ocorrer imediatamente e não ocorra novamente. 
Nesses aspectos, dois métodos são importantes para recuperar as falhas.
São eles:
• Recuperação de falhas por avanço (forwad);
• Recuperação por retrocesso (backward).
O método por retrocesso é semelhante ao adotado na maioria dos Sistemas 
Operacionais. Nesse método, os estados do Sistema são armazenados ou “checa-
dos” em determinados pontos em intervalos freqüentes.
Ocorrendo um erro, o estado é “trazido de volta” ao ponto de checagem mais 
recente e a computação é repetida. 
No método de recuperação avançada, um futuro estado consistente é deter-
minado, o Sistema é forçado ou colocado nesse estado e a execução é retomada 
desse ponto.
22
23
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
 Sites
Sergio Prado
Sistemas de Tempo Real – Parte 1.
https://goo.gl/K29zuC
 Vídeos
Sistema em Tempo Real - SO
https://youtu.be/gaO9o-ZfMiU
Sistemas de Tempo Real
https://youtu.be/HTLZUCkdQbA
 Leitura
Sistemas de Tempo Real
https://goo.gl/4bcgvB
23
UNIDADE Apresentação das Principais Metodologias 
e Tecnologias de Desenvolvimento
Referências
ALMEIDA, M. B. de. Implementando sistemas operacionais de Tempo Real 
em microcontroladores. Amazon, 2013. (eBook)
CAURIN, G. A. P. Análise de sistemas operacionais de Tempo Real para 
aplicações de robótica e automação. 2008. 154 p. (Dissertação de Mestra-
do) Departamento de Engenharia da Escola de Engenharia /Universidade de 
São Paulo, São Paulo, 2008.
CEDENO, W.; LAPLANTE, P. A. Na overview of real-time operating systems, 
Journal of the Association for Laboratoty Automation, USA, n. 12, p. 40-
45, 2007.
FARINES, J. M., FRAGA, J. S. e OLIVEIRA, R. S. Sistemas de Tempo Real. 
Departamento de Automação e Sistemas. Universidade Federal de Santa Cata-
rina, Florianópolis, julho de 2000. 
MARTIN, T. Design of Real Time Systems. NJ: Prentice-Hall Inc., 2013.
SHAW, A. C., Sistemas e Software de Tempo Real. Porto Alegre: Bookman, 2003.
TANENBAUM, A. S. Sistemas Operacionais Modernos. 2. ed. São Paulo, Pearson 
Prentice Hall, 2003.
24
Sistemas de Tempo Real
Material Teórico
Responsável pelo Conteúdo:
Prof. Dr. Cléber Silva Ferreira da Luz
Revisão Textual:
Prof.ª Dr.ª Selma Aparecida Cesarin
Programação de Sistemas Operacionais para Aplicações em Tempo Real
• Introdução;
• Sistemas Operacionai;
• Sistemas Operacionais de Tempo Real;
• Funções e Serviços de um so de Tempo Real;
• Exemplos de Sistemas Operacionais de Tempo Real;
• Conclusões e Resumo da Unidade.
 · Apresentar todos os conceitos presentes no desenvolvimento de um 
Sistema Operacional para Aplicações de Tempo Real.
OBJETIVO DE APRENDIZADO
Programação de Sistemas Operacionais 
para Aplicações em Tempo Real
Orientações de estudo
Para que o conteúdo desta Disciplina seja bem 
aproveitado e haja maior aplicabilidade na sua 
formação acadêmica e atuação profissional, siga 
algumas recomendações básicas: 
Assim:
Organize seus estudos de maneira que passem a fazer parte 
da sua rotina. Por exemplo, você poderá determinar um dia e 
horário fixos como seu “momento do estudo”;
Procure se alimentar e se hidratar quando for estudar; lembre-se de que uma 
alimentação saudável pode proporcionar melhor aproveitamento do estudo;
No material de cada Unidade, há leituras indicadas e, entre elas, artigos científicos, livros, vídeos 
e sites para aprofundar os conhecimentos adquiridos ao longo da Unidade. Além disso, você 
também encontrará sugestões de conteúdo extra no item Material Complementar, que ampliarão 
sua interpretação e auxiliarão no pleno entendimento dos temas abordados;
Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de discus-
são, pois irão auxiliar a verificar o quanto você absorveu de conhecimento, além de propiciar o 
contato com seus colegas e tutores, o que se apresenta como rico espaço de troca de ideias e 
de aprendizagem.
Organize seus estudos de maneira que passem a fazer parte 
Mantenha o foco! 
Evite se distrair com 
as redes sociais.
Mantenha o foco! 
Evite se distrair com 
as redes sociais.
Determine um 
horário fixo 
para estudar.
Aproveite as 
indicações 
de Material 
Complementar.
Procure se alimentar e se hidratar quando for estudar; lembre-se de que uma 
Não se esqueça 
de se alimentar 
e de se manter 
hidratado.
Aproveite as 
Conserve seu 
material e local de 
estudos sempre 
organizados.
Procure manter 
contato com seus 
colegas e tutores 
para trocar ideias! 
Isso amplia a 
aprendizagem.
Seja original! 
Nunca plagie 
trabalhos.
UNIDADE Programaçãode Sistemas Operacionais para Aplicações em Tempo Real
Introdução
Sistemas Operacionais de Tempo Real são Sistemas Operacionais voltados para 
aplicações de Tempo Real. Assim como num Sistema de Tempo Real, um Sistema 
Operacional de Tempo Real responde a eventos pré-definidos em um intervalo de 
tempo conhecido e bem definido. 
Em Sistemas Operacionais de Tempo Real, o tempo de resposta a um evento é 
o aspecto mais importante. Todos os eventos devem ser respondidos respeitando 
os prazos de tempo. 
Um Sistema Operacional de Tempo Real também possui a característica de ser 
totalmente confiável, mesmo na ocorrência de uma falha; o Sistema Operacional 
de Tempo Real deve responder o evento no intervalo de tempo determinado. 
O primeiro passo no estudo de Sistemas Operacionais para aplicações de Tempo 
Real é entender o que é um Sistema operacional. Após termos bem claro o que é um 
Sistema Operacional, conseguiremos compreender facilmente todos os conceitos e 
elementos por trás de um Sistema Operacional para aplicações de Tempo Real.
Em um Sistema Computacional, um Sistema Operacional (SO) é o Programa 
mais importante do Sistema. Ele atua como um intermediário entre o usuário e o 
hardware de um computador. 
O objetivo do Sistema Operacional fornece um ambiente para que o usuário 
possa executar seus Programas. Dessa forma, podemos dizer que o objetivo central 
do SO é facilitar o uso de Sistemas Computacionais. 
Um objetivo secundário do SO é usar os hardwares do Sistema Computa-
cional de forma eficiente. A próxima seção apresenta mais detalhes sobre um 
Sistema Operacional.
Sistemas Operacionais
Um Sistema Operacional (SO) pode ser considerado um Programa que visa a 
realizar uma intermediação entre um usuário e o hardware de um computador. 
Seu objetivo é fornecer um ambiente no qual os usuários possam executar seus 
Programas de maneira eficiente. Numa definição clássica de Sistemas Operacio-
nais, um SO pode ser considerado um gerenciador, que atua gerenciando os diver-
sos recursos computacionais, tais como, softwares, hardwares, dados e dados de 
entrada e saída, entre outros.
Por mais complexo que possa parecer, um Sistema Operacional é um conjunto 
de rotinas executado pelo processador, da mesma forma que nossos Programas. 
Sua principal função é controlar o funcionamento do computador, como um geren-
te dos vários recursos disponíveis do Sistema. 
8
9
O nome Sistema Operacional não é único para designar esse Conjunto de Pro-
gramas. Nomes como monitor, executivo, supervisor ou controlador possuem, nor-
malmente, o mesmo significado.
Funções que um Sistema operacional deve desempenhar:
• Permitir que os Programas armazenem e obtenham informação;
• Isolar os Programas dos detalhes específicos de hardware;
• Controlar o fluxo de dados entre os componentes de um computador;
• Permitir que os Programas sejam executados sem a interferência de outros 
Programas;
• Permitir que os Programas independentes cooperem periodicamente e com-
partilhem informações;
• Responder aos erros ou a solicitações dos usuários;
• Impor um escalonamento entre Programas que solicitam recursos;
• Facilitar o acesso aos recursos do Sistema.
O Sistema Operacional, então, serve de 
interface entre o usuário e os recursos dis-
poníveis no Sistema, tornando essa comu-
nicação transparente e permitindo ao usu-
ário uma utilização mais eficiente e com 
menores chances de erros. 
Sistemas Operacionais 
de Tempo Real
As principais funções de um SO são 
gerenciar os recursos de hardware e de 
software do Sistema Computacional e 
fornecer serviços específicos para os 
usuários do Sistema Computacional. Sis-
temas Operacionais de Tempo Real tam-
bém realizam as mesmas funções e servi-
ços de um SO.
Todavia, um SO de Tempo Real possui 
requisitos diferentes que surgem por causa 
da sua natureza. Uma característica funda-
mental que os diferes é a Previsibilidade. 
Essa característica se aplica de modo mais crítico em relação ao tempo. Todos 
os serviços devem ser realizados dentro de um intervalo de tempo conhecidos e 
Figura 1 – Sistema Operacional como uma interface
Fonte: Adaptado de iStock/Getty Images
9
UNIDADE Programação de Sistemas Operacionais para Aplicações em Tempo Real
determinados. Essa característica também é aplicada em todos os recursos geren-
ciados pelo SO de Tempo Real, tais como, armazenamento, dispositivos de E/S e 
arquivos. É importante também, que a gerência de falhas seja previsível. 
Outras características que os difere são a Visibilidade e o Controle para to-
dos os recursos do Sistema. Em um SO convencional, uma grande quantidade 
de hardware do Sistema Computacional é totalmente escondida e abstraída do 
usuário. Entretanto, em um SO de Tempo Real, os usuários devem ser capazes de 
acessar e controlar os recursos físicos do Sistema para garantir a previsibilidade. 
Habitualmente, um SO de Tempo Real é um Sistema aberto, isto é, aquele que de-
fine um conjunto de mecanismos apropriados e flexíveis. Um SO de Tempo Real deve 
possibilitar a definição de um amplo domínio de políticas, por exemplo, definição de di-
ferentes políticas de gerenciamento de memória, de gerenciamento de entrada e saída 
de dados e de gerenciamento de arquivos, entre outros. Criando um amplo conjunto de 
definições de políticas, o Sistema Operacional de Tempo Real se torna mais robusto. 
Um Sistema Operacional de Tempo Real compartilha dos mesmos conceitos e 
classificações de um Sistema de Tempo Real. Por exemplo, um SO de Tempo Real 
também é classificado em Crítico e Não Crítico. 
SOs de Tempo Real Críticos obedecem ao intervalo de tempo para a realiza-
ção da tarefa, isto é, não pode haver perda de prazo na realização de uma tarefa. 
O não cumprimento dos prazos pode causar resultados fatais. 
Em um SO de Tempo Real, uma realização de tarefa pode ser encarada como 
uma alocação de recurso, uma alocação de memória e uma abertura de um arquivo,e 
entre outros. Todavia, a tarefa deve cumprir o prazo de forma rigorosa; senão, resul-
tados fatais podem ocorrer. 
Um SO de Tempo Real crítico também é subclassificado em Seguro em Caso 
de Falha e Operacional em Caso de Falha. 
Seguro em Caso de Falha significa que, caso ocorram falhas, o SO consegue 
atingir um ou mais estados seguros. Operacional em Caso de Falha significa que, se 
ocorrerem falhas, o SO se degrada e consegue fornecer um tipo de serviço mínimo. 
No SO Tempo Real não Crítico, o tempo também é o fator mais importante; 
todavia, se ocorrerem falhas, elas são aceitáveis. Dessa forma, caso ocorra perda 
de prazo, os danos resultantes não serão letais.
Um SO de Tempo Real também pode ser classificado como Hard Real-Time, 
Soft Real-Time, Real Real-Time e Firm Real-Time. 
Hard Real-Time significa que o SO deve respeitar todos os prazos de forma 
absoluta, isto é, a perda de prazo não é tolerada. Soft Real-Time significa que se 
o SO perder algum prazo final, ocasionalmente, é tolerável. Os SO classificados 
como Real Real-Time são SOs Hard Real-Time que possuem prazos de respos-
tas extremamente curtos. 
10
11
Na classificação Firm Real-Time estão os Soft Real-Time que não possuem 
benefícios de entrega de serviço sem atraso. Para um melhor entendimento sobre 
essas classificações, consulte a Unidade I – Definição de Conceitos Básicos e da 
importância de Sistemas Computacionais para aplicações Tempo-Real.
Funções e Serviços de um so de Tempo Real
Um Sistema Operacional de Tempo Real deve realizar algumas funções básicas, 
tais como, criar Processos, gerenciar Processos, escalonar Processos, gerenciar 
memória, gerenciar arquivos, gerenciar dados de entrada e saída e, também, ge-
renciar todos os hardwares disponíveis no Sistema Operacional.
A próxima seção apresenta detalhes sobre Processos.
Processos
Um dos serviços mais importantes que o SO de Tempo Real realiza é criar, con-
trolar e destruir Processos. 
Um Processo é basicamente um Programa em Execução. O termo Processo se re-
fere ao Programa em Execuçãoe, também, todos os elementos necessários para que o 
Programa o execute, como, espaço de memória, código binário do Programa, espaço 
para armazenar dados de processamento e controlador de instruções (responsável por 
controlar quais instruções do programa falta serem executadas), entre outros. 
A maneira mais fácil de obter uma boa noção de Processos é pensar nos Siste-
mas de tempos compartilhados. Periodicamente, o SO decide parar de executar 
um Processo e começar a executar outro. 
Quando um Processo é suspenso temporariamente, mais tarde ele deve ser rei-
niciado exatamente no mesmo estado em que estava quando foi suspenso. Dessa 
forma, todas as informações do Programa devem ser armazenadas em algum lugar 
seguro durante a suspensão. 
Um Processo pode criar outros Processos. Nesse caso, temos uma relação de 
pai e filho, criando uma árvore de Processos, como é mostrado na Figura 2.
C
A
B
FED
Uma árvore de processos
- A criou dois processos �lhos: B e C
- B criou dois processos �lhos: D, E e F
Figura 2 – Relação entre Processos
Fonte: Acervo do Conteudista
11
UNIDADE Programação de Sistemas Operacionais para Aplicações em Tempo Real
Processos são executados na CPU do computador. Um Processo possui 3 estados:
1. Executando (realmente sendo executado na CPU nesse instante);
2. Pronto (executável; temporariamente parado para permitir que outro 
Processo execute na CPU);
3. Bloqueado (incapaz de executar até que algum evento externo aconteça).
A Figura 3 ilustra o ciclo de estados de um Processo.
Bloqueado
1
3
2
1 - O processo bloqueia para entrada
2 - O agendador seleciona outro processo
3 - O agendador seleciona esse processo
4 - A entrada torna-se disponível
4
Executando
Pronto
Figura 3 – Ciclo de estados de um Processo
Fonte: Adaptado de Tanenbaum
O agendador é responsável por selecionar o Processo e colocá-lo para executar 
na CPU. A próxima seção apresenta detalhes sobre um agendador.
Escalonamento
Outra função importante de um SO de Tempo Real é escalonar o Processo 
para ser executado pelo processado. Quando um Processo fica em estado de 
pronto, ele é colocado em fila de Processos, esperando a sua vez de ser escalonado 
para utilizar o processador, conforme ilustrado na Tabela 1. 
Tabela 1 – Fila de Processos
Processos
0 1 ... n – 2 n – 1
Agendador
Fonte: Acervo do Conteudista
A função de escalonamento é chamada de agendador ou escalonador. Fre-
quentemente, o termo em inglês Sheduling é utilizado para fazer referência à 
função de escalonamento do SO. 
Os Processos que se encontram em estado de prontos ficam numa fila e o escalo-
nador de Processos seleciona um Processo e o coloca para ser executado na CPU. 
Esse procedimento é ilustrado na Figura 4.
12
13
Espera
Execução
Processo
Processo
Processo
Processo
Processo
Pronto
Escalonador
Figura 4 – Escalonamento
Fonte: Acervo do Conteudista
Essa seleção é realizada a partir de um método de escalonamento, que selecio-
na o Processo utilizando um algoritmo de escalonamento. 
Existem diversos algoritmos de escalonamento; cada algoritmo de escalonamen-
to implementa uma lógica de seleção. 
Os algoritmos de escalonamento são classificados em dois grupos:
• Algoritmos de escalonamento estáticos; 
• Algoritmos de escalonamento dinâmicos.
Essa classificação baseia-se nas regras de escalonamento quanto à consideração 
do estado atual da aplicação. Como, por exemplo, no escalonamento estático, que 
não são consideradas as alterações do estado atual da aplicação. 
Dessa forma, as tarefas são alocadas antes da execução da aplicação e a execu-
ção é feita em função do escalonamento estabelecido. 
O escalonamento dinâmico detecta alterações no estado atual da aplicação e 
gerencia os recursos com base nas informações atuais da aplicação. 
As tarefas são alocadas em tempo de execução, considerando as informações 
e as condições da aplicação. Métodos de escalonamentos serão estudados com 
profundidade na unidade V – Métodos de Escalonamento.
É interessante lembrar que problemas de escalonamento de tarefas não ocorrem 
somente em Sistemas Operacionais; ocorrem, constantemente, em Sistemas de 
Tempo Real. 
Imagine o seguinte cenário: chegam duas tarefas ao mesmo tempo para o Sis-
tema de Tempo Real. Qual se deve atender primeiro? 
Os Sistemas de Tempo possuem uma política de escalonamento muito rígida, 
pois, habitualmente, chegam diversas tarefas ao mesmo tempo e o Sistema deve 
realizar a escolha de qual realizar primeiro a partir de um mecanismo de escalona-
mento, que selecionará a tarefa a ser executada primeiro utilizando determinadas 
regras implementadas no escalonador.
13
UNIDADE Programação de Sistemas Operacionais para Aplicações em Tempo Real
Threads 
Em Sistemas Operacionais de Tempo Real, é comum que Processos trabalhem 
em conjunto para realizar uma determinada tarefa. Frequentemente, quando dois 
Processos trabalham em conjunto, eles compartilham o mesmo recurso, seja ele 
um espaço de memória, seja um arquivo. Dessa forma, é necessário haver comu-
nicação e sincronização, entre os Processos.
Normalmente, num Processo, há uma única linha de execução. Entretanto, em 
alguns Sistemas Operacionais modernos, é fornecido suporte para múltiplas linhas 
de execução dentro de um Processo. 
Essas linhas de controle, normalmente, são chamadas Threads ou, ocasional-
mente, Processos Leves. 
Threads possuem os mesmos estados de um Processo, compartilham o mes-
mo espaço de endereçamento, permitindo que um thread possa alterar dados de 
outro thread. 
Assim como os Processos, Threads podem compartilhar o mesmo endereço 
de memória também. Habitualmente, Threads trabalham de forma cooperativa, 
assim como os Processos.
Thread 2
Thread 3
Processo
Thread 1
Figura 5 – Threads
Fonte: Acervo do Conteudista
Comunicação entre Threads
Habitualmente, Threads trabalham em conjunto para realizar um único traba-
lho. O mesmo se aplica a Processos. 
Com isso, em Sistemas Operacionais de Tempo Real, é necessário haver um 
mecanismo de comunicação e de sincronização. 
No trabalho em conjunto, frequentemente, há necessidade de compartilhar al-
guns armazenamentos de dados que podem ser lidos e gravados. 
O armazenamento compartilhado pode estar na memória principal ou pode 
ser um arquivo compartilhado; a localização da memória compartilhada não muda 
a natureza da comunicação ou os problemas que surgem. 
14
15
Para entender os problemas que surgem com o armazenamento compartilhado, 
imagine uma variável chamada cont. Essa variável contém o valor 10 e é compar-
tilhada entres os Processos A e B. 
Tanto o Processo A como o Processo B realizam uma operação de soma em 
cont. Uma operação de soma é realizada por três operações primitivas, Leitura, 
Soma e Armazenamento. 
O Processo A está em execução na CPU. Ele lê o conteúdo de cont., soma 1 ao 
valor de cont., mas, nesse momento, o Processo A perde a prioridade de execução 
na CPU e fica no estado de Pronto. 
Em seguida, o Processo B entra em estado de execução e lê o valor de cont., 
soma 1 e grava o resultado em cont. Logo após, o Processo B fica no estado de 
Pronto, deixando o Processo A usar a CPU. 
Agora, o Processo A continua na operação que ele parou, ou seja, continua a 
partir da escrita e escreve o resultado da soma em cont.
Nesse caso, o que houve com valor de cont.? 
O valor de cont. está corrompido, não é mais um valor confiável. Quando esse 
cenário ocorrer, dizemos que ocorreu uma condição de corrida.
Proceso BProceso A
Cont.
Figura 6 – Condição de Corrida
Fonte: Acervo do Conteudista
Para evitar condições é preciso implementar um mecanismo de execução mú-
tua, isto é, quando uma Thread estiver acessando a variável Cont., nenhuma outra 
Thread pode acessá-la. 
De uma maneira mais simples, é preciso criar um mecanismo de sincronização, 
que permita que uma Thread por vez acesse a variável Cont.. Existem diversas 
soluções para o problema de sincronização. 
O problema de sincronização e as suas soluções são abordadoscom mais deta-
lhes na Unidade VI – Problemas de sincronismo e temporização.
Todavia, nesta Unidade, iremos apresentar uma solução para o problema da 
variável Cont. 
Uma solução possível para evitar condição de corrida e, implicitamente, im-
plementar um mecanismo de sincronização nesse problema é criar uma variável 
de bloqueio. 
15
UNIDADE Programação de Sistemas Operacionais para Aplicações em Tempo Real
Nessa solução, é criada uma variável “bloqueio” com o valor 0, que significa 
que ninguém está acessando a variável Cont, e o valor 1 significa que alguém esta 
acessando Cont. 
Por exemplo, vamos supor que a Thread T1 acesse primeiro a variável Cont.; 
ao acessar a variável, a Thread T1 muda o valor de bloqueio para 1, impossibili-
dade de outras Threads acessarem a variável Cont. 
Quando a Thread T1 termina de acessar a Cont., ela muda o valor de bloqueio 
para 0, possibilitando que outras Threads acessem a variável Cont.
T2T1
Cont.
T1bloqueio = 0;
bloqueio = 1;
bloqueio = 0;
Figura 7 – Solução variável de bloqueio
Fonte: Acervo do Conteudista
Vale ressaltar que o problema de sincronização e as suas soluções serão abor-
dados com detalhes na Unidade VI – Problemas de Sincronismo e Temporização.
É importante enfatizar, também, que problemas de sincronização não aparecem 
somente em Sistemas Operacionais de Tempo Real, aparecem, constantemente, 
em Sistemas de Tempo Real como um todo. 
Imagine a seguinte situação: são necessários dois recursos (A e B) para realizar 
uma única tarefa. O Recurso A é responsável por iniciar a tarefa e, depois de algum 
tempo de processamento, o Recurso B continua o processamento. 
B não pode realizar o processamento se A não o iniciar primeiro. Esse exemplo, 
e diversos outros, ocorrem constantemente em Sistemas de Tempo Real.
Memória
Outra função importante de SO de Tempo Real é gerenciar a memória do Sis-
tema Computacional. Um computador possui diferentes níveis de memórias. Cada 
nível tem um propósito, uma capacidade e forma de acesso diferente. 
Os níveis de memória de computador são:
• Registradores;
16
17
• Memória Cache;
• Memória Principal;
• Memória Secundária. 
A Figura 8 ilustra os níveis de memória. Esta ilustração mostra a capacidade e a 
velocidade de cada nível:
Registradores
Memória Cache
Memória Principal
Memória Secundária
Maior custo
Maior Velocidade
Maior Capacidade
Figura 8 – Níveis de memória de um computador
Fonte: Acervo do Conteudista
Registradores são pequenos espaços de memórias presentes nos processa-
dores. Sua velocidade é extremamente rápida. É um nível de memória presente 
no processador. 
Por exemplo, para que o processador realize a soma entre 2 dois números, ele 
precisa de espaço de memória para armazenar os dois números e, posteriormente, 
armazenar o resultado. Esses números são armazenados em registradores, para 
possibilitar que o processador realize a soma. 
A Memória Cache também é uma memória de alta velocidade. O tempo de 
acesso a um dado nela armazenado é muito menor do que se ele estivesse na me-
mória principal, ou na memória secundária. 
Essa memória é nível de processador, isto é, uma memória dedicada a arma-
zenar dados para o processador. Esse nível de memória é mais lento do que os 
registradores; todavia, permite armazenar uma quantidade maior de dados. Essa 
quantidade é bem limitada, mas é maior que a dos registradores. Seu objetivo é 
armazenar dados que são utilizados com mais frequência; dessa forma, o proces-
samento fica mais rápido.
A Memória Primária, também chamada de memória RAM, tem velocidade re-
lativamente rápida; porém, é mais lenta do que a memória cache e os registradores. 
Em contrapartida, tem uma capacidade de armazenamento superior à dos regis-
tradores e cache. O objetivo da memória primária é fornecer espaço de memória 
para os programas serem executados. Todos os programas, inclusive o SO, são 
executados nesse nível de memória. 
17
UNIDADE Programação de Sistemas Operacionais para Aplicações em Tempo Real
A Memória Secundária é um meio permanente de armazenamento de progra-
mas e dados. Nesse nível, o acesso é mais lento se comparado ao acesso à memória 
cache ou à principal. Todavia, sua capacidade de armazenamento é superior a qual-
quer outro nível de memória. Exemplos de dispositivos de memória secundária: HD.
Dispositivos de Entrada e Saída de Dados
Fornecer gerenciamento de entrada e saída de dados é outra função que o SO 
de Tempo Real deve realizar. Dispositivos de entrada e saída de dados são utilizados 
para permitir a comunicação entre o computador e o mundo exterior. 
Os dispositivos de E/S podem ser divididos em duas categorias:
• Dispositivos que são utilizados como memória secundária;
• Dispositivos que servem para a interface homem-máquina.
Dispositivos que são utilizados como memórias secundárias são dispositivos que 
possibilitam estender o meio físico de armazenamento de dados. Por exemplo, um 
pen driver, é um dispositivo utilizado como memória secundária. 
Já os dispositivos que servem para a interface homem-máquina são aqueles 
dispositivos que possibilitam a entrada e saída de dados do computador para o 
ambiente externo, ou vice e versa. Por exemplo, um teclado ou um monitor são 
exemplos de dispositivos que servem como interface homem-máquina.
Arquivos
Outra função que um SO de Tempo Real deve fornecer é o gerenciamento 
de arquivos. 
Arquivos possibilitam o armazenamento de informações e devem ser armazena-
das ao longo do tempo; são constituídos de informações logicamente relacionadas. 
Por exemplo, um Programa pode ser considerado arquivo, porque é totalmente 
construído de informações lógicas. 
• Arquivos podem ser classificados em:
• Arquivos Executáveis; 
• Arquivos Lógicos;
• Arquivos de Somente Leitura;
• Arquivos de Somente Escrita. 
Arquivos armazenam informações, geralmente, em grandes quantidades. Essas in-
formações precisam ser armazenadas para serem utilizadas em diversos momentos. 
Dessa forma, ao se desligar o computador, essas informações não podem ser 
perdidas. Quando utilizadas, elas devem ser acessadas e lidas na memória do com-
18
19
putador. Há muitas formas de acesso às informações. Alguns Sistemas fornecem 
apenas um tipo, já outros, disponibilizam diferentes métodos, conforme a necessi-
dade da aplicação. 
Um SO de Tempo Real deve fornecer mecanismos para armazenar, buscar, apa-
gar, alterar e organizar arquivos, com o objetivo de facilitar o acesso às informações. 
Deve, também, permitir que as aplicações (Programas) criem e manipulem ar-
quivos. Dessa forma, é necessário que o SO de Tempo Real forneça mecanismos 
como o “System Calls de E/S” que são chamados de Sistemas, que possibilitam a 
aplicação de manipular o arquivo.
Dispositos
Aplicação
System Call de E/S
Figura 9 – System Calls de E/S
Fonte: Acervo do Conteudista
As chamadas de Sistemas (System Calls) de E/S deve fornecer os comandos, como:
• Create() – Responsável por criar arquivos; 
• Open() – Responsável por abrir arquivos;
• Read() – Responsável por ler arquivos;
• Write() – Responsável por escrever arquivos;
• Close() – Responsável por fechar arquivos;
• Rename() – Responsável por renomear arquivos;
• Delete() – Responsável por deletar arquivos.
Um arquivo deve possuir, ainda, atributos, tais como, nome, tamanho, data da 
criação, proteção e também, o uid (id do usuário) do criador do arquivo. O meca-
nismo de gerência de arquivo do SO é responsável por tudo isso.
19
UNIDADE Programação de Sistemas Operacionais para Aplicações em Tempo Real
Exemplos de Sistemas Operacionais 
de Tempo Real
Existem diversos Sistemas Operacionais de Tempo Real no Mercado.
Entre eles, estão; 
• RedHat Enterprise Linux for Real Time – Criado pela Empresa RedHat, 
o “RedHat Enterprise Linux for Real Time” é um Sistema Operacional de 
Tempo Real em Ambiente Linux;
• AIX – Advanced Interactive eXecutive – Este Sistema Operacional de Tempo 
é uma versão do Unix executados em computadores de médioporte da IBM;
• RTA-OSEK – Um Sistema de Tempo Real voltado para o comércio automotivo;
• AMX – Sistema de Tempo Real criado pela Empresa KADAK;
• CMX – Um Sistema Operacional desenvolvido pela Empresa CMX Company;
• RT-Linux – um Sistema Operacional desenvolvido para atender tarefas de 
Tempo Real e também tarefas que não acontecem de Tempo Real.
Conclusões e Resumo da Unidade
Sistemas Operacionais (SO) para aplicações de Tempo Real são Sistemas Ope-
racionais que devem responder a eventos pré-definidos em um intervalo de tempo 
conhecido, tendo como objetivos primários responder a eventos e respeitar o pra-
zo de resposta deles.
Assim como um Sistema de Tempo Real, um SO de Tempo Real deve ser al-
tamente confiável e deve responder aos eventos dentro do prazo determinado, 
mesmo na presença de falhas.
Para compreender de fato o que é um Sistema Operacional de Tempo Real, é 
necessário primeiro entender o que é um Sistema Operacional. 
Um Sistema Operacional pode ser visto como um gerenciador de recursos, que 
gerencia todos os recursos de um Sistema Computacional. Seu objetivo é fornecer um 
ambiente para que o usuário possa executar seus Programas de forma fácil e eficaz. 
Dessa forma, ele também pode ser visto como um intermediário entre o usuário 
e o hardware de um Sistema Computacional. Um Sistema Operacional de Tempo 
Real é um SO Convencional, isto é, possui o mesmo objetivo que um SO Conven-
cional. Todavia, é um SO que deve responder um evento pré-definido num prazo 
de tempo estipulado. Caso isso não aconteça, danos irreversíveis podem ocorrer.
Um SO de Tempo Real também possui as mesmas características de um Sistema 
de Tempo Real. Um SO de Tempo Real pode ser classificado em SO de Tempo 
Real crítico e não crítico. 
20
21
O crítico não tolera perda de prazo e no não crítico, ocasionalmente, a perda 
de prazo é tolerada. 
Um SO de Tempo Real crítico pode ser classificado como Seguro em Caso de 
Falhas e Operacional em Caso de Falha. Seguro em Caso de Falha, o SO consegue 
atingir um ou mais estados possíveis caso ocorra falhas. Seguro em Caso de Falhas, 
o SO se degrada e fornece algum tipo de serviço mínimo.
Um SO de Tempo Real também pode ser classificado como Hard Real-Time, 
Soft Real-Time, Real Real-Time e Firm Real-Time. Hard Real-Time leva em 
consideração o prazo para realizar uma tarefa. 
Um SO de Tempo Real deve fornecer serviços básicos, tais como, gerencia-
mento de Processos, gerenciamento de memória, gerenciamento de arquivos e 
gerenciar todos os recursos físicos do Sistema Computacional.
No gerenciamento de Processos, o SO deve fornecer mecanismos para criação, 
escalonamento, manipulação e destruição de Processos. Um Processo pode ser 
abstraído como um Programa em execução. 
Todavia, não é apenas um Programa em execução; é tudo o que um Programa 
precisa para rodar, tal como, memória para se executado, memória para armaze-
namento de dados e pilha de instrução, entre outros; o termo Processo envolve 
tudo isso. 
Um Processo possui 3 estados, executando, pronto e bloqueado. Executando: 
o Processo está em execução na CPU; Pronto: significa que o Processo está apto 
para ser executado na CPU; todavia, está aguardando a sua vez chegar; Bloqueado: 
significa que o Processo está bloqueado esperando um evento externo acontecer. 
Quando um Processo está pronto, ele fica em fila de espera, esperando sua 
vez de ser executado na CPU. Um agendador é responsável por selecionar um 
Processo e colocá-lo na CPU para executar. Essa seleção é feita por um método 
de escalonamento. 
Normalmente, um Processo tem apenas uma linha de execução. Todavia, SO 
de Tempo Real fornece suporte a múltiplas linhas de execução em um Processo. 
Essas linhas de execução são chamadas de Threads. Habitualmente, Threads 
trabalham juntos para realizar uma atividade. Frequentemente, nessas atividades 
há necessidade das threads se comunicarem. Na comunicação entre threads, há 
necessidade de haver um mecanismo de sincronização. 
Outra funcionalidade que um SO deve oferecer é o gerenciamento de memória. 
Um Sistema computacional possui níveis de memórias, que são; registradores, 
memória cache, memória primária e memória secundária.
Registradores são pequenos espaços de memória presentes nos processadores; 
a memória cache é um nível de memória dedicada ao processador; já a memória 
primária é utilizada para executar programas e a memória secundária é utilizada 
para armazenar arquivos.
21
UNIDADE Programação de Sistemas Operacionais para Aplicações em Tempo Real
Fornecer um gerenciamento de entrada e saída de dados é outra função que o 
SO de Tempo Real deve realizar. Dispositivos de entrada e saída de dados são utili-
zados para permitir a comunicação entre o computador e o mundo exterior. Outra 
funcionalidade que um SO de Tempo Real deve ter é disponibilizar um mecanismo 
de gerência de arquivo. 
Arquivos possibilitam o armazenamento de informações que devem ser armaze-
nadas ao longo do tempo e são constituídos de informações logicamente relaciona-
das. O SO deve fornecer “chamadas de Sistema” para as aplicações manipularem 
os arquivos.
Como visto nesta Unidade, um Sistema Operacional de Tempo Real é um Sis-
tema Operacional Convencional que se preocupa em responder eventos pré-defi-
nidos, respeitando prazos. 
Um Sistema Operacional de Tempo Real deve fornecer serviços que são muito 
importantes para aplicações de Tempo Real. 
No Mercado, há diversos tipos de Sistemas Operacionais de Tempo Real, cada 
um com objetivos diferentes e aplicados em contextos diferentes. 
22
23
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
 Sites
Sistemas de Tempo Real – Parte 1
https://goo.gl/w3BRV1
 Vídeos
Sistema em Tempo Real - SO
https://youtu.be/gaO9o-ZfMiU
Sistemas de tempo real
https://youtu.be/HTLZUCkdQbA
 Leitura
Sistemas de Tempo Real
https://goo.gl/4bcgvB
23
UNIDADE Programação de Sistemas Operacionais para Aplicações em Tempo Real
Referências
GALVIN, S. Sistemas Operacionais conceitos. 5.ed. São Paulo: Prentice Hall, 2000.
______. Sistemas Operacionais conceitos. 3.ed. São Paulo: Prentice Hall, 1998. 
SHAW, A. C. Sistemas E Software de Tempo Real, Porto Alegre: Bookman, 2003.
TANENBAUM, A. S. Sistemas Operacionais Modernos. 2.ed. São Paulo: 
Pearson Prentice Hall, 2003.
24
Sistemas de Tempo Real
Material Teórico
Responsável pelo Conteúdo:
Prof. Dr. Cléber Silva Ferreira da Luz
Revisão Textual:
Prof.ª Esp. Kelciane da Rocha Campos
Sistemas de Tempo Real Distribuídos
• Introdução;
• Definição de Sistema Distribuído;
• Modelos de Programação;
• Plataformas de Processamento;
• MPI;
• Conclusão e Resumo da Unidade.
 · Apresentar todos os conceitos envolvidos no desenvolvimento de sis-
temas de tempo real distribuídos.
OBJETIVO DE APRENDIZADO
Sistemas de Tempo Real Distribuídos
Orientações de estudo
Para que o conteúdo desta Disciplina seja bem 
aproveitado e haja maior aplicabilidade na sua 
formação acadêmica e atuação profissional, siga 
algumas recomendações básicas: 
Assim:
Organize seus estudos de maneira que passem a fazer parte 
da sua rotina. Por exemplo, você poderá determinar um dia e 
horário fixos como seu “momento do estudo”;
Procure se alimentar e se hidratar quando for estudar; lembre-se de que uma 
alimentação saudável pode proporcionar melhor aproveitamento do estudo;
No material de cada Unidade, há leituras indicadas e, entre elas, artigos científicos, livros, vídeos 
e sites para aprofundar os conhecimentos adquiridos ao longo da Unidade. Além disso, você 
também encontrará sugestões de conteúdo extra no item Material Complementar, que ampliarão 
sua interpretação e auxiliarão no pleno entendimento dos temas abordados;
Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de discus-
são, pois irão auxiliar a verificar o quanto você absorveu de conhecimento, além de propiciar o 
contato com seus colegas e tutores, o que se apresentacomo rico espaço de troca de ideias e 
de aprendizagem.
Organize seus estudos de maneira que passem a fazer parte 
Mantenha o foco! 
Evite se distrair com 
as redes sociais.
Mantenha o foco! 
Evite se distrair com 
as redes sociais.
Determine um 
horário fixo 
para estudar.
Aproveite as 
indicações 
de Material 
Complementar.
Procure se alimentar e se hidratar quando for estudar; lembre-se de que uma 
Não se esqueça 
de se alimentar 
e de se manter 
hidratado.
Aproveite as 
Conserve seu 
material e local de 
estudos sempre 
organizados.
Procure manter 
contato com seus 
colegas e tutores 
para trocar ideias! 
Isso amplia a 
aprendizagem.
Seja original! 
Nunca plagie 
trabalhos.
UNIDADE Sistemas de Tempo Real Distribuídos
Introdução
Sistemas de tempo real são sistemas computacionais que se preocupam em 
responder a eventos em um determinado intervalo de tempo. Neste sistema com-
putacional, eventos chegam a todo o momento, e o sistema deve responder a tais 
eventos em prazo determinado. Um sistema de tempo real deve ser capaz de res-
ponder a diversos eventos simultaneamente. Dessa forma, a programação paralela 
e destruída possui grande influência em sistemas de tempo real. Um sistema com-
putacional que responde a eventos de tempo real pode utilizar tanto computação 
paralela, como computação distribuída, visando responder aos diversos eventos 
simultaneamente e não perdendo nenhum prazo.
Nesta aula, iremos realizar um estudo sobre sistemas de tempo real distribuído, 
isto é, sistemas de tempo implementados na forma de sistemas distribuídos. Todos 
os conceitos e elementos envolvidos na computação distribuída serão estudados 
nesta unidade, bem como a definição de sistema distribuído, plataforma de proces-
samento, modelos de programação, entre outros.
Definição de Sistema Distribuído
Vamos começar pela definição de um sistema distribuído. Segundo Tanenbaum 
(2003), “um sistema distribuído é uma coleção de computadores independentes 
entre si que se apresenta ao usuário como um sistema único e coerente”. Em outra 
definição mais clara, um sistema distribuído é um sistema computacional composto 
por vários computadores conectados por uma rede física que se apresenta ao usu-
ário como um único computador.
Em um sistema distribuído, cada computador é considerado como uma unida-
de de processamento. Uma unidade de processamento recebe vários nomes, tais 
como nó, node, máquina, host, entre outros. Nesta unidade, como uma forma 
de padronizar a nomenclatura, iremos nos referir a uma unidade de processa-
mento como node. Toda vez que falamos a palavra node, estamos nos referindo 
a um computador do sistema distribuído. Um sistema distribuído visa distribuir o 
processamento de dados entre os n nodes presentes no sistema computacional 
(TANENBAUM, 2003).
Um sistema distribuído pode ser classificado como:
• Homogêneo; e
• Heterogêneo.
Um sistema distribuído homogêneo é um sistema composto por unidades de 
processamento iguais, isto é, todos os computadores do sistema distribuído são 
iguais. Já um sistema distribuído heterogêneo é composto por vários computadores 
diferentes, cada node no sistema é diferente um do outro.
8
9
Node 01
Node 02
Node 05 Node 06
Node 04 Node 03
Figura 1 – Sistema distribuído
Agora que já definimos um sistema distribuído, por que implementar um sistema de 
tempo real de forma distribuída? A próxima seção nos ajuda a entender essa questão.
Por Que Criar um Sistema de Tempo Real Distribuído?
Existem 4 motivos para criar um sistema de tempo real de forma distribuída.
• Compartilhamento de recursos;
• Aumento da velocidade;
• Confiabilidade;
• Comunicação.
Compartilhamento de recursos: uma das principais vantagens de criar um 
sistema de tempo real de forma distribuída é o compartilhamento de recursos. 
Um mecanicismo de compartilhamento em um sistema distribuído deve prover 
o compartilhamento de arquivos, dados, processamento e recursos. Por exem-
plo, um sistema distribuído permite compartilhar o processamento. Cada node se 
apresenta como uma unidade de processamento. Dessa forma, um sistema dis-
tribuído pode distribuir o processamento dos diversos eventos a que ele deve res-
ponder simultaneamente e, assim, responder a todos os eventos ao mesmo tempo 
(TANENBAUM, 2003).
Aumento da velocidade: um sistema de tempo real deve responder a todos os 
eventos no intervalo de tempo determinado, isto é, não deve haver perda de prazo. 
Se o sistema de tempo real puder compartilhar as tarefas que devem ser realizadas 
ao se responder a um evento, o tempo de resposta irá diminuir proporcionalmen-
te. Por exemplo, uma tarefa leva 4 minutos para ser respondida. Se o sistema de 
tempo real distribuído possuir 4 recursos capazes de compartilhar o processamento 
de tal resposta, o tempo de resposta seria de 1 minuto. Com o compartilhamento 
9
UNIDADE Sistemas de Tempo Real Distribuídos
da tarefa, a velocidade de processamento aumenta e o tempo de resposta diminui 
(TANENBAUM, 2003).
Confiabilidade: um sistema de tempo real deve ser totalmente tolerante a fa-
lhas, caso as mesmas ocorram o sistema deve completar a tarefa no prazo deter-
minado. Em um sistema de tempo real distribuído, caso um node falhe, os demais 
nodes podem continuar o processamento sem problema nenhum, isto é, se o 
processamento realizado no momento da falha for independente. Caso o proces-
samento dependa dos outros nodes, o sistema deve identificar e corrigir a falha 
imediatamente. É importante enfatizar que o fato de o sistema agora possuir mais 
unidades de processamento não mascara a ocorrência de falhas, as mesmas podem 
ocorrer e devem ser solucionadas imediatamente (TANENBAUM, 2003).
Comunicação: um sistema de tempo real distribuído facilita a comunicação 
entre os processos. Quando várias máquinas estão conectadas umas às outras por 
uma rede, a comunicação, isto é, a troca de mensagem, é realizada de forma fácil 
e eficaz (TANENBAUM, 2003).
É importante ressaltar que, para aumentar a velocidade no processamento e, 
consequentemente, ganhar mais desempenho no processamento de uma aplicação 
distribuída, o sistema computacional deve possuir um bom mecanismo de balan-
ceamento de carga. Um mecanismo de balanceamento de carga irá balancear 
as cargas de trabalhos entre os diversos nodes do sistema distribuído. Uma má 
distribuição na carga de trabalho entre os recursos de processamento pode sobre-
carregar alguns recursos e deixar outros ociosos, impactando no desempenho da 
aplicação (GALVIN, 2000).
Modelos de Programação
Diversos modelos de programação são utilizados em sistemas de tempo real, 
entre eles estão:
• Modelo mestre e escravo;
• Pool de tarefa;
• Pipeline.
As próximas seções apresentam mais detalhes sobre estes modelos de programação.
Modelo Mestre e Escravo
No modelo mestre escravo, um node é definido como mestre e os demais 
nodes são definidos como escravos. O node mestre envia dados para os escravos 
processarem. Os nodes escravos, por sua vez, recebem os dados, processam tais 
dados e os enviam novamente para o mestre. Após receber os dados processados, 
o node mestre envia mais dados para os escravos processarem. O envio e recebi-
mento de dados é realizado até que todos os dados sejam processados.
10
11
Processo Mestre
escravo 1 escravo 2 escravo N
. . .
Figura 2 – Modelo mestre e escravos
Neste modelo de programação, há uma comunicação muito grande entre o mes-
tre e os escravos. Dessa forma, este modelo é muito eficiente quando a granulari-
dade da computação é grossa, isto é, cada computador realiza uma quantidade 
grande de computação. A granularidade grossa mascara o overhead da comunica-
ção. Agora se a granularidade da computação é fina, isto é, a computação que 
cada computador irá realizar é pequena, este modelo já não é tão eficiente, porque 
o overhead da comunicação será maior que a computação (TANENBAUM, 2003).
Para a computação neste modelo ser eficiente, deve-se, também, realizar as 
seguintes observações:• este modelo funciona perfeitamente quando as tarefas são independentes; e
• quando as tarefas ocorrem de forma inesperada.
Pool de Tarefas
Neste modelo de programação, não há a figura de um elemento central contro-
lando o processamento. Os próprios nodes são responsáveis por pegar, selecionar 
a tarefa que eles irão processar. Como se os nodes mergulhassem em uma “piscina 
de tarefa”. Após processar uma tarefa, o node volta para a “piscina de tarefa” e 
seleciona outra tarefa para processar.
Neste modelo de programação, o processamento só termina quando todas as 
tarefas tiverem sido processadas.
Node 01
Node 02
Node 05 Node 06
Node 04 Node 03
Tarefa 1
Tarefa 2
Tarefa 3
Tarefa 4
Figura 3 – Pool de tarefas
11
UNIDADE Sistemas de Tempo Real Distribuídos
Pipeline
Neste modelo de programação, as unidades de processamento são responsáveis 
por processar uma fração da tarefa. A distribuição do processamento é realizada da 
seguinte forma: cada node realiza um “pedacinho” da tarefa. Conforme ilustrado 
na Figura 4.
Node 01 Node 02 Node 05Node 04Node 03
Tarefa 1
Tarefa 1
Tarefa 1
Tarefa 1
Tarefa 1
Figura 4 – Modelo de programação Pipeline
Plataformas de Processamento
Um sistema de tempo real distribuído pode utilizar diversas plataformas de pro-
cessamento, entre elas:
• Cluster;
• Grid.
Cluster
Um Cluster pode ser considerado como vários computadores conectados por 
uma rede física que se apresenta para o usuário como um único computador. Nes-
te sistema computacional, cada computador é considerado como uma unidade de 
processamento independente, e juntos processam uma aplicação de forma distribu-
ída. Habitualmente, um Cluster possui uma unidade central que se apresenta para 
o usuário como sendo “um único computador”.
12
13
O objetivo principal de um Cluster é distribuir o processamento da aplicação. 
Distribuindo o processamento da aplicação, é possível aumentar a velocidade do 
processamento da aplicação e ganhar mais desempenho no processamento.
Unidade Central
Figura 5 – Cluster
Um Cluster pode usar vários modelos de programação, tais como mestre e es-
cravo, pool de tarefas e pipeline.
Grid
Assim como um Cluster, um Grid é um aglomerado de computadores que se 
apresenta para o usuário como um único computador. Todavia, a diferença entre 
os dois é a forma como as máquinas são conectadas. Em um Grid, os computado-
res são conectados por uma rede internet e não mais por uma rede física.
Um Grid possui o mesmo objetivo de um Cluster, isto é, distribuir o proces-
samento da aplicação. Como também utiliza os modelos de programação de um 
Cluster. Realmente, a única característica que os difere é a forma como os compu-
tadores são conectados. Cluster por uma rede física e Grid pela internet.
MPI
É muito comum um sistema de tempo real distribuído ser implementado utili-
zando um Cluster de computadores. MPI (Message-Passing Interface) é uma bi-
blioteca de desenvolvimento voltada para aplicações distribuídas. Tendo como foco 
o envio e recebimento de mensagem, esta biblioteca é muito utilizada em Cluster 
de computadores. MPI disponibiliza funções para enviar e receber dados entre os 
vários nós do Cluster. Nesta seção, iremos estudar os principais aspectos de desen-
volvimento de um sistema distribuído utilizando MPI. Iremos estudar as principais 
funções do MPI, entre elas daremos mais foco para as funções:
• MPI_Init();
• MPI_Finalize();
13
UNIDADE Sistemas de Tempo Real Distribuídos
• Send();
• Recv();
• Isend();
• Irecv();
• Bcast();
• Scatter();
• Gather().
Em um programa MPI, processos são representados por ranks e estes são nu-
merados, ex.: rank 0, rank 1, rank 2, rank 3 ... rank n.
Um programa MPI sempre começa com MPI_Init(int *argc,char *argv); e ter-
mina com MPI_Finalize(void);, entre MPI_Init e MPI_Finalize deve estar todo o 
código distribuído do programa.
Uma mensagem pode ser enviada pela função MPI_Send(). A sintaxe do MPI_
Send() é a seguinte:
MPI_Send(void *buf,int count,MPI_Datatype 
dtype,int dest,int tag,MPI_Comm comm); 
Nesta função:
• buf é o endereço do dado;
• int count é a quantidade de dados que será enviada;
• MPI_Datatype é o tipo de dado que será enviado;
• Dest é o número do rank destino;
• tag é uma tag de identificação da mensagem;
• comm é o “canal” de comunicação entre os ranks.
Para o recebimento da mensagem, MPI disponibiliza a função MPI_Recv (). Sua 
sintaxe é:
MPI_Recv(void *buf,int count,MPI_Datatype 
dtype,int source,int tag,MPI_Comm comm,MPI_Status *status);
Nesta função:
• buf é o endereço onde o dado será armazenado;
• count é a quantidade de dados que será armazenada;
• MPI_Datatype é o tipo de dado que será armazenado;
• source é a identificação do rank emissor;
• comm é o “canal” de comunicação entre os ranks;
• status é uma estrutura que armazena o status da comunicação.
14
15
A Figura 6 ilustra um pequeno trecho de código em MPI utilizando a função 
Send() e Recv(). Nesse programa, utiliza-se o modelo mestre e escravo.
Figura 6 – Trecho de Código MPI Send e Recv
As funções Send() e Recv() são bloqueantes. Por exemplo, o rank 0 envia uma 
mensagem para o rank 1. O rank 1 ficará bloqueado até que toda a mensagem seja 
transmitida. Após o término da transmissão da mensagem, o rank 1 será desblo-
queado e pode continuar o processamento.
MPI_Send
MPI_Reve
espera
espera
Figura 7 – Send e Recv bloqueantes
MPI também disponibiliza as funções Isend() e IRecv() para o envio de men-
sagem não bloqueante. Utilizando o Isend() e o IRecv(), tanto o receptor como o 
emissor não ficam bloqueados. Por exemplo, o rank 0 pode enviar mensagem 
para o rank 1 e continuar o seu processamento. O mesmo ocorre com o rank 1 
- enquanto os dados são transmitidos, o rank 1 pode continuar o processamento.
A sintaxe do Isend é:
MPI_Isend(void *buf,int count,MPI_Datatype 
dtype,int dest,int tag,MPI_Comm comm,MPI_Request *req)
Nesta função:
• buf é o endereço do dado;
• int count é a quantidade de dados que será enviada;
• MPI_Datatype é o tipo de dado que será enviado;
• Dest é o número do rank destino;
• tag é uma tag de identificação da mensagem;
• comm é o “canal” de comunicação entre os ranks;
15
UNIDADE Sistemas de Tempo Real Distribuídos
• req é o objeto que contém informações sobre a mensagem.
• Já a sintaxe do Irecv() é: 
MPI_Irecv(void *buf,int count,MPI_Datatype dtype, 
int source, int tag, MPI_Comm comm, MPI_Request *req);
Nesta função:
• buf é o endereço onde o dado será armazenado;
• count é a quantidade de dados que será armazenada;
• MPI_Datatype é o tipo de dado que será armazenado;
• source é a identificação do rank emissor;
• comm é o “canal” de comunicação entre os ranks;
• req é o objeto que contém informações sobre a mensagem.
MPI_ISend
MPI_IReve
Figura 8 – ISend e IRecv não bloqueantes
MPI ainda disponibiliza funções para o envio de mensagens coletivas MPI_Bcast(). 
Utilizando-se essa função, uma mensagem será enviada para todos os ranks. MPI_
Bcast() realiza uma de broadcast. Nesta operação todos os processos especificam o 
mesmo processo root (argumento root), cujo conteúdo do buffer será enviado. Os 
demais processos especificam buffers de recepção. Após a execução da chamada, 
todos os buffers contêm os dados do buffer do processo root. Sua sintaxe é a seguinte:
MPI_Bcast(void *buf,int count,MPI_Datatype dtype,int root,MPI_Comm comm);
Nesta função:
• buf é o buffer onde o dado está localizado;
• count é a quantidade de dados que será transmitida;
• MPI_Datatype é o tipo de dado que será armazenado;
• comm é o “canal” de comunicação entre os ranks.
Outras funções de envio e recebimento de dados coletivos são Scatter() e 
Gather(). A função Scatter compartilha os dados armazenados em um buffer 
entre os recursos. Na operação scatter todos os processos especificam o mesmo 
count (número de elementos a serem recebidos). Argumentos send são significan-
tes apenas para o processo root.
16
17
A sintaxe do Scatter é:
MPI_Scatter(void*sendbuf,int sendcount,MPI_Datatype sendtype,void 
*recvbuf,int recvcount,MPI_Datatype recvtype,int root,MPI_Comm comm);
Nesta função:
• buf é o buffer onde o dado está localizado;
• count é a quantidade de dados que será transmitida;
• MPI_Datatype é o tipo de dado que será enviado;
• Recvbuf é o buffer onde os dados serão armazenados;
• Recvcount é a quantidade de dados que serão armazenados;
• Datatype é o tipo de dado que será armazenado;
• root é o rank emissor da mensagem;
• comm é o “canal” de comunicação entre os ranks.
Já a função Gather() é o contrário, recolhe os dados dos buffer de todos os ranks 
e os armazena no buffer do rank mestre. A sintaxe do Gather é:
MPI_Gather(void *sendbuf,int sendcount,MPI_Datatype sendtype,void 
*recvbuf,int recvcount,MPI_Datatype recvtype,int root,MPI_Comm comm); 
Nesta função:
• buf é o buffer onde o dado está localizado;
• count é a quantidade de dados que será transmitida;
• MPI_Datatype é o tipo de dado que será enviado;
• Recvbuf é o buffer onde os dados serão armazenados;
• Recvcount é a quantidade de dados que será armazenada;
• Datatype é o tipo de dado que será armazenado;
• root é o rank emissor da mensagem;
• comm é o “canal” de comunicação entre os ranks.
Conclusão e Resumo da Unidade
Um sistema de tempo real pode ser implementado de forma distribuída. Um sistema 
distribuído é um sistema computacional composto por vários computadores conecta-
dos por uma rede física que se apresenta ao usuário como um único computador.
Em um sistema distribuído, cada computador é considerado como uma unida-
de de processamento. Uma unidade de processamento recebe vários nomes, tais 
como nó, node, máquina, host, entre outros.
17
UNIDADE Sistemas de Tempo Real Distribuídos
Um sistema distribuído pode ser classificado como homogêneo ou heterogê-
neo. Um sistema homogêneo é um sistema composto por unidades de processa-
mento iguais, isto é, todos os computadores do sistema distribuído são iguais. Já 
um sistema distribuído heterogêneo é composto por vários computadores diferen-
tes, cada node no sistema é diferente um do outro.
Ao se criar um sistema de tempo real distribuído, pode-se encontrar 4 vanta-
gens, que são: Compartilhamento de recursos, Aumento da velocidade, Con-
fiabilidade e Comunicação.
Compartilhamento de recursos: um mecanicismo de compartilhamento em 
um sistema distribuído deve prover o compartilhamento de arquivos, dados, pro-
cessamento e recursos.
Aumento da velocidade: um sistema de tempo real deve responder a todos os 
eventos no intervalo de tempo determinado, isto é, não deve haver perda de prazo. 
Se o sistema de tempo real puder compartilhar as tarefas que devem ser realizadas 
ao se responder a um evento, o tempo de resposta irá diminuir proporcionalmente.
Confiabilidade: um sistema de tempo real deve ser totalmente tolerante a fa-
lhas, caso as mesmas ocorram o sistema deve completar a tarefa no prazo deter-
minado. Em um sistema de tempo real distribuído, caso um node falhe, os demais 
nodes podem continuar o processamento sem problema nenhum, isto é, se o 
processamento realizado no momento da falha for independente.
Comunicação: um sistema de tempo real distribuído facilita a comunicação entre 
os processos quando várias máquinas estão conectadas umas às outras por uma rede 
a comunicação, isto é, a troca de mensagem é realizada de forma fácil e eficaz.
Um sistema distribuído deve possuir um mecanismo de balanceamento de carga 
que será responsável por balancear as cargas de trabalhos entre os diversos nodes 
do sistema distribuído.
Um sistema distribuído pode utilizar diversos modelos de programação, entre 
eles estão: o modelo mestre e escravo, pool de tarefas e pipeline.
No modelo mestre escravo, um node é definido como mestre e os demais 
nodes são definidos como escravos. O node mestre envia dados para os escravos 
processarem. Os nodes escravos, por sua vez, recebem os dados, processam tais 
dados e os enviam novamente para o mestre. Após receber os dados processados, 
o node mestre envia mais dados para os escravos processarem.
No modelo pool de tarefas, os próprios nodes são responsáveis por pegar, 
selecionar a tarefa que eles irão processar. Como se os nodes mergulhassem em 
uma “piscina de tarefa”. Após processar uma tarefa, o node volta para a “piscina 
de tarefa” e seleciona outra tarefa para processar.
No modelo Pipeline, as unidades de processamento são responsáveis por pro-
cessar uma fração da tarefa. A distribuição do processamento é realizada da seguin-
te forma: cada node realiza um “pedacinho” da tarefa.
18
19
Um Cluster pode ser considerado como vários computadores conectados por 
uma rede física que se apresenta para o usuário como um único computador. Neste 
sistema computacional, cada computador é considerado como uma unidade de pro-
cessamento independente, e juntos processam uma aplicação de forma distribuída.
Assim como um Cluster, um Grid é um aglomerado de computadores que se 
apresenta para o usuário como um único computador. Todavia, a diferença entre 
os dois é a forma como as máquinas são conectadas. Em um Grid, os computado-
res são conectados por uma rede internet e não mais por uma rede física.
Habitualmente, um sistema de tempo real distribuído é implementado utilizando 
um Cluster de computadores. MPI (Message-Passing Interface) é uma biblioteca 
de desenvolvimento voltada para aplicações distribuídas. Tendo como foco o envio 
e recebimento de mensagem, esta biblioteca é muito utilizada em Cluster de com-
putadores. MPI disponibiliza funções para enviar e receber dados entre os vários 
nós do cluster.
19
UNIDADE Sistemas de Tempo Real Distribuídos
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
 Vídeos
Sistema em Tempo Real - SO
https://youtu.be/gaO9o-ZfMiU
Sistema em Tempo Real
https://youtu.be/HTLZUCkdQbA
 Leitura
Sistemas de tempo real – parte 1
https://goo.gl/K29zuC
Sistemas de tempo real
https://goo.gl/4bcgvB
20
21
Referências
GALVIN, S. Sistemas operacionais: conceitos. 5ª edição. São Paulo: Prentice 
Hall, 2.000.
________, S. Sistemas operacionais: conceitos e aplicações. 3ª edição. Rio de 
Janeiro: Campus, 1998.
SHAW, A. C. Sistemas e software de tempo real. Porto Alegre: Bookman, 2003.
TANENBAUM, A. S. Sistemas operacionais modernos. 2ª edição. São Paulo: 
Pearson Prentice Hall, 2003.
21
Sistemas de Tempo Real
Material Teórico
Responsável pelo Conteúdo:
Prof. Dr. Cléber Silva Ferreira da Luz
Revisão Textual:
Prof.ª Esp. Kelciane da Rocha Campos
Métodos de Escalonamento
• Introdução;
• Escalonamento Preemptivo e não Preemptivo;
• Características de Escalonamento;
• Escalonamento de Tarefas;
• Conclusões e Resumo da Unidade.
 · Apresentar os principais algoritmos de escalonamento no âmbito de 
sistemas de tempo real distribuído.
OBJETIVO DE APRENDIZADO
Métodos de Escalonamento
Orientações de estudo
Para que o conteúdo desta Disciplina seja bem 
aproveitado e haja maior aplicabilidade na sua 
formação acadêmica e atuação profissional, siga 
algumas recomendações básicas: 
Assim:
Organize seus estudos de maneira que passem a fazer parte 
da sua rotina. Por exemplo, você poderá determinar um dia e 
horário fixos como seu “momento do estudo”;
Procure se alimentar e se hidratar quando for estudar; lembre-se de que uma 
alimentação saudável pode proporcionar melhor aproveitamento do estudo;
No material de cada Unidade, há leituras indicadas e, entre elas, artigos científicos, livros, vídeos 
e sites para aprofundar os conhecimentos adquiridos ao longo da Unidade. Além disso, você 
também encontrará sugestões de conteúdo extra no item Material Complementar, que ampliarão 
sua interpretação e auxiliarão no pleno entendimento dos temas abordados;
Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de discus-
são, pois irão auxiliar a verificar o quanto você absorveu de conhecimento, além de propiciar o 
contato com seus colegase tutores, o que se apresenta como rico espaço de troca de ideias e 
de aprendizagem.
Organize seus estudos de maneira que passem a fazer parte 
Mantenha o foco! 
Evite se distrair com 
as redes sociais.
Mantenha o foco! 
Evite se distrair com 
as redes sociais.
Determine um 
horário fixo 
para estudar.
Aproveite as 
indicações 
de Material 
Complementar.
Procure se alimentar e se hidratar quando for estudar; lembre-se de que uma 
Não se esqueça 
de se alimentar 
e de se manter 
hidratado.
Aproveite as 
Conserve seu 
material e local de 
estudos sempre 
organizados.
Procure manter 
contato com seus 
colegas e tutores 
para trocar ideias! 
Isso amplia a 
aprendizagem.
Seja original! 
Nunca plagie 
trabalhos.
UNIDADE Métodos de Escalonamento
Introdução
Habitualmente, um sistema de tempo real recebe diversos eventos do ambiente 
ao mesmo tempo. A qual sistema deve responder? Em muitos casos, o sistema 
possui múltiplos recursos de processamento e múltiplos eventos para responder. 
Neste caso, devem-se escalonar os múltiplos eventos para serem processados pelos 
múltiplos recursos de processamento. Os múltiplos eventos são processados de 
forma paralela ou distribuída, isto é, simultaneamente.
O primeiro passo é entender o que é um escalonamento. Problemas que envol-
vem escalonamento ocorrem em diversas áreas. Por exemplo, problema de esca-
lonamento ocorrem em hospitais, universidades, indústrias, entre outros. Em uni-
versidades, o problema de escalonamento aparece na atribuição de aulas para os 
professores e na alocação de sala para as disciplinas. Na alocação de sala, é preciso 
alocar as salas para as disciplinas, tomando-se cuidado para não alocar uma mesma 
sala para duas disciplinas e seguindo-se algumas restrições preestabelecidas, como 
o horário das disciplinas. Em hospitais, o problema de escalonamento ocorre na 
alocação de salas para realizar cirurgias, alocação de médicos e enfermeiros para 
atender os pacientes, entre outras formas.
De um modo geral, o problema de escalonamento é definido como se segue: 
dados y recursos e z tarefas, é preciso alocar os y recursos para as z tarefas, res-
peitando-se uma série de restrições preestabelecidas, a fim de alcançar um objetivo 
final (TANENBAUM, 2003).
O escalonamento visa otimizar a performance do sistema de acordo com um critério 
estabelecido no escalonamento. A otimização é realizada através da divisão da capacida-
de de processamento entre os diversos recursos de processamento presentes no sistema 
de tempo real. Dividindo-se o processamento, o tempo de resposta é diminuído.
Escalonamento aparece em diversas áreas e de formas variadas. Para um me-
lhor entendimento sobre o conceito de escalonamento, é necessário o entendimen-
to dos seguintes termos:
• Recursos: podem ser entendidos como computadores, dispositivos, apare-
lhos, máquinas, entre outros.
• Tarefa: pode ser vista como um conjunto de operações que juntas completam 
uma rotina.
• Escalonador: é o componente responsável por gerenciar os recursos e esca-
lonar as tarefas para os mesmos. O escalonador é responsável por fornecer a 
solução de escalonamento das tarefas para os recursos disponíveis.
• Escalonamento: o termo “escalonamento” caracteriza o processo de aloca-
ção de recursos às tarefas como um todo. Uma solução de escalonamento 
mostra como o problema de alocação de recursos às tarefas pode ser resol-
vido. As tarefas podem ser escalonadas dinamicamente, em tempo real, ou 
estaticamente, antes de começar a execução da aplicação.
8
9
Em sistemas de tempo real, os métodos de escalonamento devem garantir a priori 
que o sistema cumpra as suas metas temporais, isto é, que o sistema realize todas 
as tarefas no intervalo de tempo definido, ou seja, não pode haver perda de prazo.
Habitualmente, o mecanismo de escalonamento do sistema de tempo real co-
nhece o tempo de execução de todas as tarefas que devem ser realizadas, tanto 
para eventos periódicos, como para eventos esporádicos (ALMEIDA, 2013).
Escalonamento Preemptivo 
e não Preemptivo
Existem duas classificações de escalonamento, que são:
• preemptivo; e
• não preemptivo.
Quando uma tarefa é escalonada para ser executada em um recurso de pro-
cessamento e esta tarefa tem o direito de terminar todas as ações que ela precisa 
fazer, dizemos que o escalonamento é não preemptivo. Quando uma tarefa pode 
ser interrompida no momento de sua execução, isto é, ela não termina todas as 
suas ações, dizemos que o escalonamento é preemptivo. Em outras palavras, se um 
recurso pegar uma tarefa ele terá que a concluir (não preemptivo), ou se o mesmo 
começar a executar uma tarefa e logo depois houver uma substituição de tarefas, 
estamos falando de um escalonamento preemptivo.
Características de Escalonamento
Alguns termos são utilizados para caracterizar o escalonamento. Alguns desses 
termos são:
• Turnaround Time: é o tempo que decorre entre o instante em que a tarefa é 
submetida para o recurso e o instante em que ela é concluída.
• Tempo de Resposta: é o tempo que decorre entre a submissão de um pedido 
(evento) e o início da resposta.
• Deadline: é o tempo no qual um determinado resultado de computação deve 
estar disponível, isto é, o prazo de tempo em que um evento deve ocorrer. 
Sempre que forem especificados deadlines, o critério de escalonamento deve 
garantir que os deadlines são cumpridos, caso não seja possível deve garantir 
que o mínimo número de deadlines seja ultrapassado.
• Prioridade: cada tarefa é associada a uma determinada prioridade que lhe 
garante um tratamento diferenciado por parte do escalonador em relação às 
outras tarefas, isto é, aquela tarefa que possui uma prioridade maior será esca-
lonada para ser executada antes que as outras.
9
UNIDADE Métodos de Escalonamento
Escalonamento de Tarefas
Um escalonamento de tarefas pode ser classificado em dois grupos: 
• Escalonamento Estático; e
• Escalonamento Dinâmico.
Essa classificação baseia-se nas regras de escalonamento quanto à consideração 
do estado atual da aplicação. Por exemplo, no escalonamento estático não são 
consideradas as alterações do estado atual da aplicação. Dessa forma, as tarefas 
são alocadas antes da execução da aplicação e a execução é feita em função do 
escalonamento estabelecido.
O escalonamento dinâmico detecta alterações no estado atual da aplicação e ge-
rencia os recursos com base nas informações atuais da aplicação. As tarefas são alo-
cadas em tempo de execução, considerando-se as informações e condições da apli-
cação. Um método de escalonamento implementa uma política de escalonamento.
Na literatura, as políticas de escalonamento dinâmico mais comuns são:
• FIFO;
• HPF;
• SJF;
• HRN;
• RR.
Na política de escalonamento FIFO (First In First Out), as tarefas são colocadas 
em uma fila ordenada por ordem de chegada. Em FIFO, o escalonamento é feito 
obedecendo-se ao instante de chegada de cada tarefa, ou seja, a tarefa que ocupa 
o primeiro lugar na fila será a próxima a ser escalonada para o recurso. A tarefa 
escalonada recebe o uso do recurso até a sua finalização. Quando uma tarefa que 
estava em execução é finalizada, a próxima tarefa que se encontra na fila é, então, 
escalonada para utilizar o recurso. Este algoritmo possui a característica de ser fácil 
e simples para implementar.
A política de escalonamento HPF (Highest Priority First), também chamado de 
escalonamento por prioridades, é uma variante do escalonamento FIFO. Em HPF, 
as tarefas em espera pelo recurso são organizadas em uma fila obedecendo à sua 
prioridade. Na fila, as posições são ocupadas por tarefas em ordem decrescente 
de prioridade. Com isso, a função de seleção para o escalonamento favorece as 
tarefas consideradas mais importantes.
A política de escalonamento SJF (Shortest Job First) é um caso especial do 
HPF, em que o escalonamento é realizado em função do tempo de execução das 
tarefas. As tarefas em espera pelos recursos são organizadas em uma fila obede-
cendo a seu tempode execução. As tarefas com menores tempos de execução 
são colocadas na frente da fila. Dessa forma, as tarefas com menores tempos de 
10
11
execução são escalonadas primeiro. Este algoritmo é considerado um algoritmo 
ótimo porque realiza uma pequena otimização no tempo de espera, tempo que 
as tarefas devem esperar para ser selecionadas. Este algoritmo também é usado 
essencialmente para escalonamento a longo prazo.
A política de escalonamento HRN (Highest Response-Ratio Next) é uma ver-
são mais eficiente do escalonamento SJF. Em HRN, é realizado um balanceamento 
entre a duração da tarefa e seu tempo de espera, de forma a compensar a espera 
excessiva de tarefas de maior duração. Neste algoritmo, cada tarefa é associada 
com uma prioridade. Os recursos de processamento são alocados para as tarefas 
com as maiores prioridades. Este escalonamento pode ser preemptivo ou não pre-
emptivo. A prioridade é representada por um número inteiro positivo.
A política de escalonamento RR (Round Robin) é uma política de escalonamen-
to simples e elegante. Este algoritmo atribui uma fração de tempo para cada tarefa 
em partes iguais.
Métodos de Escalonamentos de Tarefas
Existem diversos métodos de escalonamento de tarefas na literatura. Nesta se-
ção, são apresentados os métodos de escalonamento estático e os dinâmicos Self-
-Scheduling e Guided.
Algoritmos de Escalonamento Estático 
O algoritmo de escalonamento estático consiste em atribuir as tarefas aos recur-
sos em tempo de compilação. Desta forma, antes de o processamento começar 
cada recurso de processamento já sabe quais tarefas terá que processar.
Para um melhor entendimento, considere as 12 tarefas apresentadas na Figura 
1. Cada tarefa possui um tempo de processamento em minuto - por exemplo, a 
tarefa 1 leva 7 minutos para ser processada. Já a tarefa 8 leva 17 minutos para ser 
processada, enquanto a tarefa 12 leva 17 minutos para ser processada.
Tarefas
5 6 7 8 9 10 1111 432 12
4 9 6 17 33 11 17 2252 17
Figura 1 – Tarefas
Essas tarefas devem ser escalonadas pelos 4 recursos de processamento dispo-
níveis no sistema de tempo real. A Figura 2 ilustra os 4 recursos.
Recurso 1 Recurso 3 Recurso 4Recurso 2
Figura 2 – Recursos de processamento
11
UNIDADE Métodos de Escalonamento
Agora, realizando-se o escalonamento estático utilizando a política FIFO, o es-
calonamento fica conforme ilustrado na Figura 3.
Recurso 1
4
33
7
Recurso 3
6
1
5
Recurso 2
9
11
2
Recurso 4
17
22
17
Figura 3 – Escalonamento estático
Neste escalonamento, o Recurso 1 ficou responsável por processar as tarefas 
7, 4 e 33. O Recurso 2 as tarefas 2, 9 e 11. Já o Recurso 3 as tarefas 5, 6 e 1. 
E por fim, o Recurso 4 ficou com as tarefas 22, 17 e 17. Somando-se as cargas 
de trabalho, é possível perceber que não houve uma boa distribuição de carga de 
trabalho neste escalonamento. A próxima seção apresenta detalhes sobre o desba-
lanceamento de carga causado neste cenário.
Desbalanceamento de Carga
Para este escalonamento, houve uma má distribuição de carga. Observe a Figura 
4, esta figura mostra o total de carga atribuída para cada recurso de processamen-
to. É possível observar que a carga de trabalho entre tais recursos ficou extrema-
mente diferente, provocando uma má distribuição de carga de trabalho.
Recurso 1
4
33
7
Recurso 3
6
1
5
Recurso 2
9
11
2
Recurso 4
17
22
17
Total 44 22 12 56
Figura 4 – Total de carga de trabalho
12
13
Habitualmente, no escalonamento procura-se realizar um bom balanceamento 
de carga, isto é, cada recurso de processamento deve possuir uma carga de tra-
balho justa e igualitária. O Balanceamento de Carga permite balancear as cargas 
de trabalhos entre os processadores, de forma que todos tenham uma carga de 
trabalho justa e igual. Um mau balanceamento de carga entre os recursos de pro-
cessamento pode afetar o desempenho da aplicação.
Neste cenário, é possível perceber que o Recurso 3 irá terminar o processamen-
to primeiro e que o último recurso a terminar será o Recurso 4. Dessa forma, o 
Recurso 3 ficará 34 (56-22) minutos ocioso, isto é, 34 minutos parado, sem nada 
para processar. Ociosidade no processamento não é legal. A ociosidade pode de-
gradar o desempenho da aplicação.
Os algoritmos de escalonamento dinâmico realizam uma melhor distribuição de car-
ga e quase sempre deixando uma ociosidade muito pequena no processamento. A pró-
xima seção apresenta mais detalhes sobre os algoritmos de escalonamento dinâmico.
Algoritmos de Escalonamento Dinâmico
No algoritmo de escalonamento dinâmico, as tarefas são atribuídas para os re-
cursos em tempo de processamento. Assim, o recurso somente sabe quais as tare-
fas que terá que processar na hora da execução.
Habitualmente, os algoritmos de escalonamento dinâmico possuem a caracte-
rística de realizarem uma boa distribuição de carga de trabalho entre os diversos 
recursos de processamento presentes no sistema computacional. Dessa forma, 
os algoritmos dinâmicos permitem não haver ociosidade no processamento, ou a 
ociosidade é quase nula.
Existem diversos algoritmos de escalonamento dinâmico, entre os quais estão:
• Self-Scheduling; e
• Guided.
Os algoritmos Self-Scheduling e Guided são indicados para escalonamentos em 
que o tempo da chegada das tarefas é desconhecido. As tarefas chegam dinamica-
mente. Estes algoritmos implicitamente realizam um balanceamento de carga no 
processamento. As próximas seções apresentam detalhes sobre esses dois algorit-
mos de escalonamento dinâmicos.
Algoritmo Self-Scheduling
O algoritmo de escalonamento Self-Scheduling é usado principalmente para 
lidar com o balanceamento de cargas. Durante o Self-Scheduling, o processador 
ocioso busca a próxima tarefa ou um bloco de tarefas de tamanho definido pelo 
usuário em um pool de tarefas compartilhadas.
Um processo (processo mestre) fica responsável por enviar tarefas para os ou-
tros processos (processos escravos). Quando um escravo termina de processar a 
sua tarefa ou o seu bloco, ele envia uma mensagem para o nó mestre avisando que 
13
UNIDADE Métodos de Escalonamento
terminou a execução e logo em seguida, o nó mestre envia outra tarefa ou bloco 
de tarefa para este escravo, conforme ilustrado na Figura 5.
Recurso 1
Recurso 3Recurso 2 Recurso 4
Send()
Receive()
Send()
Receive()
Send()
Receive()
Send()
Receive()
Figura 5 – Envio e recebimento de dados no algoritmo Self-Scheduling
No Self-Scheduling, as atribuições de cargas são realizadas em passos. Primei-
ro o recurso mestre envia as tarefas para os recursos. Após os recursos terminarem 
a sua tarefa, os mesmos solicitam mais tarefas para o recurso mestre. A Figura 6 
ilustra uma primeira atribuição realizada pelo algoritmo de escalonamento dinâmi-
co Self-Scheduling, considerando as tarefas apresentadas na Figura 1 e os recur-
sos apresentados na Figura 2.
Recurso 1
7
Recurso 3
5
Recurso 2
2
Recurso 4
22
Figura 6 – Primeira atribuição de carga de trabalho pelo algoritmo Self-Scheduling
Nesta atribuição, o primeiro recurso a terminar a sua tarefa é o recurso 2. Após 
terminar a sua tarefa, o recurso 2 solicita mais trabalho para o recurso mestre, que 
o envia logo em seguida. Dessa forma, o escalonamento fica igual ao demonstrado 
na Figura 7.
Recurso 1
7
Recurso 3
5
Recurso 2
4
2
Recurso 4
22
Figura 7 – Segunda atribuição de carga de trabalho realizada pelo algoritmo Self-Scheduling
14
15
O próximo recurso de processamento a terminar a sua tarefa é o recurso 3, que, 
por sua vez, solicita mais tarefa ao recurso mestre, que a envia logo em seguida. 
Agora o escalonamento fica igual ao apresentado na Figura 8.
Recurso 1
7
Recurso 3
5
Recurso 2
4
2
Recurso 4
22
9
Figura 8 – Terceira atribuição de carga de trabalho realizada pelo algoritmo Self-Scheduling
Na próxima atribuição, o recurso que terminar o processamento irá solicitar 
mais tarefas para o recurso mestre, que, por sua vez, enviará mais tarefas ao re-
curso solicitador.
Recurso 1
7Recurso 3
5
Recurso 2
4
2
Recurso 4
22
9
Figura 9 – Atribuição de carga de trabalho realizada pelo algoritmo Self-Scheduling
E assim, o escalonamento segue até que todas as tarefas sejam processadas. A 
Figura 10 ilustra todo o processamento das tarefas pelos recursos de processamento.
Recurso 1
7
Recurso 3
5
Recurso 2
4
2
Recurso 4
22
9
Figura 10 – Atribuição de carga de trabalho realizada pelo algoritmo Self-Scheduling
15
UNIDADE Métodos de Escalonamento
Algoritmo Guided
No algoritmo de escalonamento Guided, a atribuição de tarefas é realizada em 
blocos dinamicamente. O tamanho de bloco é calculado dinamicamente e varia ao 
longo das atribuições durante a execução (TANENBAUM, 2003).
A ideia principal deste algoritmo é iniciar o processamento das iterações do laço 
atribuindo quantias de iterações cujo tamanho começa com n/p e continua a dimi-
nuir até que todas as tarefas estejam atribuídas. Em n/p, n é a quantidade de tarefas 
e p é a quantidade de recurso de processamento.
Assim como o algoritmo Self-Scheduling, o algoritmo Guided implementa um 
balanceamento de carga implicitamente. Este algoritmo também é muito indicado 
em situações em que o tempo da chegada das tarefas não é conhecido.
Conclusões e Resumo da Unidade
Frequentemente, um sistema de tempo real recebe diversos eventos do seu am-
biente, muitas vezes tais eventos devem ser respondidos simultaneamente, em pa-
ralelo. Dessa forma, um sistema de tempo real deve possuir bons mecanismos de 
escalonamentos para escalonar as suas diversas tarefas entre os diversos recursos 
presentes no sistema computacional.
Problemas de escalonamento aparecem em diversas áreas, tais como: industrial, 
comercial, bancária, escolar, entre outras. De um modo geral, o problema de esca-
lonamento é definido como se segue: dados y recursos e z tarefas, é preciso alocar 
os y recursos para as z tarefas, respeitando-se uma série de restrições preestabele-
cidas, a fim de alcançar um objetivo final (AROCA, 2008).
Em um sistema de tempo real, o mecanismo de escalonamento deve:
• escalonar as tarefas para serem executadas pelos recursos;
• manter os recursos de processamento ocupados;
• balancear a utilização dos recursos de processamentos;
• tratar todos os processos de forma igual;
• garantir prioridades quando necessário;
• manter um equilíbrio entre resposta e utilização.
O escalonamento também visa otimizar a performance do sistema de acordo 
com um critério estabelecido no escalonamento. A otimização é realizada através 
da divisão da capacidade de processamento entre os diversos recursos de proces-
samento presentes no sistema de tempo real. Dividindo-se o processamento, o 
tempo de resposta é diminuído.
O mecanismo de escalonamento deve ser composto por:
• Recursos: que podem ser entendidos como computadores, dispositivos, apa-
relhos, máquinas, entre outros.
16
17
• Tarefa: que pode ser vista como um conjunto de operações que juntas com-
pletam uma rotina.
• Escalonador: que é o componente responsável por gerenciar os recursos e 
escalonar as tarefas para os mesmos.
• Escalonamento: o termo “escalonamento” caracteriza o processo de aloca-
ção de recursos às tarefas como um todo.
Um escalonamento pode ser classificado como Preemptivo e não Preemptivo. 
Quando uma tarefa é escalonada para ser executada em um recurso de processa-
mento e esta tarefa tem o direito de terminar todas as ações que ela precisa fazer, 
dizemos que o escalonamento é não preemptivo. Quando uma tarefa pode ser 
interrompida no momento de sua execução, isto é, ela não termina todas as suas 
ações, dizemos que o escalonamento é preemptivo.
Um escalonamento de tarefas pode ser classificado em dois grupos: Escalona-
mento Estático e Escalonamento Dinâmico (TANENBAUM, 2003). No escalo-
namento estático, não são consideradas as alterações do estado atual da aplicação. 
Dessa forma, as tarefas são alocadas antes da execução da aplicação e a execução 
é feita em função do escalonamento estabelecido. O escalonamento dinâmico de-
tecta alterações no estado atual da aplicação e gerencia os recursos com base nas 
informações atuais da aplicação. As tarefas são alocadas em tempo de execução, 
considerando-se as informações e condições da aplicação. Um método de escalo-
namento implementa uma política de escalonamento.
Na literatura, as políticas de escalonamento dinâmico mais comuns são:
• FIFO (First In First Out): as tarefas são colocadas em uma fila ordenada por 
ordem de chegada. Em FIFO, o escalonamento é feito obedecendo-se ao ins-
tante de chegada de cada tarefa, ou seja, a tarefa que ocupa o primeiro lugar 
na fila será a próxima a ser escalonada para o recurso.
• HPF (Highest Priority First), também chamado de escalonamento por priori-
dades, é uma variante do escalonamento FIFO. Em HPF, as tarefas em espera 
pelo recurso são organizadas em uma fila obedecendo à sua prioridade.
• SJF (Shortest Job First) é um caso especial do HPF, em que o escalonamen-
to é realizado em função do tempo de execução das tarefas. As tarefas em 
espera pelos recursos são organizadas em uma fila obedecendo a seu tempo 
de execução. As tarefas com menores tempos de execução são colocadas na 
frente da fila.
• HRN (Highest Response-Ratio Next) é uma versão mais eficiente do esca-
lonamento SJF. Em HRN, é realizado um balanceamento entre a duração 
da tarefa e seu tempo de espera, de forma a compensar a espera excessiva 
de tarefas de maior duração. Neste algoritmo, cada tarefa é associada a 
uma prioridade.
• RR (Round Robin) é um algoritmo de escalonamento simples e elegante. Este 
algoritmo atribui uma fração de tempo para cada tarefa em partes iguais.
17
UNIDADE Métodos de Escalonamento
No algoritmo de escalonamento dinâmico, as tarefas são atribuídas para os re-
cursos em tempo de processamento. Assim, o recurso somente sabe quais as tare-
fas que terá que processar na hora da execução.
Existem diversos algoritmos de escalonamento dinâmicos, entre os quais estão:
• Self-Scheduling; e
• Guided.
O algoritmo de escalonamento Self-Scheduling é usado principalmente para 
lidar com o balanceamento de cargas. Durante o Self-Scheduling, o processador 
ocioso busca a próxima tarefa ou um bloco de tarefas de tamanho definido pelo 
usuário em um pool de tarefas compartilhadas.
No algoritmo de escalonamento Guided, a atribuição de tarefas é realizada em 
blocos dinamicamente. O tamanho de bloco é calculado dinamicamente e varia ao 
longo das atribuições durante a execução.
Muitas vezes, um sistema de tempo real deve responder a eventos simultanea-
mente, isto é, em paralelo. Dessa forma, o sistema de tempo real deve possuir um 
mecanismo de escalonamento, visando escalonar de forma correta as tarefas entre 
os diversos recursos de processamento. Nesta unidade, estudamos os principais 
métodos e algoritmos de escalonamento de tarefa.
18
19
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
 Vídeos
Sistema em Tempo Real - SO
https://youtu.be/gaO9o-ZfMiU
Sistema em Tempo Real
https://youtu.be/HTLZUCkdQbA
 Leitura
Sistemas de Tempo Real – Parte 1
https://goo.gl/K29zuC
Sistemas de Tempo Real
https://goo.gl/4bcgvB
19
UNIDADE Métodos de Escalonamento
Referências
ALMEIDA, M. B. de. Implementando sistemas operacionais de tempo real em 
microcontroladores. 2013. (ebook).
SHAW, A. C. Sistemas e software de tempo real. Porto Alegre: Bookman, 2003.
AROCA, R. V. Análise de sistemas operacionais de tempo real para aplica-
ções de robótica e automação. Dissertação de mestrado. Orientador: Prof. Dr. 
Glauco Augusto de Paula Caurin. Escola de Engenharia de São Carlos. Universi-
dade de São Paulo. São Carlos, 2008. Disponível em: <file:///C:/Users/campo/
Downloads/DissertacaoArocaMestrado2008.pdf>. Acesso em: 26 jul. 2018.
TANENBAUM, A. S. Sistemas operacionais modernos. 2ª edição. São Paulo: 
Pearson Prentice Hall, 2003.
MARTIN, T. Design of real time systems. Prentice-Hall, Inc. Upper Saddle River, 
NJ,USA, 1967.
CEDENO, W.; Laplante, P. A. An overview of real-time operating systems. Jour-
nal of the Association for Laboratoty Automation, 12:40-45.
20
Sistemas de 
Tempo Real
Material Teórico
Responsável pelo Conteúdo:
Prof. Dr. Cléber Silva Ferreira da Luz 
Revisão Textual:
Prof.ª Esp. Kelciane da Rocha Campos
Problemas de Sincronismo e Temporização
• Introdução;
• Condição de Corrida;
• Sincronização Síncrona e Assíncrona;
• Conclusões e resumo da unidade.
 · Apresentar a problemática de sincronização e temporização no desen-
volvimento de sistema de tempo real.
OBJETIVO DE APRENDIZADO
Problemas de Sincronismo e Temporização
Orientações de estudo
Para que o conteúdo desta Disciplina seja bem 
aproveitado e haja maior aplicabilidade na sua 
formação acadêmica e atuação profissional, siga 
algumas recomendações básicas: 
Assim:
Organize seus estudos de maneira que passem a fazer parte 
da sua rotina. Por exemplo, você poderá determinar um dia e 
horário fixos como seu “momento do estudo”;
Procure se alimentar e se hidratar quando for estudar; lembre-se de que uma 
alimentação saudável pode proporcionar melhor aproveitamento do estudo;
No material de cada Unidade, há leituras indicadas e, entre elas, artigos científicos, livros, vídeos 
e sites para aprofundar os conhecimentos adquiridos ao longo da Unidade. Além disso, você 
também encontrará sugestões de conteúdo extra no item Material Complementar, que ampliarão 
sua interpretação e auxiliarão no pleno entendimento dos temas abordados;
Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de discus-
são, pois irão auxiliar a verificar o quanto você absorveu de conhecimento, além de propiciar o 
contato com seus colegas e tutores, o que se apresenta como rico espaço de troca de ideias e 
de aprendizagem.
Organize seus estudos de maneira que passem a fazer parte 
Mantenha o foco! 
Evite se distrair com 
as redes sociais.
Mantenha o foco! 
Evite se distrair com 
as redes sociais.
Determine um 
horário fixo 
para estudar.
Aproveite as 
indicações 
de Material 
Complementar.
Procure se alimentar e se hidratar quando for estudar; lembre-se de que uma 
Não se esqueça 
de se alimentar 
e de se manter 
hidratado.
Aproveite as 
Conserve seu 
material e local de 
estudos sempre 
organizados.
Procure manter 
contato com seus 
colegas e tutores 
para trocar ideias! 
Isso amplia a 
aprendizagem.
Seja original! 
Nunca plagie 
trabalhos.
UNIDADE Problemas de Sincronismo e Temporização
Introdução
Um sistema de tempo real é definido como um sistema computacional que 
recebe estímulo do seu ambiente, processa tais estímulos e posteriormente toma 
uma ação, isto é, gera uma saída.
Muitas vezes, a ação de saída é realizada por dois ou mais recursos (concorrentes), 
o que pode gerar situações indesejáveis, que podem corromper o sistema. Ao realizar 
tarefas concorrentes, deve haver um mecanismo de sincronização entre os recursos.
Por exemplo, uma ação é realizada por dois recursos, Proc. Gravador e o Proc. 
Leitor. O Proc. Gravador é responsável por gravar dados em Buffer. O Proc. Leitor 
é responsável por ler os dados gravados em Buffer. Toda vez que o Proc. Gravador 
produz um dado, ele acorda o Proc. Leitor para consumi-lo e volta a dormir. Após 
o Proc. Leitor ler o dado, ele acorda o Proc. Gravador e volta a dormir, ou seja, 
enquanto um recurso está dormindo, o outro está trabalhando. Habitualmente, os 
recursos, além de compartilhar a tarefa, compartilham a memória, como é o caso 
do Buffer compartilhado (TANENBAUM, 2003).
Proc.
Gravador
Proc.
Leitor
Bu�er
DadosDados
Sincronização
Figura 1 – Proc. Gravador e Proc. Leitor
Neste cenário, é necessário haver uma sincronização entre o Proc. Gravador e 
o Proc. Leitor. O Proc. Leitor não pode consumir o dado caso o Proc. Gravador 
não o gere, e o Proc. Gravador não pode gerar mais dado, caso o Proc. Leitor não 
o consuma. Portanto, deve haver um mecanismo de sincronização entre o Proc. 
Gravador e o Proc. Leitor.
Cenários como esse ocorrem constantemente em sistemas de tempo real; por 
isso, nesta aula, iremos estudar os mecanismos de sincronização. Nesta aula, serão 
abordadas as principais soluções para o problema de sincronização. O cenário 
acima implica uma condição de corrida. A próxima seção apresenta mais detalhes 
sobre a condição de corrida.
8
9
Condição de Corrida
Segundo Tanenbaum (2003), onde dois ou mais processos estão lendo ou gra-
vando um dado compartilhado, localizado no mesmo endereço de memória princi-
pal ou secundária, pode ocorrer uma “condição de corrida”. Essa situação deve ser 
evitada porque pode causar erros que serão difíceis de identificar.
Para exemplificar uma condição de corrida, imagine uma variável chamada cont. 
que contém o valor 10. Essa variável é compartilhada entres os processos A e B. Tan-
to o processo A como o processo B leem o valor de cont. e somam 1 em cont. Uma 
soma é realizada por três operações primitivas, Leitura, Soma e Armazenamento.
O processo A está em execução e lê o conteúdo de cont. Soma 1 ao valor de 
cont., mas nesse momento o processo A perde a prioridade de execução, isto é, 
para de executar. Em seguida, o processo B entra em estado de execução. O pro-
cesso B lê o valor de cont., soma 1 e grava o resultado em cont. Logo após o pro-
cesso B perde a prioridade de execução, deixando o processo A voltar a executar. 
Agora o processo A continua de onde ele parou, ou seja, na escrita, e escreve o 
resultado da soma em cont.
Nesse caso, o que houve com o valor de cont.?
• O valor de cont. está comprometido.
Quando este cenário ocorre, dizemos que temos uma condição de corrida, isto 
é, os recursos disputam entre eles o acesso ao dado. Situações como esta devem 
ser evitadas, pois podem causar erros irreversíveis ao sistema.
Processo A Processo B
Cont.
Figura 2 – Condição de corrida
9
UNIDADE Problemas de Sincronismo e Temporização
Como evitar Condições de Corrida?
Para prevenir este problema e em muitas outras situações envolvendo memória 
compartilhada, arquivos compartilhados, deve-se encontrar uma maneira de proibir 
que mais de 1 processo leia e grave os dados compartilhados ao mesmo tempo. 
Dito em outras palavras, precisamos de uma exclusão mútua – uma maneira de 
certificar que se um processo está utilizando um arquivo ou variável compartilhada, 
os outros processos serão impedidos de fazer a mesma coisa (MARTIN, 1967).
O problema de evitar as condições de corrida também pode ser formulado de 
uma maneira abstrata. Parte de tempo, um processo fica ocupado fazendo compu-
tações internas e outras coisas que não conduzem a condições de corrida. Entre-
tanto, às vezes, um processo pode estar acessando memória compartilhada ou ar-
quivos compartilhados, ou fazer outras coisas críticas que podem levar a condições 
de corrida. Esta parte do programa em que a memória compartilhada é acessada 
é chamada região crítica ou seção crítica. Se pudermos organizar os problemas 
de tal modo que nenhum dos 2 processos jamais esteja em suas regiões críticas ao 
mesmo tempo, poderemos evitar as condições de corrida (TANENBAUM, 2003).
Embora este requisito evite as condições de corrida, isso não é o suficiente 
para ter processos paralelos que cooperam corretamente e efetivamente, utilizan-
do dados compartilhados. Precisamos sustentar quatro condições para ter uma 
boa solução:
1. nenhum dos dois processos pode estar simultaneamente dentro de suas 
regiões críticas;
2. nenhuma suposição pode ser feita sobre as velocidades ou sobre o número 
de recursos de processamento;
3. nenhum processo que executa fora de sua região crítica pode bloquear 
outro processo;
4. nenhum processo deve ter de esperar eternamente para entrar em sua 
região crítica.
Soluções para evitar Condições de Corrida
Existem diversas soluções para evitar condições de corrida, entre as quais estão:
• desativar as interrupções;
• variáveis de bloqueio;
• alternância estrita;• algoritmo de Peterson.
10
11
Desativar as Interrupções
Esta solução consiste em desabilitar todas as suas interrupções de processamento, 
isto é, caso o processo (recurso) entre na região crítica são desabilitadas as interrup-
ções, ou seja, nenhum outro processo é executado. Desabilitar as interrupções signi-
fica que um só processo por vez será executado (MARTIN, 1967).
Um aspecto negativo nesta solução, com as interrupções desabilitadas, é que um 
só processo é executado. Não é uma solução segura, pois um processo pode não 
habilitar novamente suas interrupções e não ser finalizado.
Variável de Bloqueio
Nesta solução, o processo que deseja utilizar uma região crítica atribui um valor 
a uma variável chamada bloqueio. Se a variável está com valor 0 (zero), significa 
que nenhum processo está na região crítica. Se a variável está com valor 1 (um), 
significa que existe um processo na região crítica (TANENBAUM, 2003).
Por exemplo, vamos supor que o processo T1 acesse a região crítica primeiro, ele 
altera o valor de bloqueio para 1. Dessa forma, quando o recurso T2, por exemplo, 
chegar até a região crítica, não poderá acessá-la, porque bloqueio está com 1. Após 
o recurso T1 terminar de acessar a região crítica e alterar o valor de bloqueio para 0, 
o recurso T2, então, poderá acessar a região crítica em questão.
Problema nesta solução: suponha que um processo T1 leia a variável bloqueio 
com valor 0. Antes que o processo T1 possa alterar a variável para o valor 1, um 
processo T2 é escalonado e altera o valor de bloqueio para 1. Quando o processo 
T1 for escalonado novamente, ele altera o valor de bloqueio para 1, e ambos os 
processos estão na região crítica. Dessa forma, esta solução apresenta o mesmo 
problema do exemplo da variável cont. Esta solução é eficiente quando o tempo 
de execução dos dois processos é extremamente grande.
T 1
T 2
Região Crítica
T 1
bloqueio = 0;
bloqueio = 0;
bloqueio = 1;
Figura 3 – Variável de bloqueio
11
UNIDADE Problemas de Sincronismo e Temporização
Alternância Estrita
Esta solução é extremamente simples. Considere o processo A e o processo B. 
A ideia desta solução consiste no seguinte: enquanto um processo A está acessan-
do uma região crítica, o processo B está realizando computações que não têm nada 
a ver com a região crítica em questão. Quando o processo A terminar de acessar a 
região crítica, ele irá realizar outras computações que também não têm nada a ver 
com a região crítica. Enquanto isso, o processo B acessa a região crítica sem ne-
nhum problema. Esta solução consiste nesta alternância entre região crítica e não 
crítica constantemente. A ideia central desta solução é realizar turnos - enquanto 
um processo está na região crítica, o outro processo está a fazer outra coisa. Pos-
teriormente, os dois trocam o turno.
while (TRUE) {
while (turn! = 0) /* espera */;
critical_region();
turn = 1;
noncritical_region();
}
while (TRUE) {
 while (turn! = 1) /* espera */;
 critical_region();
 turn = 0;
 noncritical_region();
}
(a) (b)
Figura 4 – Alternância estrita
Problemas com esta solução: suponha que o Processo B é mais rápido e sai da 
região crítica. Ambos os processos estão fora da região crítica e turn com valor 0. 
O processo A termina antes de executar sua região não crítica e retorna ao início 
do loop. Como o turn está com valor zero, o processo A entra novamente na 
região crítica, enquanto o processo B ainda está na região não crítica. Ao sair da 
região crítica, o processo A atribui o valor 1 à variável turn e entra na sua região 
não crítica. Novamente ambos os processos estão na região não crítica e a variável 
turn está com valor 1. Quando o processo A tenta novamente entrar na região 
crítica, não consegue, pois turn ainda está com valor 1. Assim, o processo A fica 
bloqueado pelo processo B, que NÃO está na sua região crítica, violando a condi-
ção 3 (TANENBAUM, 2003).
Esta solução só funciona quando a computação da região não crítica de ambos 
os processos é externamente grande. Se for pequena, não terá uma sincroniza-
ção entre ambos os recursos, fazendo com que ambos estejam em suas áreas de 
região crítica.
Algoritmo de Peterson
Esta solução combina uma variável de bloqueio com a solução de turnos. O algo-
ritmo de Peterson é mostrado na Figura 5.
12
13
#define FALSE 0
#define TRUE 1
#define N 2
int turn;
int interested [N];
void enter_region(int process);
{
int other;
other = 1 - process;
interested[process] = TRUE;
turn = process;
while (turn == process && interested[other] == TRUE)
}
void leave region(int process)
{
interested[process] = FALSE;
}
/* número de processos */
/* de quem é a vez (turn)? */
/* todo os valores inicialmente 0 (FALSE)*/
/* o process é 0 ou 1 */
/* número dos outros processos */
/* o oposto do processo */
/* mostra que você está interessado */
/* define o sinalizador */
/* declaração nula */
/* processo: quem está saindo */
/* indica saída da região crítica */
Figura 5 – Algoritmo de Peterson
Neste algoritmo, antes de utilizar as variáveis compartilhadas, isto é, antes de os 
processos entrarem na região crítica, cada processo chama a função enter_region() 
com o seu próprio número de processo, 0 ou 1, como parâmetro. Essa chamada 
causará espera, se necessário, até que seja seguro entrar. Depois que terminou de 
trabalhar com as variáveis compartilhadas, o processo chama leave_region() para 
indicar que terminou e permitir que o outro processo entre, se ele, então, quiser.
Inicialmente, nenhum processo está em sua região crítica. Agora, o processo 0 
chama enter_region(). Ele indica o seu interesse, configurando o seu elemento e 
configura turn como 0. Como o processo 1 não está interessado, enter_region() 
retorna imediatamente. Se o processo 1 agora chamar enter_region(), ele ficará 
parado até que o interested[0] torne-se false, evento que só ocorre quando o 
processo 0 chama leave_region() para sair da região crítica.
Agora considere o caso em que os dois processos chamam enter_region() 
quase simultaneamente. Ambos armazenaram o seu número de processo em turn. 
Qualquer que seja o armazenamento feito por último, é este que conta; o primeiro é 
perdido. Suponha que o processo 1 armazene por último, assim turn é 1. Quando 
ambos os processos chegam na declaração while, o processo 0 a executa zero 
vezes e entra em sua região crítica. O processo 1 entra em laço e não entra em 
sua região crítica.
Primitivas Sleep/Wakeup
Todas as soluções apresentadas até agora utilizam a espera ocupada, isto é, 
processos ficam em estados de espera (laços) até que possam utilizar a sua região 
crítica. Esta, por sua vez, é uma boa solução. Todavia, esta solução leva à perda de 
tempo de processamento, uma vez que o processo tem que ficar executando em 
tempo de espera, e também leva a situações inesperadas.
13
UNIDADE Problemas de Sincronismo e Temporização
Para solucionar esse problema de espera, um par de primitivas Sleep e Wakeup 
é utilizado. A primitiva Sleep é uma chamada de sistema que bloqueia o processo 
que a chamou, ou seja, suspende a execução de tal processo até que outro processo 
o “acorde”. A primitiva Wakeup é uma chamada de sistema que “acorda” um 
determinado processo. Ambas as primitivas possuem dois parâmetros: o processo 
sendo manipulado e um endereço de memória para realizar a correspondência 
entre uma primitiva Sleep com sua correspondente Wakeup.
Problema do Produtor e Consumidor
No começo deste estudo, foi colocado um cenário em que havia uma única 
tarefa sendo realizada por dois processos. Neste cenário, o Proc. Grav gerava um 
dado e o armazenava em um Buffer. O Proc. Leitor consumia o dado gerado.
O problema surge quando o produtor quer colocar um novo item no buffer, mas 
este último já está cheio. A solução é o produtor ir dormir para ser acordado quando 
o consumidor remover um ou mais itens. Em contrapartida, se o consumidor quiser 
remover um item do buffer e vir que o buffer está vazio, ele adormecerá até queo 
produtor coloque algo no buffer e o acorde.
Uma primeira solução pode ser obtida utilizando-se uma variável cont. Esta 
variável controla o número de itens presentes no buffer. Se o número máximo de 
itens que o buffer pode armazenar for N, o processo produtor primeiro testará se 
cont é N - se for, o produtor adormecerá; se não, o produtor adicionará um item 
e aumentará cont em uma unidade.
O processo consumidor terá que fazer uma ação semelhante, primeiro testa a 
variável cont para ver se o valor dela é 0. Caso seja, ele irá adormecer; se for dife-
rente de 0, removerá um item e diminuirá em 1 unidade o valor de cont. Cada um 
dos processos também testa para ver se outro deveria estar dormindo e se não, ele 
acorda. A Figura 6 mostra o código do produtor e consumidor.
#define N 100
int count = 0;
void producer (void)
{
 int item;
 while (TRUE) {
 item = produce_item();
 if (count == N)
 sleep();
 insert_item(item);
 count = count + 1;
 if (count == 1)
 wakeup (consumer)
 }
 }
void consumer (void)
{
 int item;
 while (TRUE){
 if (count == 0)
 sleep();
 item = remove_item();
 count = count - 1;
 if (count == N - 1)
 wakeup(producer)
 consume_item(item);
 }
}
Figura 6 – Código do Produtor e Consumidor
14
15
Esta solução não resolve o problema ainda, o acesso à variável cont é irrestrito. 
Imagine a seguinte situação. O buffer está vazio e o consumidor terminou de ler 
cont para ver se ele é 0. Nesse momento, o consumidor para de ser executado 
temporariamente e, em seguida, o produtor começa a ser executado. O produtor 
insere o item no buffer, aumentando cont e avisa que ele agora é 1. Deduzindo 
que cont era apenas 0, e assim o consumidor deveria estar dormindo, o produtor 
chama wakeup para acordar o consumidor.
Infelizmente, o consumidor ainda não está logicamente adormecido, então o 
sinal para acordar é perdido. Quando o consumidor executar da próxima vez, 
ele testará o valor de cont anteriormente lido, verificará que ele é 0 e, então, 
irá dormir. Cedo ou tarde, o produtor encherá o buffer e irá dormir, ambos irão 
dormir eternamente.
Semáforo
Outra solução mais eficaz foi proposta por E. W. Dijkstra (1965). Esta solução 
utiliza uma variável inteira para armazenar o número de sinais wakeups enviados. 
Nesta solução, uma variável semáforo foi introduzida. Um semáforo pode ter valor 
0 quando não há sinal armazenado ou um valor positivo referente ao número de 
sinais armazenados.
Nesta solução, Dijkstra propôs ter duas operações, down e up (generalizações de 
Sleep e Wakeup, respectivamente.). A operação Down em um semáforo verifica 
se o valor é maior que 0. Caso seja, ele diminui o valor, isto é, utiliza um wakeup 
armazenado e simplesmente continua. Caso o valor seja 0, o processo é colocado 
para dormir sem completar o Down, por enquanto. Verificar o valor, alterá-lo e 
possivelmente ir dormir, tudo é feito com uma única e indivisível ação atômica. É 
garantido que uma vez que uma operação de semáforo se iniciou, nenhum outro 
processo acesse o semáforo até que a operação se tenha completado ou tenha sido 
bloqueada. Essa atomicidade é absolutamente essencial para resolver problemas de 
sincronização e para evitar condições de corridas.
A operação Up incrementa o valor do semáforo. Caso um ou mais processos 
estejam dormindo neste semáforo, incapazes de completar uma operação Down 
anterior, um deles é escolhido pelo sistema e autorizado a completar o seu Down. 
Assim, depois de um Up em um semáforo com processos adormecidos nele, o 
semáforo ainda será 0, mas haverá um processo a menos dormindo nele. A ope-
ração de incrementar o semáforo e de acordar um processo também é indivisível. 
Nenhum processo bloqueia utilizando um Up, assim como nenhum processo blo-
queia fazendo Wakeup no modelo anterior. Nesta solução, Dijkstra utiliza nomes P 
e V em vez de Down e Up, respectivamente.
Em outras palavras, um Down verifica se o valor do semáforo é maior do que 0. 
Se for, o semáforo é decrementado. Se o valor for 0, o processo é colocado para 
dormir sem completar sua operação de down. Todas essas ações são chamadas de 
15
UNIDADE Problemas de Sincronismo e Temporização
ações atômicas. Ações atômicas garantem que quando uma operação no semáforo 
está sendo executada, nenhum processo pode acessar o semáforo até que a 
operação seja finalizada ou bloqueada. Um Up incrementa o valor do semáforo, 
fazendo com que algum processo que esteja dormindo possa terminar de executar 
sua operação down.
Resolvendo o problema do Produtor e Consumidor com Semáforo
Para resolver o problema do produtor e consumidor de vez, são utilizados três 
semáforos:
• full;
• empty; e
• mutex.
O full para contar o número de entradas que estão ocupadas, o empty para 
contar o número de entradas que estão livres e o mutex para assegurar que o pro-
dutor e o consumidor não acessem o buffer ao mesmo tempo.
Inicialmente, full é 0, empty é igual ao número de entradas no buffer e mutex 
também é 1. Os semáforos que são inicializados como 1 e utilizados por dois ou 
mais processos para assegurar que só um deles possa entrar em sua região crítica 
ao mesmo tempo são chamados semáforos binários. Caso o processo faça um 
Down imediatamente antes de entrar em sua crítica e um Up somente depois de 
sair dela, a exclusão mútua é garantida. A Figura 7 mostra o código do produtor e 
consumidor com a solução com três semáforos.
# include “prototypes.h”
# define N 100
typedef int semaphore;
semaphore mutex = 1;
semaphore empty = N;
semaphore full = 0;
void producer (void){
 int item;
 while (TRUE) {
 produce_item(&item);
 down (&empty);
 down (&mutex);
 enter_item(item);
 up (&mutex);
 up (&full);
 }
}
void consumer (void){
 int item;
 while (TRUE){
 down (&full);
 down (&mutex);
 remove_item(item);
 up (&mutex);
 up (&empty);
 consume_item(item);
 }
}
Figura 7 – Código do Produtor e Consumidor com semáforo
16
17
Deadlock
Deadlock tipicamente ocorre em compartilhamentos de tarefas. Deadlock é a 
espera de um evento que nunca ocorrerá. Por exemplo, no problema do produtor e 
do consumidor, vamos supor que o produtor durma e não envie o sinal para o con-
sumidor. Neste caso, o consumidor ficará esperando eternamente uma ação que não 
ocorrerá. Quando isso ocorre, dizemos que ocorreu um Deadlock.
Condições para ocorrer o deadlock:
• cada recurso só pode estar alocado a um único processo (exclusão mútua);
• um processo espera por outros recursos, além dos já alocados;
• um recurso não pode ser liberado só porque outros querem;
• um processo espera pelo outro (espera circular).
Deadlock não ocorre somente em um sistema computacional. Um exemplo de 
deadlock pode ser facilmente observado na Figura 8.
Figura 8 – Exemplo de deadlock
Fonte: moodle.stoa.usp.br
Nesta Imagem, temos carros em quatro sentidos diferentes. Os que estão no 
sentido “A” pedem espaço para os que estão no sentido “B”. Mas o pedido é 
negado. E em vez de liberar espaço para os que estão no sentido “A”, os que estão 
no sentido “B” solicitam espaço para os que estão no sentido “C”. Mas o pedido é 
negado. E em vez de liberar espaço para os que estão no sentido “B”, os que estão 
no sentido “C” solicitam espaço para os que estão no sentido “D”. Mas o pedido 
é negado. E em vez de liberar espaço para os que estão no sentido “C”, os que 
estão no sentido “D” solicitam espaço para os que estão no sentido “A”. E assim, 
estamos em um impasse, ou seja, em Deadlock.
17
UNIDADE Problemas de Sincronismo e Temporização
Como evitar Deadlock
Garantir que uma das quatro condições não ocorra:
1. Retirar a exclusão mútua: problemas de sincronismo.
2. Requisitar os recursos antes de utilizá-los. Grande tempo de uso dos recur-
sos. Possibilidade de ocorrer starvation (espera de recursos). Dificuldade 
em determinar os recursos antes de utilizá-los.
3. Retirar o recurso de um processo pode acarretar perda de todo o proces-
samento já realizado. Também pode ocorrer starvation.
4. Evitar a referênciacircular. Forçar o uso de apenas um recurso por vez; se 
precisar de outro, deve liberar o primeiro.
Sincronização Síncrona e Assíncrona
No compartilhamento de tarefas, a comunicação é feita por sincronização síncrona 
ou assíncrona. Síncrona: os recursos estão no mesmo ponto de processamento quan-
do a comunicação é realizada. A Figura 9 ilustra esse procedimento. A Assíncrona 
diz que os recursos estão em pontos de processamento diferentes na comunicação. A 
Figura 10 ilustra esse procedimento.
Recurso 1 Recurso 2
ProcessamentoComunicação
Comunicação
Figura 9 – Comunicação síncrona
18
19
Recurso 2
Recurso 1
Processamento
Comunicação
Figura 10 – Comunicação assíncrona
Conclusões e Resumo da Unidade
Habitualmente, um sistema de tempo real compartilha tarefas, isto é, uma 
tarefa é realizada por dois ou mais recursos. Tal compartilhamento implica uma 
sincronização entre os recursos para não acarretar situações indesejáveis.
O compartilhamento de tarefas, frequentemente, é realizado utilizando-se me-
mória compartilhada, isto é, os processos utilizam o mesmo espaço de memória 
para ler e gravar dados. Segundo Tanenbaum (2003), onde dois ou mais processos 
estão lendo ou gravando um dado compartilhado, localizado no mesmo endereço 
de memória principal ou secundária, pode ocorrer uma “condição de corrida”. Essa 
situação deve ser evitada porque pode causar erros que serão difíceis de identificar.
Para resolver o problema de condição de corrida, é necessário implementar uma 
exclusão mútua – uma maneira de certificar que se um processo está utilizando 
um arquivo ou variável compartilhada, os outros processos serão impedidos de 
fazer a mesma coisa. A parte do programa em que a memória compartilhada é 
acessada é chamada região crítica ou seção crítica. Se pudermos organizar os 
problemas de tal modo que nenhum dos 2 processos jamais esteja em suas regiões 
críticas ao mesmo tempo, poderemos evitar as condições de corrida.
Existem diversas soluções para evitar condições de corrida, entre as quais estão: 
Desativar as interrupções, Variáveis de bloqueio, Alternância estrita e Algo-
ritmo de Peterson.
19
UNIDADE Problemas de Sincronismo e Temporização
Desativar as interrupções: esta solução consiste em desabilitar todas as suas 
interrupções de processamento, isto é, caso o processo (recurso) entre na região 
crítica são desabilitadas as interrupções, ou seja, nenhum outro processo é executa-
do. Desabilitar as interrupções significa que um só processo por vez será executado.
Variável de bloqueio: nesta solução, o processo que deseja utilizar uma região 
crítica atribui um valor a uma variável chamada bloqueio. Se a variável está com 
valor 0 (zero), significa que nenhum processo está na região crítica. Se a variável 
está com valor 1 (um), significa que existe um processo na região crítica.
Alternância estrita: a ideia central desta solução é realizar turnos para acessar 
a região crítica. Enquanto um processo está na região crítica, o outro processo está 
a fazer outra coisa. Posteriormente, os dois trocam o turno.
Algoritmo de Peterson: este algoritmo combina a ideia de turnos com a solu-
ção da variável de bloqueio.
Todas as soluções apresentadas até agora utilizam a espera ocupada, isto é, 
processos ficam em estados de espera (laços) até que possam utilizar a sua região 
crítica. Esta, por sua vez, é uma boa solução. Todavia, esta solução leva à perda de 
tempo de processamento, uma vez que o processo tem que ficar executando em 
tempo de espera, e também leva a situações inesperadas.
Para solucionar esse problema de espera, um par de primitivas Sleep e Wakeup 
é utilizado. A primitiva Sleep é uma chamada de sistema que bloqueia o processo 
que a chamou, ou seja, suspende a execução de tal processo até que outro proces-
so o “acorde”. A primitiva Wakeup é uma chamada de sistema que “acorda” um 
determinado processo.
Outra solução mais eficaz foi proposta por E. W. Dijkstra (1965). Esta solução 
utiliza uma variável inteira para armazenar o número de sinais wakeups enviados. 
Nesta solução, uma variável semáforo foi introduzida. Um semáforo pode ter valor 
0 quando não há sinal armazenado ou um valor positivo referente ao número de 
sinais armazenados.
Deadlock tipicamente ocorre em compartilhamentos de tarefas. Deadlock é a 
espera de um evento que nunca ocorrerá. Por exemplo, no problema do produtor 
e do consumidor, vamos supor que o produtor durma e não envie o sinal para o 
consumidor. Neste caso, o consumidor ficará esperando eternamente uma ação 
que não ocorrerá. Quando isso ocorre, dizemos que ocorreu um deadlock.
Habitualmente, um sistema de tempo real compartilha a realização de uma tare-
fa entre os diversos recursos do sistema computacional. Neste compartilhamento, 
é necessário implementar mecanismos de sincronização, pois o compartilhamento, 
seja ele de recurso ou de memória, pode levar a resultados indesejáveis. Nesta uni-
dade, estudamos todos os aspectos que são envolvidos na problemática da sincro-
nização, bem como suas principais soluções.
20
21
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
 Leitura
Condição de Corrida
https://goo.gl/6Y2SZj
Condições de Corrida, Regiões Críticas eExclusão Mútua
https://goo.gl/sj6sCq
 Vídeos
Sistemas Operacionais Capítulo 3 Deadlock
https://goo.gl/U34Jxs
Dead Lock - Sistemas Operacionais
https://goo.gl/f3CjyT
21
UNIDADE Problemas de Sincronismo e Temporização
Referências
ALMEIDA, M. B. de. Implementando Sistemas Operacionais de Tempo Real 
em Microcontroladores. 2013. (e-book).
AROCA, R. V. Análise de Sistemas Operacionais de Tempo Real para apli-
cações de Robótica e Automação. Dissertação de mestrado. Orientador: Prof. 
Dr. Glauco Augusto de Paula Caurin. Escola de Engenharia de São Carlos. Univer-
sidade de São Paulo. São Carlos, 2008. Disponível em: <file:///C:/Users/cam-
po/Downloads/DissertacaoArocaMestrado2008.pdf>. Acesso em: 26 jul. 2018.
CEDENO, W.; LAPLANTE, P. A. An overview of real-time operating systems. 
Journal of the Association for Laboratoty Automation, 12:40-45.
MARTIN, T. Design of Real Time Systems. Prentice-Hall, Inc. Upper Saddle River, 
NJ, USA, 1967.
SHAW, A. C. Sistemas e Software de Tempo Real. Porto Alegre: Bookman, 2003.
TANENBAUM, A. S. Sistemas Operacionais Modernos. 2ª edição. São Paulo: 
Pearson Prentice Hall, 2003.
22