Sistem As de Tempo Real Far Ines

Sistemas de Tempo Real
Jean-Marie Farines
Joni da Silva Fraga
Rmulo Silva de Oliveira
Departamento de Automao e Sistemas
Universidade Federal de Santa Catarina
Florianpolis, julho de 2000.

Prefcio
A preocupao com o tempo, entre filsofos e matemticos, vem desde a

antigidade. A contribuio mais conhecida desse perodo foi a de Zenon cujo o
paradoxo sobre o tempo e o espao1 levanta questes de continuidade e de atomicidade
no tempo e no espao.
No mundo atual, a rapidez nas decises, nas comunicaes e nas atividades em
geral, se tornou um dos paradigmas dominantes na Sociedade da Informao. Utiliza-se
cada vez mais o termo Tempo Real em diversas situaes, as vezes com propriedade,
outras apenas com objetivo comercial. De fato, o tempo est sempre presente em todas
as atividades mesmo que no seja de forma explcita; as atividades computacionais
seguem tambm essa regra.
Um nmero crescente de aplicaes de importncia na sociedade atual apresentam
comportamentos definidos segundo restries temporais. Alguns exemplos dessas
aplicaes se encontram no controle de plantas industriais, de trfego areo ou
ferrovirio, nas telecomunicaes, na eletrnica embarcada em carros e avies, na
robtica, em sistemas de multimdia, etc. Essas aplicaes que apresentam a
caracterstica adicional de estarem sujeitas a restries temporais, so agrupados no que
normalmente identificado como Sistemas de Tempo Real.
A maior parte dos sistemas de tempo real so projetados e implementados com
ferramentas convencionais de verificao e de implementao. Por exemplo, na prtica
corrente, so usadas linguagens de alto nvel com construes no deterministas ou
mesmo linguagens de baixo nvel, mas sem a preocupao de tratar o tempo de uma
forma mais explcita o que torna difcil a garantia da implementao das restries
temporais. Os sistemas operacionais e suportes de tempo de execuo geralmente
utilizados apresentam mecanismos para implementar escalonamentos dirigidos a
prioridades; estas nunca refletem as restries temporais definidas para essas
aplicaes. Na prtica usual, a importncia em termos das funcionalidades presentes
nessas aplicaes so determinantes nas definies dessas prioridades; o que pode ser
contestado, pois os possveis graus de importncia de funes em uma aplicao nem
sempre se mantm na mesma ordem relativa durante todo o tempo de execuo desta.
Essas prticas tm permitido resolver de forma aceitvel e durante muito tempo certas
classes de problemas de tempo real nas quais as exigncias de garantia sobre as
restries temporais no so to estritas.
Entretanto, as necessidades de segurana num nmero cada vez maior de aplicaes
e a ligao dessa com a correo temporal desses sistemas colocam em xeque as
metodologias e ferramentas convencionais, sob pena de perdas em termos financeiros,
1
Conhecido como paradoxo de Aquiles e da tartaruga que, na essncia, mostra uma
mquina - Aquiles - que pode realizar clculos infinitos num tempo finito.
iii
essas duas abordagens ao visto de exemplos ilustrativos e um ltimo captulo de

concluses e perspectivas.
O primeiro captulo apresenta uma introduo geral ao problema da programao
em tempo real. Nesse, estabelecido o entendimento da noo de tempo real,
destacando a terminologia e os conceitos a serem usados em particular os de correo
temporal e de previsibilidade. Em seguida, discutida a problemtica de tempo real
considerando as aplicaes de tempo real mais comuns.
No livro so caracterizados os segundo e terceiro captulos como definindo uma
linha metodolgica para a programao de aplicaes de tempo real, na qual
priorizado a determinao de uma escala de execuo de tarefas que possa atender as
restries de tempo da aplicao (abordagem assncrona).
O segundo captulo concentra sua ateno sobre a conceituao e os algoritmos de
escalonamento de tempo real, essenciais na garantia da correo temporal dos sistemas
de tempo real. Inicialmente conceitos, objetivos, hipteses e mtricas so claramente
apresentados no sentido de introduzir o problema de escalonamento. A seguir,
diferentes classes de problemas aplicveis em diferentes contextos de aplicao so
tratadas em suas solues algortmicas.
O terceiro captulo discute principalmente aspectos de sistemas operacionais e de
ncleos cujo propsito suportar aplicaes de tempo real. Na abordagem apresentada
no captulo anterior, os requisitos temporais so atendidos com algoritmos de
escalonamento adequados mas deve levar em conta tambm as funcionalidades de
suportes de tempo de execuo no sentido de permitir a previsibilidade ou pelo menos
um desempenho satisfatrio da aplicao. Entre os aspectos desenvolvidos est a
definio da funcionalidade mnima que vai caracterizar os ncleos de tempo real a
partir de demandas especficas da aplicao. Finalmente, so apresentados e discutidos
padres, solues comerciais existentes, prottipos notrios presentes na literatura.
No quarto captulo, apresentada a abordagem alternativa na programao de
sistemas de tempo real fundamentada na chamada hiptese sncrona e num conjunto de
ferramentas integradas de especificao, verificao e implementao. Essa abordagem
particularmente adaptada para sistemas de tempo real concebidos dentro de uma viso
de sistemas reativos e que se baseia na hiptese da instantaneidade da reao do
sistema a eventos externos. Os conceitos, ferramentas e metodologias relacionadas com
essa abordagem so apresentados nesse captulo, particularizando nas descries os
mesmos para o modelo de programao usado na linguagem sncrona Esterel.
O quinto captulo confronta as abordagens apresentadas anteriormente (a
assncrona e a sncrona). Essas duas abordagens so utilizadas em exemplos de
aplicao do mundo real. Inicialmente dado destaque para as linhas metodolgicas
que permitem projetar e implementar essas aplicaes nesses dois casos. A seguir so
discutidos vantagens e limitaes das duas abordagens e a adequao dessas em
diferentes situaes. No ultimo captulo, concluses, desafios e perspectivas
complementam esse livro, apontando para os caminhos futuros de evoluo da rea de
Sistemas de Tempo Real.
ndice
1 Introduo sobre o Tempo Real . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1 Os Sistemas de Tempo Real . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 O Tempo: Diferentes Interpretaes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Conceituao Bsica e Caracterizao de um Sistema de Tempo Real . .3
1.4 A Previsibilidade nos Sistemas de Tempo Real . . . . . . . . . . . . . . . . . . . 5
1.5 Classificao dos Sistemas de Tempo Real . . . . . . . . . . . . . . . . . . . . . . . 7
1.6 O Problema Tempo Real e Abordagens para a sua Soluo . . . . . . . . . . 8
2 O Escalonamento de Tempo Real . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1 Introduo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Modelo de Tarefas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1 Restries Temporais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.2 Relaes de Precedncia e de Excluso . . . . . . . . . . . . . . . . . . . . . 15
2.3 Escalonamento de Tempo Real . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.1 Principais Conceitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.2 Abordagens de Escalonamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.3 Teste de Escalonabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4 Escalonamento de Tarefas Peridicas . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4.1 Escalonamento Taxa Monotnica [LiL73] . . . . . . . . . . . . . . . . . . . 22
2.4.2 Escalonamento "Earliest Deadline First" (EDF) [LiL73] . . . . . . . 24
2.4.3 Escalonamento "Deadline" Monotnico [LeW82] . . . . . . . . . . . . . 25
2.5 Testes de Escalonabilidade em Modelos Estendidos . . . . . . . . . . . . . . . .26
2.5.1 "Deadline" Igual ao Perodo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.5.2 "Deadline" Menor que o Perodo . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.5.3 Deadline Arbitrrio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
vi ndice
2.6 Tarefas Dependentes: Compartilhamento de Recursos . . . . . . . . . . . . . . 35

2.6.1 Protocolo Herana de Prioridade . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.6.2 Protocolo de Prioridade Teto (Priority Ceiling Protocol) . . . . . . 41
2.7 Tarefas Dependentes: Relaes de Precedncia . . . . . . . . . . . . . . . . . . . 44
2.8 Escalonamento de Tarefas Aperidicas . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.8.1 Servidores de Prioridade Fixa [LSS87, SSL89] . . . . . . . . . . . . . . . 49
2.8.2 Consideraes sobre as Tcnicas de Servidores . . . . . . . . . . . . . . . 58
2.9 Concluso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58
3 Suportes para Aplicaes de Tempo Real . . . . . . . . . . . . . . . . . . . . . . . . . . 61

3.1 Introduo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.2 Aspectos Funcionais de um Sistema Operacional Tempo Real . . . . . . . 62
3.2.1 Tarefas e "Threads" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.2.2 Comunicao entre Tarefas e "Threads" . . . . . . . . . . . . . . . . . . . . 65
3.2.3 Instalao de Tratadores de Dispositivos . . . . . . . . . . . . . . . . . . . . 66
3.2.4 Temporizadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.3 Aspectos Temporais de um Sistema Operacional Tempo Real . . . . . . . . 69
3.3.1 Limitaes dos Sistemas Operacionais de Propsito Geral . . . . . . 70
3.3.2 Chaveamento de Contexto e Latncia de Interrupo . . . . . . . . . . .73
3.3.3 Relao entre Mtricas e Tempo de Resposta . . . . . . . . . . . . . . . . .75
3.3.4 Tempo de Execuo das Chamadas de Sistema . . . . . . . . . . . . . . . 78
3.3.5 Outras Mtricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
3.3.6 Abordagens de Escalonamento e o Sistema Operacional . . . . . . . . 82
3.4 Tipos de Suportes para Tempo Real . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
3.4.1 Suporte na Linguagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
3.4.2 "Microkernel" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
3.4.3 Escolha de um Suporte de Tempo Real . . . . . . . . . . . . . . . . . . . . . 85
3.5 Exemplos de Suportes para Tempo Real . . . . . . . . . . . . . . . . . . . . . . . . . 86
3.5.1 Posix para Tempo Real . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
3.5.2 Escalonamento no Unix SVR4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
3.5.3 Escalonamento no Solaris 2.x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
vii
3.5.4 ChorusOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
3.5.5 Neutrino e QNX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
3.5.6 Linux para Tempo Real . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .100
3.6 Concluso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .104
4 O Modelo de Programao Sncrona para os Sistemas de Tempo Real . . 105

4.1 Introduo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
4.2 Princpios Bsicos do Modelo de Programao Sncrono da Linguagem
Esterel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .107
4.3 O Estilo de Programao da Linguagem Esterel . . . . . . . . . . . . . . . . . . . 108
4.3.1 Programando num estilo imperativo . . . . . . . . . . . . . . . . . . . . . . . . 108
4.3.2 Declarao de interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
4.3.3 Declarao de variveis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .112
4.3.4 Os diferentes tipos de preempo . . . . . . . . . . . . . . . . . . . . . . . . . . 112
4.3.5 Mecanismo de exceo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
4.3.6 Testes de presena . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
4.3.7 Mdulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
4.3.8 O conceito de tempo no modelo de programao . . . . . . . . . . . . . . 116
4.4 Um exemplo ilustrativo do estilo de programao . . . . . . . . . . . . . . . . . 116
4.5 A assncronia na linguagem Esterel: a execuo de tarefas externas . . . 118
4.6 O Ambiente de Ferramentas Esterel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
4.7 Implementaes de programas em Esterel . . . . . . . . . . . . . . . . . . . . . . . .126
4.8 Discusso sobre o modelo e a linguagem . . . . . . . . . . . . . . . . . . . . . . . . 127
4.9 Concluso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .129
5 Aplicao das Abordagens Assncrona e Sncrona . . . . . . . . . . . . . . . . . . . 131

5.1 Aplicao com Abordagem Assncrona . . . . . . . . . . . . . . . . . . . . . . . . . 131
5.1.1 Descrio do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
5.1.2 Definio das Tarefas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
5.1.3 Modelo de Tarefas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
5.1.4 Teste de Escalonabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
5.1.5 Programao Usando RT-Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
viii ndice
5.2 Aplicao com Abordagem Sncrona . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

5.3 Abordagem Assncrona versus Abordagem Sncrona: Elementos para
uma Comparao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
5.4 Concluso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .153
6 Tendncias Atuais em Sistemas de Tempo Real . . . . . . . . . . . . . . . . . . . . . 155

6.1 Abordagem Sncrona . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
6.2 Abordagem Assncrona . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
ANEXO A - Extenses em Esquemas de Prioridade Dinmica . . . . . . . . . . 165

A.1 Testes para Escalonamentos com Prioridades Dinmicas . . . . . . . . . . . 165
A.1.1 Deadline igual ao perodo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
A.1.2 Deadlines Arbitrrios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
A.2 Compartilhamento de Recursos em Polticas de Prioridade Dinmica . 169
A.2.1 Poltica de Pilha (Stack Resource Policy) . . . . . . . . . . . . . . . . . . . 169
A.3 Escalonamento de tarefas aperidicas com polticas de prioridade
dinmica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
A.3.1 Servidores de Prioridade Dinmica [SpB96] . . . . . . . . . . . . . . . . . 174
ANEXO B Sistemas Operacionais de Tempo Real na Internet . . . . . . . . . 177
ANEXO C - Sintaxe e Semntica da Linguagem Esterel . . . . . . . . . . . . . . . . 183
C.1 Mdulos e submdulos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
C.2 Declarao de interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
C.2.1 Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
C.2.2 Sinais e Sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
C.2.3 Variveis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
C.2.4 Expresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
C.3 Construes do corpo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
C.4 Instanciao de mdulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
C.5 A execuo de tarefa externa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Bibliografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Lista de Figuras
Figura 1.1 Sistema de tempo real . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Figura 2.1 Ativaes de uma tarefa peridica . . . . . . . . . . . . . . . . . . . . . . . . . 14
Figura 2.2 Ativaes de uma tarefa aperidica . . . . . . . . . . . . . . . . . . . . . . . . 14
Figura 2.3 Abordagens de escalonamento de tempo real . . . . . . . . . . . . . . . . . 20
Figura 2.4 Tipos de testes de escalonabilidade . . . . . . . . . . . . . . . . . . . . . . . . .20
Figura 2.5 Escala RM produzida a partir da tabela 2.1 . . . . . . . . . . . . . . . . . . 24
Figura 2.6 Escalas produzidas pelo (a) EDF e (b) RM . . . . . . . . . . . . . . . . . . . 25
Figura 2.7 Escala produzida pelo DM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Figura 2.8 Maior perodo ocupado da tarefa T3 . . . . . . . . . . . . . . . . . . . . . . . . 35
Figura 2.9 Inverso de prioridades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Figura 2.10 Exemplo do uso do PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Figura 2.11 Bloqueio transitivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Figura 2.12 Exemplo do uso do PCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Figura 2.13 Uma aplicao constituda por duas atividades . . . . . . . . . . . . . . 46
Figura 2.14 Servidora de "background" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Figura 2.15 Algoritmo "polling server" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Figura 2.16 Algoritmo "deferrable server" . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Figura 2.17 Algoritmo "sporadic server" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Figura 2.18 Servidor SS e RM usados em carga aperidica com Di=Min i . . . 57
Figura 2.19 Servidor SS e DM usados em carga aperidica com Di<Min i . . . 57
Figura 3.1 Estados de uma "thread" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Figura 3.2 Formas do "kernel" lidar com interrupes de hardware . . . . . . . . 75
Figura 3.3 Tempo de resposta de um tratador simples . . . . . . . . . . . . . . . . . . . 77
Figura 3.4 Comportamento de tratador complexo em "kernel" que sofre
interrupes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Figura 3.5 Latncia medida em 40 oportunidades consecutivas . . . . . . . . . . . 81
Figura 3.6 Distribuio das latncias medidas conforme sua durao . . . . . . . 81
x Lista de Figuras
Figura 3.7 Tipos de suportes para aplicaes de tempo real . . . . . . . . . . . . . . 84

Figura 3.8 Estratificao de servios em um sistema . . . . . . . . . . . . . . . . . . . . 85
Figura 4.1 Autmato para a especificao ABRO . . . . . . . . . . . . . . . . . . . . . . 108
Figura 4.2 Tela Principal do Ambiente XEVE . . . . . . . . . . . . . . . . . . . . . . . . . 124
Figura 4.3 Tela de Ajuda do Ambiente XEVE . . . . . . . . . . . . . . . . . . . . . . . . . 125
Figura 4.4 Tela de Resultados do Ambiente XEVE . . . . . . . . . . . . . . . . . . . . . 125
Figura 5.1 Diagrama do nvel de navegao . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Figura 5.2 Esquema da Regulao de Nvel de um Reservatrio . . . . . . . . . . 144
Figura 5.3 Arquitetura do Sistema de Controle . . . . . . . . . . . . . . . . . . . . . . . . 144
Figura 5.4 Representao do Mdulo CONSUMO_SEGURO . . . . . . . . . . . 149
Figura A.1 Nveis de preempo no EDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . .170
Figura A .2 Exemplo de escala com SRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Figura A.3 Algoritmo "Dynamic Sporadic Server" . . . . . . . . . . . . . . . . . . . . . 175
Figura A.4 "Dynamic Sporadic Server" com capacidade menor . . . . . . . . . . . 176
xi
Lista de Tabelas
Tabela 2.1 Utilizao de tarefas peridicas . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Tabela 2.2 Exemplo da figura 2.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29
Tabela 2.3 Exemplo da figura 2.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31
Tabela 2.4 Tarefas com "deadlines" arbitrrios . . . . . . . . . . . . . . . . . . . . . . . . 34
Tabela 2.5 Exemplo do uso do PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Tabela 2.6 Exemplo do uso do PCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Tabela 2.7 Utilizao dos servidores DS, PE e SS . . . . . . . . . . . . . . . . . . . . . . 56
Tabela 5.1 Definio das tarefas, verso inicial . . . . . . . . . . . . . . . . . . . . . . . . 136
Tabela 5.2 Definio das tarefas, verso final . . . . . . . . . . . . . . . . . . . . . . . . . 138
Anexo A - Tabela I - Exemplo da figura 2.7 (captulo 2) . . . . . . . . . . . . . . . . . . 168
Captulo 1
Introduo sobre o Tempo Real
Esse captulo visa esclarecer o entendimento de tempo real dos autores, definir
conceitualmente os Sistemas de Tempo Real e apresentar os problemas e desafios que
lhes so relacionados.
1.1 Os Sistemas de Tempo Real
Na medida em que o uso de sistemas computacionais prolifera na sociedade atual,

aplicaes com requisitos de tempo real tornam-se cada vez mais comuns. Essas
aplicaes variam muito em relao complexidade e s necessidades de garantia no
atendimento de restries temporais. Entre os sistemas mais simples, esto os
controladores inteligentes embutidos em utilidades domsticas, tais como lavadoras de
roupa e videocassetes. Na outra extremidade do espectro de complexidade esto os
sistemas militares de defesa, os sistemas de controle de plantas industriais (qumicas e
nucleares) e o controle de trfego areo e ferrovirio. Algumas aplicaes de tempo real
apresentam restries de tempo mais rigorosas do que outras; entre esses, encontram-se
os sistemas responsveis pelo monitoramento de pacientes em hospitais, sistemas de
superviso e controle em plantas industriais e os sistemas embarcados em robs e
veculos (de automveis at avies e sondas espaciais). Entre aplicaes que no
apresentam restries to crticas, normalmente, so citados os vdeogames, as
teleconferncias atravs da Internet e as aplicaes de multimdia em geral. Todas essas
aplicaes que apresentam a caracterstica adicional de estarem sujeitas a restries
temporais, so agrupados no que usualmente identificado como Sistemas de Tempo
Real.
Metodologias e ferramentas convencionais so usadas, em uma prtica corrente, no
projeto e implementao de sistemas de tempo real. A programao dessas aplicaes
feita com o uso de linguagens de alto nvel, em geral eficientes, mas com construes
no deterministas ou ainda, com linguagens de baixo nvel. Em ambos os casos, sem a
preocupao de tratar o tempo de uma forma mais explcita, o que torna difcil a
garantia de implementao das restries temporais. Os sistemas operacionais ou
ncleos de tempo real, que gerenciam interrupes e tarefas e permitem a programao
de temporizadores e de "timeout", so para muitos projetistas as ferramentas suficientes
para a construo de sistemas de tempo real. Embora esses suportes apresentem
mecanismos para implementar escalonamentos dirigidos a prioridades, essas
prioridades nunca refletem as restries temporais definidas para essas aplicaes.
2 1. Introduo sobre o Tempo Real
Essas prioridades so determinadas usualmente a partir da importncia das

funcionalidades presentes nessas aplicaes; o que no leva em conta, por exemplo, que
o grau de importncia relativa de uma funo da aplicao nem sempre se mantm igual
durante todo o tempo de execuo desta.
Essas prticas correntes tm permitido resolver de forma aceitvel e durante muito
tempo certas classes de problemas de tempo real nas quais as exigncias de garantia
sobre as restries temporais no so to rigorosas. Entretanto essas tcnicas e
ferramentas convencionais apresentam limitaes. Por exemplo, a programao em
linguagem "Assembly" produz programas com pouca legibilidade e de manuteno
complexa e cuja a eficincia est intimamente ligada experincia do programador.
Acrescenta-se a essas limitaes, as dificuldades advindas do uso de ferramentas e
metodologias que permitem a verificao apenas da correo lgica nessas aplicaes.
Em conseqncia, o software obtido dessa forma considerado altamente imprevisvel
e sem garantia de um comportamento correto durante todo seu tempo de uso; situaes
perigosas podem resultar da utilizao de software assim produzido.
Alm do aspecto dessas ferramentas convencionais no tratarem da correo
temporal, um outro fato que influi sobre o que se pode considerar como prtica corrente
o desconhecimento do que seria tempo real. A grande maioria dos sistemas de tempo
real vem sendo projetada e implementada at hoje a partir de uma viso errada de que
tempo real simplesmente reduzido a uma questo de melhoria no desempenho
[Sta88].
As exigncias de segurana num nmero cada vez maior de aplicaes e a ligao
dessa com a correo temporal desses sistemas colocam em xeque as metodologias e
ferramentas convencionais, sob pena de perdas em termos financeiro, ambiental ou
humano. Essas aplicaes necessitam de algoritmos, de suportes computacionais e de
metodologias que ultrapassam as caractersticas das ferramentas at ento utilizadas e
lanam novos desafios para os projetistas desse tipo de sistemas. Nas aplicaes mais
crticas, so assumidos situaes extremas e pessimistas com hipteses de carga de pico
e cenrios de falhas, sendo que mesmo nestas situaes extremas, de pior caso, o
sistema de tempo real deve manter as restries temporais impostas pelo seu ambiente.
H quem considera que a famosa lei de Murphy o paradigma pessimista ideal a ser
considerado para as anlises de Sistemas de Tempo Real com restries temporais
crticas [But97].
Antes de apresentarmos abordagens para que se garanta a correo temporal em
sistemas de tempo real necessrio que se entenda o conceito de tempo.
1.2 O Tempo: Diferentes Interpretaes
A noo de tempo em sistemas informticos difcil de ser expressa, podendo

assumir diferentes enfoques. Na seqncia abaixo, so apresentados alguns desses
enfoques com as suas respectivas interpretaes que sero utilizadas nesse livro
1.3 Conceituao Bsica e Caracterizao de um Sistema de Tempo Real 3
[Ray91], [Mot92], [Kop92a], [Jos91]. Alguns desses enfoques so colocados em

contraposio:
Tempo na Execuo considerado como um recurso a ser gasto durante a execuo
de um programa como outros recursos fsicos ou lgicos e o Tempo na
Programao visto como uma grandeza a ser manipulada pelo programa como
outros tipos de variveis; na execuo o tempo intervm de forma implcita,
enquanto na programao, ele pode ser visto de forma implcita ou explcita;
Tempo Lgico que definido a partir de relaes de precedncia entre eventos, o
que permite o estabelecimento de ordens causais sobre um conjunto de eventos e o
Tempo Fsico que um tempo mtrico que permite expressar quantitativamente a
distncia entre eventos e estabelecer ordens totais entre eventos;
Tempo Denso que segue a natureza uniforme e continua do tempo fsico e
isomorfo ao conjunto dos reais e o Tempo Discreto, uma simplificao geralmente
aceita do anterior, porm isomorfo em relao ao conjunto dos naturais positivos;
Tempo Global, noo abstrata que permite ao usurio de um sistema distribudo ter
acesso a um instante de referncia nico em qualquer parte do sistema e o Tempo
Local observvel localmente nos diferentes ns de um sistema distribudo; tanto o
tempo global quanto o tempo local podem ser fsicos ou lgicos;
Tempo Absoluto com referncia estabelecida a partir de um evento global e o
Tempo Relativo tendo como referncia um evento local; o tempo absoluto sempre
global, enquanto o tempo relativo sempre local.
Dependendo dos tipos de sistemas e das abordagens usadas na descrio de seus
comportamentos, alguns desses enfoques podem ser assumidos para representar a noo
de tempo. O que relevante num sistema de tempo real que o tempo, de forma
implcita ou explcita, um componente essencial e intrnseco no comportamento deste.
1.3 Conceituao Bsica e Caracterizao de um Sistema

de Tempo Real
Excetuando sistemas computacionais normalmente identificados como Sistemas

Transformacionais que calculam valores de sada a partir de valores de entrada e depois
terminam seus processamentos como ocorre, por exemplo, com compiladores,
programas de engenharia econmica e programas de clculo numrico , uma grande
parte dos sistemas computacionais atuais interagem permanentemente com os seus
ambientes. Entre esses, distingue-se os chamados Sistemas Reativos que reagem
enviando respostas continuamente estmulos de entrada vindos de seus ambientes.
Sistemas de tempo real de uma forma geral se encaixam neste conceito de sistemas
reativos:
Um Sistema de Tempo Real (STR) um sistema computacional que deve reagir a

estmulos oriundos do seu ambiente em prazos especficos.
O atendimento desses prazos resulta em requisitos de natureza temporal sobre o
comportamento desses sistemas. Em conseqncia, em cada reao, o sistema de tempo
real deve entregar um resultado correto dentro de um prazo especfico, sob pena de
ocorrer uma falha temporal. O comportamento correto de um sistema de tempo real,
portanto, no depende s da integridade dos resultados obtidos (correo lgica ou
correctness) mas tambm dos valores de tempo em que so produzidos (correo
temporal ou timeliness). Uma reao que ocorra alm do prazo especificado pode ser
sem utilidade ou at representar uma ameaa. Descries semelhantes de sistemas de
tempo real so encontradas na literatura da rea ([Aud93], [You82], [StR88], [StR90],
[Jos91], [Kop92b], [LeL90] e [But97]).
A maior parte das aplicaes tempo real se comportam ento como sistemas
reativos com restries temporais. A reao dos sistemas de tempo real aos eventos
vindo do ambiente externo ocorre em tempos compatveis com as exigncias do
ambiente e mensurveis na mesma escala de tempo. A concepo do sistema de tempo
real diretamente relacionada com o ambiente no qual est relacionado e com o
comportamento temporal do mesmo. Na classe de Sistema de Tempo Real na qual se
encontram os sistemas embutidos ("Embedded Systems") e os sistemas de superviso e
controle, distingue-se entre o Sistema a Controlar, o Sistema Computacional de
Controle e o Operador. O Sistema a Controlar e o Operador so considerados como o
Ambiente do Sistema Computacional. A interao entre os mesmos ocorre atravs de
interfaces de instrumentao (compostas de sensores e atuadores) e da interface do
operador. A figura 1.1 representa esse tipo de Sistema de Tempo Real.
Sistema
Interface de Sistema Interface
a Homem- Operador
Instrumentao Computacional
Controlar Mquina
de Controle
Figura 1.1: Sistema de Tempo Real
Existem tambm situaes nas quais as restries temporais no so impostas pelo

comportamento dinmico de um eventual Sistema a Controlar mas pelas exigncias dos
servios a serem oferecidos a um usurio humano ou computacional (p.ex. no caso do
1.4 A Previsibilidade nos Sistemas de Tempo Real 5
manuseio ou da apresentao de vdeos em sistemas multimdias). Nesses casos utiliza-

se a noo de Servio de Tempo Real como sendo um servio que deve ser oferecido
dentro de restries de tempo impostas por exigncias externas ao prprio Sistema
Computacional [DEL91]. Ento, numa generalizao podemos assumir:
Um Sistema de Tempo Real deve ser ento capaz de oferecer garantias de correo
temporal para o fornecimento de todos os seus servios que apresentem restries
temporais.
1.4 A Previsibilidade nos Sistemas de Tempo Real
Uma das crenas mais comuns que o problema de tempo real se resolve pelo
aumento da velocidade computacional. A rapidez de clculo visa melhorar o
desempenho de um sistema computacional, minimizando o tempo de resposta mdio de
um conjunto de tarefas, enquanto o objetivo de um clculo em tempo real o
atendimento dos requisitos temporais de cada uma das atividades de processamento
caracterizadas nesses sistemas [Sta88]. Ter um tempo de resposta curto, no d
nenhuma garantia que os requisitos temporais de cada processamento no sistema sero
atendidos. O desempenho mdio no tem importncia para o comportamento de um
sistema composto de diversas atividades com restries temporais. Mais do que a
rapidez de clculo, para os sistemas de tempo real, importa o conceito de
previsibilidade.
Um sistema de tempo real dito ser previsvel ("predictable") no domnio lgico e
no domnio temporal quando, independentemente de variaes ocorrendo nvel de
hardware (i.e. desvios do relgio), da carga e de falhas, o comportamento do sistema
pode ser antecipado, antes de sua execuo. Para se poder prever a evoluo de um
sistema de tempo real e garantir dentro de certos limites as suas restries temporais,
necessrio definir um conjunto de hipteses sobre o comportamento do ambiente
externo no que diz respeito carga e as falhas:
A hiptese de carga: ela determina o que corresponde a carga computacional de
pico (carga mxima) gerada pelo ambiente em um intervalo mnimo de tempo,
entre cada reao do sistema de tempo real. Mesmo eventos que ocorrem
esporadicamente como os que levam a situaes crticas (p.ex. alarme em planta
nuclear) devem ser levados em conta para determinar essa carga computacional;
A hiptese de falhas: ela descreve os tipos e freqncias de falhas com os quais o
sistema deve conviver em tempo de execuo, continuando a atender os seus
requisitos funcionais e temporais.
Consequentemente, de um ponto de visto rigoroso, para se assumir a previsibilidade
de um sistema (ou de um servio) de tempo real, precisa-se conhecer a priori o
comportamento de um sistema, levando-se em conta a pior situao de carga ocorrendo,
simultaneamente, com as hipteses de falhas. Como se v necessrio nesse caso que
as hipteses de carga e de falha que descrevem o comportamento do ambiente sejam

definidas de forma realista, o que nem sempre uma tarefa simples.
Mas a garantia de previsibilidade no depende s da carga computacional ativada
pelo ambiente e das hipteses de falhas. Um conjunto de fatores ligados a arquitetura de
hardware, ao sistema operacional e as linguagens de programao so tambm
importantes. Ou seja, os tempos gastos, no pior caso, na execuo de cdigos da
aplicao (tempo de computao) e em funes de suportes devem ser perfeitamente
conhecidos ou determinados previamente. Esses tempos limites so necessrios nas
anlises e verificaes do comportamento temporal do sistema de tempo real.
Se consideramos os tempos de computao dos cdigos de aplicao envolvidos,
muitas das construes nas linguagens de programao de caracter geral so fontes de
no determinismo, tornando os sistemas no previsveis. Como exemplo, podemos citar
construes de recorrncia no limitadas (laos no limitados) ou ainda, primitivas da
linguagem Ada como o "delay" que estipula um limite mnimo mas no garante um
limite mximo na suspenso de uma tarefa e o "select" que na ativao de alternativas
de fluxos de instrues faz uma escolha aleatria entre aquelas com guardas abertos. Os
mecanismos e protocolos de acesso a recursos compartilhados disponveis nestas
linguagens, geralmente no limitados, podem tambm tornar os cdigos programados
no previsveis. Entretanto, melhorias so obtidas em linguagens destinadas a
programao de tempo real que eliminam chamadas recursivas e estruturas dinmicas
de dados e onde so permitidos apenas laos limitados no tempo. Alm disso, estas
linguagens permitem expressar comportamentos temporais atravs de construes
apropriadas. Real-Time Euclid [KSt86] e Real-Time Concurrent C [GeR91] so
exemplos dessas linguagens.
O hardware tambm influi sobre a previsibilidade de comportamento dos sistemas
de tempo real. O processador com suas instrues de "prefetch", os dispositivos de
acesso direto memria (DMA), e mecanismos de memria "cache" so outras fontes
de no determinismo; o uso destes mecanismos ou dispositivos dificulta a determinao
dos tempos de computao no pior caso e consequentemente a anlise da
previsibilidade. As caractersticas de sistemas operacionais e suportes so tambm
determinantes para que se conhea os tempos limites envolvidos em seus
processamentos.
Diante do exposto acima, importante enfatizar que em cada etapa do ciclo de
desenvolvimento de um Sistema de Tempo Real, torna-se necessrio o uso de
ferramentas e metodologias apropriadas que permitem verificar o comportamento do
sistema e sua implementao como previsveis. A previsibilidade o requisito
necessrio que deve ser introduzido em paradigmas de computao clssico para se
poder atender aplicaes de tempo real, em particular quando estas apresentam
requisitos temporais rgidos.
Nesta seo, a noo de previsibilidade que foi introduzida est associada a uma
antecipao determinista do comportamento temporal do sistema. Ou seja, o sistema
previsvel quando podemos antecipar que todos os prazos colocados a partir das
1.5 Classificao dos Sistemas de Tempo Real 7
interaes com o seu ambiente sero atendidos. Mas na literatura, alguns autores como
em [JLT85] tambm associam o conceito de previsibilidade a uma antecipao
probabilista do comportamento do sistema, baseada em estimativas ou simulaes que
estipulam probabilidades dos prazos a serem atendidos. A previsibilidade probabilista
til em sistemas onde a carga computacional no pode ser conhecida a priori e portanto,
no se consegue uma garantia em tempo de projeto do atendimento de todos os prazos.
As discusses apresentadas acima sobre a previsibilidade, no que se refere a
aspectos de implementao, esto ligadas a um tipo de abordagem na construo de
sistemas de tempo real. Existem outras abordagens onde fatores ligados
implementao no so levados em conta e por hiptese, vlida num grande nmero de
aplicaes, o sistema de tempo real assumido com tendo um comportamento
determinista e por conseqncia a sua previsibilidade garantida. Essas abordagens que
apresentam formas distintas de conseguir a previsibilidade de sistemas de tempo real
so introduzidas no item 1.6 e apresentadas em detalhe no transcorrer desse livro.
1.5 Classificao dos Sistemas de Tempo Real
Os sistemas de tempo real podem ser classificados a partir do ponto de vista da

Segurana ("Safety") em: Sistemas No Crticos de Tempo Real (ou STRs brandos,
"Soft Real Time Systems") quando as conseqncias de uma falha devida ao tempo da
mesma ordem de grandeza que os benefcios do sistema em operao normal (ex.
sistema de comutao telefnico, sistema de processamento bancrio); e Sistemas
Crticos de Tempo Real (ou STRs duros, "Hard Real Time Systems"), quando as
conseqncias de pelo menos uma falha temporal excedam em muito os benefcios
normais do sistema (ex. sistema de controle de vo, ou de sinalizao em ferrovias,
sistema de controle de planta nuclear). Nesse caso, essa falha dita catastrfica.
Previsibilidades probabilista e determinista so associadas aos dois grupos distinguidos
acima, respectivamente.
O grupo de sistemas crticos de tempo real pode ser subdividido em: Sistemas de
Tempo Real Crtico Seguros em Caso de Falha ("fail safe") onde um ou vrios estados
seguros podem ser atingidos em caso de falha (por exemplo, parada obrigatria de
trens no caso de falha do sistema de sinalizao ferrovirio); e Sistemas de Tempo Real
Crtico Operacionais em Caso de Falha ("fail operational") que, na presena de falhas
parciais, podem se degradar fornecendo alguma forma de servio mnimo (por
exemplo, sistema de controle de vo com comportamento degradado mas ainda
seguro).
Alguns autores apresentam a sua viso de sistemas de tempo real baseada no ponto
de vista da implementao, distinguindo ento: Sistemas de Resposta Garantida
("guaranteed response system") onde existem recursos suficientes para suportar a carga
de pico e o cenrio de falhas definido; e Sistemas de Melhor Esforo ("best effort
system") quando a estratgia de alocao dinmica de recursos se baseia em estudos
probabilistas sobre a carga esperada e os cenrios de falhas aceitveis. Essa

classificao similar a anterior. A maior parte dos sistemas de tempo real vem sendo
projetados de acordo com o paradigma de melhor esforo, satisfatrio de fato apenas
para os sistemas no crticos de tempo real e levando a situaes danosas para os
sistemas crticos de tempo real para os quais aconselhado seguir o paradigma de
resposta garantida.
1.6 O Problema Tempo Real e Abordagens para a sua

Soluo
O Problema Tempo Real consiste ento em especificar, verificar e implementar

sistemas ou programas que, mesmo com recursos limitados, apresentam
comportamentos previsveis, atendendo as restries temporais impostas pelo ambiente
ou pelo usurio [Jos91]. Se consideramos esses aspectos de construo, tempo real pode
ser visto inicialmente como um problema intrnseco de programao concorrente.
Baseado ento na maneira de tratar a concorrncia surgiram duas abordagens diferentes
amplamente discutidas na literatura nesses vinte ltimos anos: a Abordagem
Assncrona1 e a Abordagem Sncrona.
A abordagem assncrona cujo o entendimento mais usual foi introduzido por R.
Milner [Mil80] trata a ocorrncia e a percepo de eventos independentes numa ordem
arbitrria mas no simultnea. As linguagens CSP, Ada e Real-Time Concurrent C
seguem o paradigma definido nessa abordagem e podem ser consideradas como
linguagens assncronas. Essa abordagem visa uma descrio a mais exata possvel de
um sistema; para tal, baseia-se na observao durante a execuo de todas as
combinaes de ocorrncia de eventos (de forma no simultnea), conhecida como
entrelaamento de eventos ("interleaving"). Essa abordagem considerada como
orientada implementao. Consequentemente, se torna necessrio levar em conta na
especificao e no decorrer do projeto, algumas caractersticas do suporte de software e
de hardware das aplicaes, o que fere eventuais exigncias em termos de
portabilidade. Por outro lado, a procura de uma descrio completa do comportamento
e a introduo de consideraes de implementao torna complexa a anlise das
propriedades do sistema por causa da necessidade de tratar com grande nmero de
estados e do possvel no determinismo introduzido. A abordagem assncrona
apresentada nesse livro implementada usando linguagens e sistemas operacionais e
est fundamentada no tratamento explcito da concorrncia e do tempo de uma
aplicao em tempo de execuo; a questo do escalonamento de tempo real o ponto
principal do estudo da previsibilidade dos sistemas de tempo real.
A abordagem sncrona na forma introduzida em [Ber89] e [BeB91] tem o seu
1
O termo Abordagem Assncrona utilizado neste livro no consenso na literatura de
tempo real.
1.6 O Problema Tempo Real e Abordagens para a sua Soluo 9
princpio bsico na considerao que os clculos e as comunicaes no levam tempo.

A abordagem sncrona se coloca num nvel de abstrao dos aspectos de
implementao tal que o tempo visto com granularidade suficientemente grossa para
que essa hiptese seja verdadeira. A descrio do comportamento do sistema nessa
abordagem menos dependente das questes de implementao, o que satisfatrio do
ponto de vista da portabilidade. A observao dos eventos nessa abordagem
cronolgica, permitindo uma eventual simultaneidade entre eles. Nesta abordagem, a
partir das suas premissas, a concorrncia resolvida sem o entrelaamento de tarefas
("interleaving") e o tempo no tratado de maneira explcita. A abordagem sncrona
considerada como orientada ao comportamento de uma aplicao e a sua verificao.
Por se situar num nvel de abstrao maior que no caso da abordagem anterior, a
abordagem sncrona facilita a especificao e a anlise das propriedades de sistemas de
tempo real. Diversas linguagens como Esterel, Statecharts, Signal, Lustre chamadas
de linguagens sncronas -- seguem o paradigma definido nessa abordagem.
Nesse livro, apresentamos solues que seguem essas duas abordagens para tratar o
problema de tempo real. A abordagem assncrona, dependente das ferramentas de
implementao e que trata explicitamente o tempo e a concorrncia tm introduzidos os
conhecimentos necessrios para o seu uso nos captulos 2 e 3. A abordagem sncrona
baseada na hiptese de sincronismo discutida no captulo 4. Exemplos ilustrativos
permitindo entender essas duas abordagens, mostrando suas vantagens e limitaes so
mostrados no captulo 5. objetivo nesse livro apresentar os tipos de aplicaes nas
quais cada uma dessas abordagens mais adaptada.
Captulo 2
O Escalonamento de Tempo Real
Em sistemas de tempo real que seguem a abordagem assncrona os aspectos de

implementao esto presentes mesmo na fase de projeto. Na implementao de
restries temporais, de fundamental importncia o conhecimento das propriedades
temporais do suporte de tempo de execuo usado e da escolha de uma abordagem de
escalonamento de tempo real adequada classe de problemas que o sistema deve tratar.
Neste sentido, este captulo e o prximo apresentam aspectos da teoria de
escalonamento e de sistemas operacionais sob a tica de tempo real.
Este captulo trata sobre escalonamento de tempo real de um modo geral. Conceitos,
objetivos, hipteses e mtricas so claramente apresentados no sentido de introduzir o
que chamamos de um problema de escalonamento. Posteriormente, diferentes classes
de problemas de escalonamento so examinadas em suas solues algortmicas.
2.1 Introduo
Em sistemas onde as noes de tempo e de concorrncia so tratadas explicitamente,

conceitos e tcnicas de escalonamento formam o ponto central na previsibilidade do
comportamento de sistemas de tempo real. Nos ltimos anos, uma quantidade
significativa de novos algoritmos e de abordagens foi introduzida na literatura tratando
de escalonamento de tempo real. Infelizmente muitos desses trabalhos definem tcnicas
restritas e conseqentemente de uso limitado em aplicaes reais. Esse captulo se
concentra em algumas tcnicas gerais e em suas extenses, visando tambm
perspectiva de um uso mais prtico.
O foco desse captulo sobre tcnicas para escalonamentos dirigidos a prioridades.
Essa escolha devido importncia da literatura disponvel e, porque cobre diversos
aspectos de possveis comportamentos temporais em aplicaes de tempo real. A grande
difuso de suportes (ncleos, sistemas operacionais), na forma de produtos, que baseiam
seus escalonamentos em mecanismos dirigidos a prioridade sem dvida outra
justificativa bastante forte para a escolha do enfoque dado nesse captulo. Essa difuso
to significativa que organismos de padronizao tm adotado essa abordagem de
escalonamento de tempo real. Os padres POSIX [Gal95] - referncia para produtos
comerciais - enfatizam em suas especificaes para tempo real escalonamentos dirigidos
a prioridades. Alguns dos algoritmos apresentados nesse captulo so recomendados
pelas especificaes POSIX.
12 2. O Escalonamento de Tempo Real
Na seqncia introduzido um conjunto de conceitos que permitem a caracterizao

de um problema de escalonamento.
2.2 Modelo de Tarefas
O conceito de tarefa uma das abstraes bsicas que fazem parte do que
chamamos um problema de escalonamento. Tarefas ou processos formam as unidades
de processamento seqencial que concorrem sobre um ou mais recursos computacionais
de um sistema. Uma simples aplicao de tempo real constituda tipicamente de vrias
tarefas. Uma tarefa de tempo real, alm da correo lgica ("correctness"), deve
satisfazer seus prazos e restries temporais ou seja, apresentar tambm uma correo
temporal ("timeliness").
As restries temporais, as relaes de precedncia e de excluso usualmente
impostas sobre tarefas so determinantes na definio de um modelo de tarefas que
parte integrante de um problema de escalonamento. Nas sees subseqentes
descrevemos essas formas de restries que normalmente esto presentes em
processamentos de tempo real.
2.2.1 Restries Temporais
Aplicaes de tempo real so caracterizadas por restries temporais que devem ser
respeitadas para que se tenha o comportamento temporal desejado ou necessrio. Todas
as tarefas de tempo real tipicamente esto sujeitas a prazos: os seus "deadlines". A
princpio, uma tarefa deve ser concluda antes de seu "deadline". As conseqncias de
uma tarefa ser concluda aps o seu "deadline" define dois tipos de tarefas de tempo
real:
Tarefas Crticas (tarefas "hard") : Uma tarefa dita crtica quando ao ser
completada depois de seu "deadline" pode causar falhas catastrficas no sistema de
tempo real e em seu ambiente. Essas falhas podem representar em danos
irreversveis em equipamentos ou ainda, em perda de vidas humanas.
Tarefas Brandas ou No Crticas (tarefas "soft"): Essas tarefas quando se

completam depois de seus "deadlines" no mximo implicam numa diminuio de
desempenho do sistema. As falhas temporais nesse caso so identificadas como
benignas onde a conseqncia do desvio do comportamento normal no representa
um custo muito significativo.
Outra caracterstica temporal de tarefas em sistemas de tempo real est baseada na
regularidade de suas ativaes. Os modelos de tarefa comportam dois tipos de tarefas
segundo suas freqncias de ativaes:
2.2 Modelo de Tarefas 13
Tarefas Peridicas: Quando as ativaes do processamento de uma tarefa ocorrem,

numa seqncia infinita, uma s ativao por intervalo regular chamado de
Perodo, essa tarefa identificada como peridica. As ativaes de uma tarefa
peridica formam o conjunto de diferentes instncias da tarefa. Nesse texto
assumimos a primeira ativao de uma tarefa peridica ocorrendo na origem dos
tempos considerados na aplicao (em t=0).
Tarefas Aperidicas ou Tarefas Assncronas: Quando a ativao do processamento

de uma tarefa responde a eventos internos ou externos definindo uma caracterstica
aleatria nessas ativaes, a tarefa dita aperidica.
As tarefas peridicas pela regularidade e portanto pela previsibilidade, usualmente
so associadas a "deadlines hard", ou seja, so tarefas crticas. As tarefas aperidicas
pela falta de previsibilidade em suas ativaes, normalmente, tem "deadlines soft"
associados a suas execues, compondo portanto as tarefas brandas de um sistema de
tempo real. Tarefas espordicas que correspondem a um subconjunto das tarefas
aperidicas, apresentam como caracterstica central a restrio de um intervalo mnimo
conhecido entre duas ativaes consecutivas e por isso, podem ter atributos de tarefas
crticas. As tarefas espordicas portanto so tambm associadas a "deadlines hard". As
figuras 2.1 e 2.2 apresentam caractersticas temporais de tarefas peridicas e
aperidicas, respectivamente.
Outras restries temporais so importantes na definio do comportamento
temporal de uma tarefa:
Tempo de computao ("Computation Time"): O tempo de computao de uma

tarefa o tempo necessrio para a execuo completa da tarefa.
Tempo de incio ("Start Time"): Esse tempo corresponde ao instante de incio do

processamento da tarefa em uma ativao.
Tempo de trmino ("Completion Time"): o instante de tempo em que se

completa a execuo da tarefa na ativao.
Tempo de chegada ("Arrival Time"): O tempo de chegada de uma tarefa o

instante em que o escalonador toma conhecimento de uma ativao dessa tarefa.
Em tarefas peridicas, o tempo de chegada coincide sempre com o incio do
perodo da ativao. As tarefas aperidicas apresentam o tempo de chegada
coincidindo com o tempo da requisio do processamento aperidico.
Tempo de liberao ("Release Time"): O tempo de liberao de uma tarefa

coincide com o instante de sua incluso na fila de Pronto (fila de tarefas prontas)
para executar.
Dependendo do modelo de tarefas assumido o tempo de liberao pode ou no
coincidir com o tempo de chegada da tarefa. Em geral assumido que to logo uma
instncia de uma tarefa chegue, a mesma liberada na fila de Pronto. Mas, nem sempre
esse o caso; uma tarefa pode ser retardada na sua liberao pelo "polling" de um
escalonador ativado por tempo ("tick scheduler") ou talvez pelo bloqueio na recepo
de uma mensagem (tarefas ativadas por mensagem). Essa no coincidncia dos tempos
de chegada com as liberaes da tarefa conduz ao que identificado como "Release
Jitter", que representa a mxima variao dos tempos de liberao das instncias da
tarefa.
Diante das restries temporais citadas temos ento o comportamento temporal de
uma tarefa peridica Ti descrito pela qudrupla (Ji, Ci, Pi, Di) onde Ci representa o
tempo de computao da tarefa, Pi o perodo da tarefa, Di o "deadline" e Ji o
"Release Jitter" da tarefa que, de certa maneira, corresponde a pior situao de
liberao da tarefa. Nessa representao de tarefas peridicas, Ji e Di so grandezas
relativas (intervalos), medidas a partir do incio do perodo Pi. O "deadline" absoluto e
o tempo de liberao da ksima ativao da tarefa peridica Ti so determinados a partir
dos perodos anteriores:
dik = (k-1)Pi + Di
ri = (k-1)Pi +Ji (pior situao de liberao).
a tiv a o 1 a tiv a o 2 a tiv a o 3
Pi Pi Pi
D D D
Ci Ci Ci
a r1 st ct d a =r st ct d a r3 st ct d t
F i g u r a 2 . 1 : A ti v a e s d e u m a t a r e f a p e r i d ic a
Na figura 2.1 ilustrado alguns dos parmetros descritos acima. Porm, cada
ativao da tarefa peridica (Ji, Ci, Pi, Di) definida a partir de tempos absolutos: os
tempos de chegada (ai), os tempos de liberao (ri), os tempos de incio (sti), os tempos
de trmino (cti) e os "deadlines" absolutos (di).
r e q u is i o 1 r e q u is i o 2
m in i m in i
Di Di
Ci C
0 a st ct d st = a ct d t
F ig u r a 2 .2 : A tiv a e s d e u m a ta re f a a p e r i d ic a
2.3 Escalonamento de Tempo Real 15
Uma tarefa espordica descrita pela tripla (Ci, Di, mini) onde Ci o tempo de
computao, Di o "deadline" relativo medido a partir do instante da requisio do
processamento aperidico (chegada da tarefa espordica) e mini corresponde ao
mnimo intervalo entre duas requisies consecutivas da tarefa espordica. A descrio
de uma tarefa aperidica pura se limita apenas s restries Ci e Di. Na figura 2.2, a
tarefa aperidica espordica (Ci, Di, mini) apresentada com duas requisies.
Tomando o tempo de chegada da requisio espordica 2 como a2, o "deadline"
absoluto desta ativao assume o valor dado por: d2=a2+Di.
2.2.2 Relaes de Precedncia e de Excluso
Em aplicaes de tempo real, muitas vezes, os processamentos no podem executar

em ordem arbitrria. Implicaes semnticas definem relaes de precedncia entre as
tarefas da aplicao determinando portanto, ordens parciais entre as mesmas. Uma
tarefa Tj precedida por uma outra Ti (Ti Tj), se Tj pode iniciar sua execuo somente
aps o trmino da execuo de Ti. Relaes de precedncia podem tambm expressar a
dependncia que tarefas possuem de informaes (ou mesmo sinais de sincronizao)
produzidas em outras tarefas. As relaes de precedncia em um conjunto de tarefas
usualmente so representadas na forma de um grafo acclico orientado, onde os ns
correspondem s tarefas do conjunto e os arcos descrevem as relaes de precedncia
existentes entre as tarefas.
O compartilhamento de recursos em excluso mtua define outra forma de relaes
entre tarefas tambm significativas em escalonamentos de tempo real: as relaes de
excluso. Uma tarefa Ti exclui Tj quando a execuo de uma seo crtica de Tj que
manipula o recurso compartilhado no pode executar porque Ti j ocupa o recurso.
Relaes de excluso em escalonamentos dirigidos a prioridade podem levar a
inverses de prioridades onde tarefas mais prioritrias so bloqueadas por tarefas
menos prioritrias.
As relaes de precedncia e de excluso sero retomadas no item que trata sobre os
algoritmos de escalonamento dirigidos a prioridades.
2.3 Escalonamento de Tempo Real
2.3.1 Principais Conceitos
O termo escalonamento ("scheduling") identifica o procedimento de ordenar tarefas

na fila de Pronto. Uma escala de execuo ("schedule") ento uma ordenao ou lista
que indica a ordem de ocupao do processador por um conjunto de tarefas disponveis
na fila de Pronto. O escalonador ("scheduler") o componente do sistema responsvel

em tempo de execuo pela gesto do processador. o escalonador que implementa
uma poltica de escalonamento ao ordenar para execuo sobre o processador um
conjunto de tarefas.
Polticas de escalonamento definem critrios ou regras para a ordenao das tarefas
de tempo real. Os escalonadores utilizando ento essas polticas produzem escalas que
se forem realizveis ("feasible"), garantem o cumprimento das restries temporais
impostas s tarefas de tempo real. Uma escala dita tima se a ordenao do conjunto
de tarefas, de acordo com os critrios pr-estabelecidos pela poltica de escalonamento,
a melhor possvel no atendimento das restries temporais.
Tendo como base a forma de clculo da escala (ordenao das tarefas), algumas
classificaes so encontradas para a grande variedade de algoritmos de escalonamento
de tempo real encontrados na literatura [AuB90, But97, CSR88]. Os algoritmos so
ditos preemptivos ou no preemptivos quando em qualquer momento tarefas se
executando podem ou no, respectivamente, ser interrompidas por outras mais
prioritrias. Algoritmos de escalonamento so identificados como estticos quando o
clculo da escala feito tomando como base parmetros atribudos s tarefas do
conjunto em tempo de projeto (parmetros fixos). Os dinmicos, ao contrrio, so
baseados em parmetros que mudam em tempo de execuo com a evoluo do sistema.
Os algoritmos de escalonamento que produzem a escala em tempo de projeto so
identificados como algoritmos "off-line". Se a escala produzida em tempo de
execuo o algoritmo de escalonamento dito de "on-line". A partir dessas
classificaes podemos ter algoritmos off-line estticos, on-line estticos e on-line
dinmicos. Essas classificaes sero revistas na apresentao de algoritmos de
escalonamento.
Um problema de escalonamento, na sua forma geral, envolve um conjunto de
processadores, um conjunto de recursos compartilhados e um conjunto de tarefas
especificadas segundo um modelo de tarefas definindo restries temporais, de
precedncia e de excluso. O escalonamento de tempo real, na sua forma geral,
identificado como um problema intratvel (NP-completo [GaJ79], [AuB90]). Muito
freqentemente os algoritmos existentes representam uma soluo polinomial para um
problema de escalonamento particular, onde um conjunto de hipteses podem expressar
simplificaes no modelo de tarefas ou ainda na arquitetura do sistema, no sentido de
diminuir a complexidade do problema. Quando nenhuma simplificao usada para
abrandar a complexidade no escalonamento, uma heurstica usada para encontrar uma
escala realizvel ainda que no sendo tima mas que garanta as restries do problema.
Os algoritmos de escalonamento esto ento ligados a classes de problemas de
escalonamento de tempo real. Um algoritmo identificado como timo se minimiza
algum custo ou mtrica definida sobre a sua classe de problema. Quando nenhum custo
ou mtrica definido, a nica preocupao ento encontrar uma escala realizvel.
Nesse caso, o algoritmo dito timo quando consegue encontrar uma escala realizvel
para um conjunto de tarefas sempre que houver um algoritmo da mesma classe que
tambm chega a uma escala realizvel para esse mesmo conjunto; se o algoritmo timo
falha em um conjunto de tarefas na determinao de uma escala realizvel ento todos

os algoritmos da mesma classe de problema tambm falharo.
2.3.2 Abordagens de Escalonamento
Uma aplicao de tempo real expressa na forma de um conjunto de tarefas e, para

efeito de escalonamento, o somatrio dos tempos de computao dessas tarefas na fila
de Pronto determina a carga computacional ("task load") que a aplicao constitui para
os recursos computacionais em um determinado instante. Uma carga toma
caractersticas de carga esttica ou limitada quando todas as suas tarefas so bem
conhecidas em tempo de projeto na forma de suas restries temporais, ou seja, so
conhecidas nas suas condies de chegada ("arrival times" das tarefas). O fato de
conhecer a priori os tempos de chegada torna possvel a determinao dos prazos a que
uma carga est sujeita. As situaes de pico (ou de pior caso) nestas cargas so tambm
conhecidas em tempo de projeto. Cargas estticas so modeladas atravs de tarefas
peridicas e espordicas.
Cargas dinmicas ou ilimitadas ocorrem em situaes onde as caractersticas de
chegada das tarefas no podem ser antecipadas. Essas cargas so modeladas usando
tarefas aperidicas, ou seja, basta que se tenha uma tarefa aperidica no conjunto cujo
intervalo mnimo entre requisies seja nulo e teremos as condies de pico dessa carga
desconhecida em tempo de projeto.
O escalonamento muitas vezes dividido em duas etapas. Um teste de
escalonabilidade inicialmente executado, no sentido de determinar se as restries
temporais de um conjunto de tarefas so atendidas considerando os critrios de
ordenao definidos no algoritmo de escalonamento. A segunda etapa envolve ento o
clculo da escala de execuo.
Diferentes abordagens de escalonamento so identificadas na literatura, tomando
como base o tipo de carga tratado e as etapas no escalonamento identificados acima. Em
[RaS94] definida uma taxonomia que identifica trs grupos principais de abordagens
de escalonamento de tempo real: as abordagens com garantia em tempo de projeto ("off-
line guarantee"), com garantia em tempo de execuo ("on-line guarantee") e
abordagens de melhor esforo ("best-effort").
O grupo garantia em tempo de projeto formado por abordagens que tem como
finalidade a previsibilidade determinista. A garantia em tempo de projeto conseguida
a partir de um conjunto de premissas:
a carga computacional do sistema conhecida em tempo de projeto (carga

esttica);
no sistema existe uma reserva de recursos suficientes para a execuo das
tarefas, atendendo suas restries temporais, na condio de pior caso.
O fato de se conhecer a priori a carga (conhecer os tempos de chegada das tarefas),

permite que se possa fazer testes de escalonabilidade, determinando se o conjunto de
tarefas considerado escalonvel e, portanto, garantindo suas restries temporais ainda
em tempo de projeto. O conhecimento prvio da situao de pior caso (situao de pico)
permite at que se possa redimensionar o sistema de modo a garantir as restries
temporais mesmo nessa situao de pico. O grupo de abordagens com garantia em
tempo de projeto prprio para aplicaes deterministas ou crticas onde a carga
conhecida previamente, como em aplicaes embarcadas, controle de trfego
ferrovirio, controle de processos em geral, etc.
So basicamente dois os tipos de abordagens com garantia em tempo de projeto: o
executivo cclico e os escalonamentos dirigidos a prioridades. No executivo cclico
([Kop97] [XuP93]) ambos, o teste de escalonabilidade e a produo da escala, so
realizados em tempo de projeto. Essa escala (ou grade), definida em tempo de projeto,
de tamanho finito e determina a ocupao dos slots do processador em tempo de
execuo. O teste de escalonabilidade fica implcito no processo de montagem da
escala. A complexidade dos algoritmos ou heursticas usadas no clculo da escala
depende da abrangncia do modelo de tarefas usado. Modelos mais complexos
envolvem o uso de funes heursticas para dirigir tcnicas de "branch and bound" na
procura de escalas realizveis [Pin95].
Essa abordagem chamada de executivo cclico porque o escalonador em tempo de
execuo se resume a um simples dispachante, ativando tarefas segundo a grade,
ciclicamente. A escala calculada nessa abordagem, em tempo de projeto, reflete o pior
caso1. Como o pior caso distante do caso mdio e nem sempre ocorre, a ativao das
tarefas segundo essas grades, embora satisfaa s restries temporais, implica em
desperdcio de recursos que so sempre reservados para o pior caso.
Abordagens com garantia em tempo de projeto baseadas em escalonadores dirigidos
a prioridades so mais flexveis. O teste de escalonamento realizado em tempo de
projeto enquanto a escala produzida "on-line" por um escalonador dirigido a
prioridades. As tarefas tm suas prioridades definidas segundo polticas de
escalonamento que envolvem atribuies estticas (prioridades fixas) ou dinmicas
(prioridades variveis), caracterizando escalonadores on-line estticos ou dinmicos.
Nessa abordagem, o pior caso se reflete apenas no teste de escalonabilidade que
executado em tempo de projeto, decidindo se o conjunto de tarefas escalonvel ou
no. Por no existir uma reserva de recursos em tempo de execuo como no executivo
cclico, os escalonamentos dirigidos a prioridades definem solues mais flexveis,
porm, mantendo tambm garantias de recursos para o pior caso.
Os grupos de abordagens garantia dinmica ("on-line guarantee") e de melhor
1
No clculo da escala o pior caso considerado, levando em conta a pior situao de chegada
das tarefas, as tarefas se executando com os seus piores tempos de computao, as tarefas
espordicas ocorrendo na mxima freqncia possvel definida por seus intervalos mnimos entre
ativaes (mini), etc.
esforo ("best-effort"), ao contrrio do grupo anterior, no tratam com uma carga

computacional previsvel; na verdade, a carga tratada por essas abordagens dinmica:
os tempos de chegada das tarefas no so conhecidos previamente. Quando o pior caso
no pode ser antecipado em tempo de projeto, no se consegue prever recursos para
todas as situaes de carga. No existindo portanto, a possibilidade de se antecipar que
todas as tarefas, em qualquer situao de carga, tero sempre seus "deadlines"
respeitados. Essas abordagens que tratam com carga dinmica devem ento lidar com
situaes, em tempo de execuo, onde os recursos computacionais so insuficientes
para os cenrios de tarefas que se apresentam (situaes de sobrecarga). Tanto a escala
como os testes de escalonabilidade so realizados em tempo de execuo nessas
abordagens (escalonadores "on-line" e dinmicos).
O grupo de abordagens com garantia dinmica ([RaS94]) se utilizam de um teste
para verificar a escalonabilidade do conjunto formado por uma nova tarefa que chega
no sistema e das tarefas que j existiam previamente na fila de pronto. Esses testes so
chamados de testes de aceitao e esto baseados em anlises realizadas com hipteses
de pior caso sobre alguns parmetros temporais. Se o teste indica o conjunto como no
escalonvel, a nova tarefa que chegou ento descartada. Esse mecanismo de garantia
dinmica em qualquer situao preserva as tarefas j previamente garantidas como
escalonveis. Essas abordagens que oferecem garantia dinmica so prprias para
aplicaes que possuam restries crticas mas que operam em ambientes no
deterministas. Sistemas militares, sistemas de radar e controle areo exemplificam
alguns desses sistemas que esto sujeitos a cargas dinmicas e necessitam atender
restries temporais.
As abordagens de melhor esforo so constitudas por algoritmos que tentam
encontrar uma escala realizvel em tempo de execuo sem realizar testes ou ainda,
realizando testes mais fracos. No existe a garantia de execues de tarefas atendendo
suas restries temporais. Essas abordagens so adequadas para aplicaes no crticas,
envolvendo tarefas "soft" onde a perda de "deadlines" no representa custos alm da
diminuio do desempenho nessas aplicaes. As abordagens de melhor esforo so
adequadas para aplicaes de tempo real brandas como sistemas de multimdia.
O desempenho de esquemas de melhor esforo, na ocorrncia de casos mdios,
melhor que os baseados em garantia. As hipteses pessimistas feitas em abordagens
com garantia dinmica podem desnecessariamente descartar tarefas. Nas abordagens de
melhor esforo tarefas so abortadas somente em condies reais de sobrecarga, na
ocorrncia de falhas temporais ("deadline"s no podem ser atendidos).
Algumas tcnicas foram introduzidas no sentido de tratar com sobrecargas. A
Computao Imprecisa [LSL94], o "Deadline (m,k) Firm" [HaR95], Tarefas com
Duplo "Deadlines" [GNM97] so exemplos dessas tcnicas adaptativas. Essas tcnicas
de escalonamento adaptativo so usadas em abordagens de melhor esforo para tratar
com sobrecargas em cargas dinmicas. A figura 2.3 sintetiza as abordagens descritas
nesse item.
Nesse captulo, o estudo de escalonamento de tempo real concentrado sobre a
abordagem de escalonamento dirigido a prioridades.
E sc a lo n a m e n to d e T e m p o R e a l
A b o rd a g e n s c o m G a ra n tia A b o rd a g e n s c o m A b o rd a g e n s d e
e m T e m p o d e P ro je to G a ra n tia D in m ic a M e lh o r E sfo r o
E x e c u tiv o D irig id o a T c n ic a s
P rio rid a d e s A d a p ta tiv a s
C c lic o
F ig u r a 2 . 3 : A b o r d a g e n s d e E s c a lo n a m e n t o d e T e m p o R e a l
2.3.3 Teste de Escalonabilidade
Testes de escalonabilidade so importantes no processo de escalonamento de tarefas

de tempo real no sentido de determinar se um conjunto de tarefas escalonvel, ou seja,
se existe para esse conjunto de tarefas uma escala realizvel. Esses testes variam
conforme os modelos de tarefas e polticas definidas em um problema de
escalonamento. Normalmente, correspondem a anlises de pior caso que em certas
classes de problemas, apresentam complexidade NP.
c o n ju n to s d e ta re fa s e sc a lo n v e is c o n ju n to s d e ta re fa s n o e sc a lo n v e is
A u m e n to d a c o m p le x id a d e
te ste su fic ie n te d o s c o n ju n to s d e ta re fa s
te ste e x a to
te ste n e c e ss rio
F ig u r a 2 .4 : T ip o s d e te ste s d e e sc a lo na bilid a d e
Na literatura so identificados alguns tipos de testes [Kop92c]:
Testes exatos so anlises que no afastam conjuntos de tarefas que apresentam

escalas realizveis. So precisos na medida em que identificam tambm conjuntos
no escalonveis. Em muitos problemas so impraticveis os testes exatos.
Testes suficientes so mais simples na execuo porm apresentam o custo do

descarte de conjuntos de tarefas escalonveis. um teste mais restritivo onde
2.4 Escalonamento de Tarefas Peridicas 21
conjuntos de tarefas aceitos nesses testes certamente so escalonveis; porm entre

os descartados podem existir conjuntos escalonveis.
Testes necessrios correspondem tambm a anlises simples porm no to

restritivas. O fato de um conjunto ter passado por um teste necessrio no implica
que o mesmo seja escalonvel. A nica garantia que esse tipo de teste pode
fornecer que os conjuntos descartados de tarefas certamente so no escalonveis.
A figura 2.4 ilustra os trs tipos de testes descritos acima.

A utilizao de uma tarefa Ti que serve como uma medida da ocupao do
processador pela mesma, dado por:
Ui = Ci / Pi se a tarefa Ti peridica, ou
Ui = Ci / Mini se a tarefa Ti espordica,
onde Ci, Pi e Mini so respectivamente o tempo mximo de computao, o perodo e o

intervalo mnimo entre requisies da tarefa Ti. A utilizao de um processador (U) d a
medida da ocupao do mesmo por um conjunto de tarefas { T1, T2, T3, ..., Tn}:
n
U = U
i
i . [1]
O conceito de utilizao serve de base para testes simples e bastante usados. A idia
central nesses testes que a soma dos fatores de utilizao (Ui) das tarefas do conjunto
no ultrapasse o nmero de processadores disponveis para suas execues:
n
U = U i m
i
onde m o nmero de processadores. Testes baseados na utilizao podem ser exatos,
necessrios ou suficientes, dependendo da poltica usada e do modelo de tarefas
assumido [Kop92c].
2.4 Escalonamento de Tarefas Peridicas
Nesse item tratado o problema do escalonamento de tarefas peridicas. Se

considerarmos aplicaes de tempo real de uma maneira geral, sejam controle de
processos ou mesmo aplicaes de multimdia, as atividades envolvidas nessas
aplicaes se caracterizam basicamente pelo comportamento peridico de suas aes.
As caractersticas de tarefas peridicas que determinam o conhecimento a priori dos
tempos de chegada e, por conseqncia, da carga computacional do sistema, permitem
que se obtenha garantias em tempo de projeto sobre a escalonabilidade de um conjunto
de tarefas peridicas.
O escalonamento de tarefas peridicas, nesse texto, discutido em esquemas
dirigidos a prioridades. Nesses esquemas de escalonamento, as prioridades atribudas

s tarefas do conjunto so derivadas de suas restries temporais, e no de atributos
outros como a importncia ou o grau de confiabilidade das tarefas. Escalonamentos
baseados em prioridades, alm de apresentarem melhor desempenho e flexibilidade, se
comparados a abordagens como o executivo cclico, so objeto de uma literatura
relativamente recente e abrangente que estende os trabalhos iniciais introduzidos em
[LiL73].
Neste captulo, feita uma reviso dos algoritmos de prioridade fixa Taxa
Monotnica (Rate Monotonic) [LiL73] e "Deadline" Monotnico (Deadline
Monotonic) [LeW82] e do algoritmo "Earliest Deadline First" [LiL73] que apresenta
atribuio dinmica de prioridades. Esses algoritmos clssicos so tidos como timos
para suas respectivas classes de problemas, sendo caracterizados por modelos de tarefas
simplificados. O conceito de utilizao e os testes de escalonabilidade nesses algoritmos
so apresentados como forma de anlise a priori para determinar se existe uma escala
realizvel que garanta as restries temporais impostas sobre um conjunto de tarefas
peridicas. Na seqncia, aps o estudo destes modelos clssicos, so aprofundados os
esquemas de prioridade fixa, nas suas extenses aos trabalhos de Liu [LiL73]. Um
estudo similar para esquemas de prioridade dinmica apresentado no Anexo A.
2.4.1 Escalonamento Taxa Monotnica [LiL73]
O escalonamento Taxa Monotnica (Rate Monotonic) produz escalas em tempo

de execuo atravs de escalonadores preemptivos, dirigidos a prioridades. um
esquema de prioridade fixa; o que define ento, o RM como escalonamento esttico e
on-line segundo os conceitos apresentados no item 2.3.1. O RM dito timo entre os
escalonamentos de prioridade fixa na sua classe de problema, ou seja, nenhum outro
algoritmo da mesma classe pode escalonar um conjunto de tarefas que no seja
escalonvel pelo RM.
As premissas do RM que facilitam as anlises de escalonabilidade, definem um
modelo de tarefas bastante simples :
a. As tarefas so peridicas e independentes.

b. O "deadline" de cada tarefa coincide com o seu perodo (Di=Pi).
c. O tempo de computao (Ci) de cada tarefa conhecido e constante (Worst
Case Computation Time).
d. O tempo de chaveamento entre tarefas assumido como nulo.
As premissas a e b so muito restritivas para o uso desse modelo na prtica, contudo

essas simplificaes so importantes para que se tenha o entendimento sobre o
escalonamento de tarefas peridicas.
A poltica que define a atribuio de prioridades usando o RM, determina uma
ordenao baseada nos valores de perodos das tarefas do conjunto: as prioridades

decrescem em funo do aumento dos perodos, ou seja, quanto mais freqente a tarefa
maior a sua prioridade no conjunto. Como os perodos das tarefas no mudam, o RM
define uma atribuio esttica de prioridades (prioridade fixa).
A anlise de escalonabilidade no RM, feita em tempo de projeto, baseada no
clculo da utilizao. Para que n tarefas tenham o atendimento de suas restries
temporais quando escalonadas pelo RM, deve ser satisfeito o teste abaixo que define
uma condio suficiente:
( )
n

Ci
[2 ]
1
U = Pi n 2
n
1 .
i
A medida que n cresce, nesse teste, a utilizao do processador converge para 0,69.
Uma utilizao de aproximadamente 70% define uma baixa ocupao do processador
que, certamente, implica no descarte de muitos conjuntos de tarefas com utilizao
maior e que, mesmo assim, apresentam escalas realizveis (feasible).
Essa condio suficiente pode ser relaxada quando as tarefas do conjunto
apresentam perodos mltiplos do perodo da tarefa mais prioritria. Nesse caso a
utilizao alcanada sob o RM se aproxima do mximo terico, coincidindo o teste
abaixo com uma condio necessria e suficiente [Kop92c]:
n
U = C i
i
Pi 1.
Tarefas Peridicas Periodo Tempo de Computao Prioridade RM Utilizao

(Pi) (Ci) (pi) (Ui)
tarefa A 100 20 1 0,2
tarefa B 150 40 2 0,267
tarefa C 350 100 3 0,286
tabela 2.1: Utilizao de tarefas peridicas
A tabela 2.1 mostra um exemplo de conjunto de tarefas peridicas onde o objetivo

verificar a escalonabilidade desse conjunto sob a poltica Taxa Monotnica. A
utilizao do processador por esse conjunto de tarefas corresponde a 0,753. Aplicando a
equao [2] concludo que esse conjunto escalonvel sob o RM:
0 , 753 n 2 ( 1
n
)
1 = 0 , 779
A figura 2.1 apresenta na forma de um diagrama de Gantt a escala RM

correspondente tabela 2.1. As tarefas A, B e C chegam em t=0. Por ser mais freqente
(maior prioridade segundo o RM), A assume o processador. Em t=20, a tarefa A conclui
e B toma posse do processador por ser a mais prioritria na fila de Pronto. A tarefa C
assume em t=60 e interrompida quando da chegada da nova ativao de A em t=100

que, por sua vez, passa a se executar (preempo de C por A). C sofre mais interrupes
de novas ativaes das tarefas B e A em t=150 e t=200, respectivamente.
tarefa A -
tarefa B -
tarefa C -
A ,B ,C A B A A ,B C
0 40 80 1 20 160 200 2 40 2 80 320 3 60

t
F igura 2.5 : E scala R M produzida a partir da T abela 2.1
2.4.2 Escalonamento "Earliest Deadline First" (EDF) [LiL73]
O "Earliest Deadline First" (EDF) define um escalonamento baseado em

prioridades: a escala produzida em tempo de execuo por um escalonador
preemptivo dirigido a prioridades. um esquema de prioridades dinmicas com um
escalonamento "on-line" e dinmico (item 2.3.1.). O EDF um algoritmo timo na
classe dos escalonamentos de prioridade dinmica. As premissas que determinam o
modelo de tarefas no EDF so idnticas s do RM:
a. As tarefas so peridicas e independentes.

b. O "deadline" de cada tarefa coincide com o seu perodo (Di=Pi).
c. O tempo de computao (Ci) de cada tarefa conhecido e constante (Worst
Case Computation Time).
d. O tempo de chaveamento entre tarefas assumido como nulo.
A poltica de escalonamento no EDF corresponde a uma atribuio dinmica de

prioridades que define a ordenao das tarefas segundo os seus "deadlines" absolutos
(di). A tarefa mais prioritria a que tem o "deadline" di mais prximo do tempo atual.
A cada chegada de tarefa a fila de prontos reordenada, considerando a nova
distribuio de prioridades. A cada ativao de uma tarefa Ti, seguindo o modelo de
tarefas peridicas introduzido no item 2.2., um novo valor de "deadline" absoluto
determinado considerando o nmero de perodos que antecede a atual ativao (k):
dik=kPi.
No EDF, a escalonabilidade tambm verificada em tempo de projeto, tomando
como base a utilizao do processador. Um conjunto de tarefas peridicas satisfazendo
as premissas acima escalonvel com o EDF se e somente se :
n
U = i=1
Ci
Pi 1 . [3 ]
Esse teste suficiente e necessrio na classe de problema definida para o EDF pelas
premissas a, b, c e d. Se qualquer uma dessas premissas relaxada (por exemplo,
assumindo DiPi), a condio [3] continua a ser necessria porm no mais suficiente.
No exemplo mostrado na figura 2.6, o mesmo conjunto de tarefas submetido a
escalonamentos EDF e RM. A utilizao do conjunto de tarefas de 100%. Com isto
pela equao [2] o conjunto no escalonvel pelo RM. Entretanto, a equao [3]
garante a produo de uma escala pelo EDF. No caso (b) da figura 2.6, no tempo t = 50
a tarefa B perde seu "deadline". Alm da melhor utilizao, uma outra diferena,
normalmente citada na literatura, que o EDF produz menos preempes que o RM. A
favor do RM est a sua simplicidade que facilita a sua implementao.
ta r e fa A -
ta re fa s p e ri d ic a s C i P i D i
ta r e fa A 10 20 20 ta r e fa B -
ta r e fa B 25 50 50
A ,B A A B
0 10 20 30 40 50 60
t
(a) E sc a lo n a m e n to E D F
A ,B A A B
p e r d a d e d e a d lin e d e B
0 10 20 30 40 50 60
t
(b) E sc a lo n a m e n to R M
F ig u r a 2 . 6 : E s c a la s p r o d u z id a s p e lo ( a ) E D F e ( b ) R M
2.4.3 Escalonamento "Deadline" Monotnico [LeW82]
O "Deadline Monotonic" introduzido em [LeW82] estende o modelo de tarefas do

Taxa Monotnica. A premissa do RM que limitava os valores de "deadlines" relativos
aos valores dos perodos das tarefas (Di=Pi), em muitas aplicaes, pode ser
considerada bastante restritiva. O modelo de tarefas do DM tambm define tarefas
peridicas independentes, o pior caso de tempo de processamento das tarefas (Ci) e o
chaveamento entre tarefas de durao nula. Porm assume "deadlines" relativos

menores ou iguais aos perodos das tarefas (Di Pi).
A poltica do DM define uma atribuio esttica de prioridades, baseada nos

"deadlines" relativos das tarefas (Di). As prioridades so atribudas na ordem inversa
dos valores de seus "deadlines" relativos. A produo da escala, portanto, feita em
tempo de execuo por escalonador preemptivo dirigido a prioridades. O esquema de
prioridades fixas do DM tambm define um escalonamento esttico e "on-line". O
"Deadline" Monotnico tambm um algoritmo timo na sua classe de problema. A
figura 2.7 mostra a escala produzida pelo DM para um conjunto de tarefas peridicas
que apresentam "deadlines" menores que seus respectivos perodos.
ta r e fa s p e r i d ic a s Ci Pi Di pi
ta r e f a A 2 10 6 1 ta r e f a A -
ta r e f a B 2 10 8 2
ta r e f a B -
ta r e f a C 8 20 16 3
ta r e f a C -
A ,B ,C A ,B A ,B ,C
d dB dC
0 4 8 12 16 20 24
t
F i g u r a 2 .7 : E s c a l a p r o d u z i d a p e l o D M
Na introduo desse algoritmo os autores no apresentaram em [LeW82] um teste

correspondente. Em [ABR91] definido um teste suficiente e necessrio para o DM,
baseado no conceito de tempo de resposta de uma tarefa. Uma evoluo deste teste
descrito na seqncia, no item 2.5.2.
2.5 Testes de Escalonabilidade em Modelos Estendidos
Os testes de escalonabilidade apresentados at aqui so baseados em limites na

utilizao do processador. Os modelos de tarefas nesses algoritmos preemptivos,
baseados em prioridades, so mantidos simples o que facilita as anlises nesses testes.
Qualquer extenso nos modelos permitindo, por exemplo, que tarefas possam ter
relaes de precedncia entre si ou que os "deadlines" assumam valores arbitrrios,
define modelos mais prximos de aplicaes concretas de tempo real. Porm, com essas
extenses, os testes fundamentados na noo de utilizao, como apresentados
anteriormente, passam a ser condies necessrias e novos testes mais restritivos so
desejveis.
2.5 Testes de Escalonabilidade em Modelos Estendidos 27
So muitas as propostas na literatura de extenses dos modelos de [LiL73]. Estes

modelos apresentados no item 2.4 podem ser estendidos, por exemplo, para inclurem
tambm tarefas espordicas. Nos testes que se seguem podemos interpretar o valor Pi
tambm como o mnimo intervalo entre requisies (mini) de uma tarefa espordica Ti
[ABR91], [TBW94]. Garantir uma tarefa espordica na sua maior freqncia implica
em ter ativaes menos freqentes tambm respeitando suas restries temporais.
Como visto anteriormente, a anlise (ou teste) de escalonabilidade tenta responder
as questes sobre o atendimento dos requisitos de correo temporal de um conjunto de
tarefas tempo real quando uma determinada poltica de escalonamento, e portanto uma
atribuio de prioridades feita. Nessas anlises so considerados cenrios de pior
caso. Alm de considerarem as tarefas executando com os seus piores casos de tempo
de computao (Ci) e com as suas maiores freqncias de ativao (no caso de tarefas
espordicas), esses testes so construdos levando em conta o Instante Crtico. O pior
caso de ocorrncia de tarefas na fila de Pronto do processador identificado como
instante crtico, ou seja, o instante onde todas as tarefas do sistema esto prontas para
a ocupao do processador. Se nesses cenrios de pior caso um conjunto de tarefas
consegue recursos suficientes para atender suas restries, em situaes mais favorveis
certamente tambm atender.
Na literatura, tanto para escalonamentos com prioridades fixas como para
prioridades dinmicas so descritos testes de escalonabilidade exatos ou suficientes, que
exploram modelos de tarefas mais complexos. Esses testes podem ainda ser construdos
usando a noo de utilizao ou estarem baseados em conceitos como tempo de
resposta e demanda de processador. Nesse item exploramos alguns testes para polticas
de prioridade fixa. Os testes referentes a polticas de prioridade dinmica seguem o
mesmo estilo de apresentao e, foram colocados no Anexo A no sentido de simplificar
a apresentao deste captulo.
2.5.1 "Deadline" Igual ao Perodo
Ainda no estendendo o modelo do algoritmo Taxa Monotnica ("Rate

Monotonic"), mas tentando apresentar um teste com melhor desempenho do que o
original, em [LSD89] apresentado um teste onde a utilizao do processador no tem
mais um sentido esttico, dependente somente das restries temporais das tarefas, mas
tambm funo de uma janela de tempo t considerada no seu clculo. As tarefas de
prioridade maior ou igual a i que esto disponveis para execuo no processador no
intervalo t constituem a carga cumulativa ("workload") Wi(t) deste intervalo e dada
por:
i t
Wi (t ) = . C j , [4 ]
j =1 Pj
onde t/Pj corresponde ao mximo nmero de ocorrncias de uma tarefa Tj no intervalo

t e t/Pj.Cj define as necessidades de processador dessa mesma tarefa no intervalo
considerado. A diviso do "workload" Wi(t) pelo valor de t d a percentagem de
utilizao do processador nesse intervalo de tempo t, considerando apenas tarefas de
prioridade maior ou igual a Ti :
W (t )
U i (t ) = i . [5 ]
t
A condio necessria e suficiente para que a tarefa Ti seja escalonvel que exista
um valor de t em que a sua utilizao Ui(t) seja menor ou igual a 1, isto , que a carga
de trabalho Wi(t) no supere o intervalo de tempo t (Wi(t) t) [LSD89]. A dificuldade
deste teste est em se determinar este valor de t.
Como o modelo define tarefas peridicas com instante crtico ocorrendo em t = 0, se
cada tarefa Ti respeitar o seu primeiro "deadline" ento os "deadlines" subseqentes,
referentes a suas outras ativaes, tambm sero atendidos. Com isto, os valores de t
podem se limitar ao intervalo (0,Pi]. Neste caso a procura de t pode se resumir a testar
os valores de mnimo de Ui(t) no intervalo considerado:
i, min 0< t Pi Ui(t) 1,
No lugar de fazer uma procura entre todos os valores de t no intervalo (0, Pi], os
clculos podem se resumir a testar os valores de :
Pi
S i = kPj 1 j i, k = 1 ,2 , . . . , . [6 ]
P j
Os pontos descritos em Si correspondem aos tempos de chegada das ativaes das

tarefas Tj de prioridade maior ou igual a Ti, ocorrendo dentro do perodo Pi. Estes
pontos correspondem aos mnimos de Ui(t), uma vez que, esta funo monotnica
decrescente nos intervalos entre chegadas de tarefas Tj. Logo, um conjunto de tarefas
peridicas independentes, com instante crtico em t=0 e escalonadas segundo o RM,
ter seus "deadlines" respeitados se :
i, min t Si Ui(t) 1. [7]
O teste acima quando comparado com [2], embora mais complexo, pode aprovar
conjuntos de tarefas que seriam rejeitados pelo teste suficiente proposto originalmente
para o RM. O teste composto a partir de [5] e [7] permite uma maior utilizao do
processador, formando uma condio suficiente e necessria [LSD89], [Fid98].
Como exemplo, considere o conjunto de tarefas da figura 2.6 (tabela 2.2) em que
ocorre na escala do RM, a perda do "deadline" da tarefa T2 em t=50. Para a verificao
das condies de escalonabilidade do conjunto de tarefas usamos o teste formado por

[5] e [7].
ta re fa s p e ri d ic a s Ci Pi Di
t a r e fa T 1 10 20 20
t a r e fa T 2 25 50 50
T a b e la 2 . 2 : E x e m p lo d a fig u r a 2 . 6
Nessa verificao, inicialmente temos que calcular as utilizaes Ui (t) para todas as
tarefas do conjunto. Comeamos ento calculando a carga de trabalho correspondente
de cada tarefa (equao [4]):
t t t
W1 (t ) = .1 0 e W 2 (t ) = .2 5 + .1 0 ,
2 0 5 0 2 0
determinamos as utilizaes (equao [5]):
W1 ( t ) W2 (t )
U 1 (t ) = e U 2 = .
t t
A dificuldade fazer a inspeo na procura de valores de t que determinam Ui(t) 1.

Para a tarefa T1 esses valores so obtidos a partir de S1 ([6]): S1 = {20}. Ento, para o
valor de t=20, a utilizao U1(20) determinada como sendo de 0,5. Logo, pela
condio [7], a tarefa T1 escalonvel.
O conjunto referente a T2, usando tambm [6], formado por: S2 = {20, 40, 50}.
A partir deste conjunto determinada U2(t):
t = 20 U 2 (20) = 1,75
t = 40 U 2 (40) = 1,12
t =50 U 2 (50) = 1,1.
O mximo valor de utilizao U2(t) ocorre em t = 20 (o menor valor de t em S2) e,

usando a condio [7], determinado que o conjunto de tarefas da tabela 2.2 de fato
no escalonvel pelo RM.
2.5.2 "Deadline" Menor que o Perodo
O modelo de tarefas, no teste que se segue, relaxa em escalonamentos de prioridade

fixa a condio que todas as tarefas peridicas independentes devem ter seus
"deadlines" relativos iguais aos seus respectivos perodos. O modelo assume tambm
tarefas com "deadlines" menores aos seus perodos (Di Pi). Esse teste, diferentemente
dos anteriores, est fundamentado no conceito de tempo de resposta. Em [JoP86],
tempo de resposta mximo de uma tarefa foi introduzido como sendo o tempo
transcorrido entre a chegada e o trmino de sua execuo, considerando a mxima
interferncia que a tarefa pode sofrer de outras tarefas de maior ou igual prioridade.
Uma anlise de escalonabilidade que se utilize desse conceito deve representar ento o
pior caso de interferncias (em termos de tempo) sobre cada tarefa do sistema.
Para o clculo do tempo de resposta mximo de uma tarefa necessrio que se
defina uma janela de tempo Ri que corresponda ao intervalo de tempo mximo
transcorrido da liberao de uma tarefa Ti at o trmino de sua execuo. A largura Ri
corresponde ao tempo necessrio, em situao de instante crtico, para a execuo de Ti
e de todas as tarefas com prioridades maiores ou iguais a i (pi=i). Nestas condies, o
tempo de resposta mximo Ri da tarefa Ti dado por :
Ri = Ci + I j
j h p (i)
onde hp(i) o conjunto de prioridades maior que i e, Ij a interferncia que a tarefa Ti

pode sofrer de uma tarefa Tj de prioridade maior, durante a largura Ri. A interferncia Ij
calculada por:
R
I j = i C j
Pj
onde Ri / Pj representa o nmero de liberaes de Tj em Ri. A expresso do tempo de

resposta Ri pode ser reescrita como:
R
Ri = Ci + i C j [8 ]
j h p (i) P j
Uma tarefa Ti mantm suas propriedades temporais sempre que Ri Di. Nesta
verificao necessrio a determinao de Ri a partir de [8]. Porm a largura Ri
aparecendo em ambos os lados dessa equao, implica na necessidade de um mtodo
iterativo para essa determinao. Em [JoP86] apresentado um mtodo para solucionar
[8]:
Rn
R in + 1 = C i + i C j
j h p (i) P j
onde a soluo conseguida a partir do clculo de Rin, a nsima aproximao de Ri,

quando Rin+1= Rin. Nesse mtodo iterativo assumido, como condio de partida,
Ri0=Ci. O mtodo no converge quando a utilizao do conjunto de tarefas for maior
que 100%.
O teste fundamentado no conceito de tempo de resposta determina ento um
conjunto de n tarefas de tempo real como escalonvel sempre que a condio i:1 in
RiDi for verificada. Os clculos dos tempos de respostas formam a base para um teste
suficiente e necessrio.
ta r efa A 2 10 6
ta r efa B 2 10 8
ta r efa C 8 20 16
T a bela 2 .3 : E x em p lo d a fig u r a 2 .7
Para clarificar o uso desse teste de escalonabilidade, considere o exemplo que foi
apresentado na figura 2.7 onde era apresentada uma escala produzida pelo "Deadline
Monotonic". As caractersticas das tarefas so reproduzidas na tabela 2.3.
A poltica DM pelos valores da tabela define uma atribuio de prioridades onde
pA>pB>pC. Os tempos de resposta das tarefas consideradas so determinados a partir da
aplicao da equao [8] nos valores da tabela 2.3. A tarefa TA, por ser a mais
prioritria, no sofre interferncia das demais e o seu tempo de resposta dado por
RA=CA=2. TA escalonvel porque seu tempo de resposta mximo menor que seu
"deadline" relativo (DA = 6) O clculo de RB, ao contrrio, envolve mais passos devido
a interferncia que TB sofre de TA. Aplicando [8] obtido:
R B0 = C B = 2
2
R B1 = 2 + .2 = 4
1 0
4
R B2 = 2 + .2 = 4
1 0
A tarefa TB que apresenta RB = 4 tambm escalonvel (RB DB). O tempo RC, por
sua vez, envolve as interferncias de TA e TB em TC. A partir de [8]:
R C0 = C C = 8
8 8
R C1 = 8 + .2 + .2 = 1 2
1 0 1 0
12 12
R C2 = 8 + .2 + .2 = 1 6
10 1 0
16 16
R C3 = 8 + .2 + .2 = 1 6
1 0 1 0
A tarefa TC tambm escalonvel apresentando um tempo de resposta (16 unidades

de tempo) no limite mximo para o seu "deadline" relativo (RC = DC). Os resultados
obtidos confirmaram a escala obtida pelo DM para o conjunto de tarefas da figura 2.7.
Nos modelos apresentados at aqui as tarefas so assumidas como peridicas e

liberadas sempre no incio de cada perodo. Contudo isto nem sempre corresponde a
uma hiptese realista. Escalonadores ativados por tempo ("ticket scheduler" [TBW94])
podem ser fonte do atraso na liberao de tarefas: as tarefas tem as suas chegadas
detectadas nos tempos de ativao do escalonador, determinando atrasos nas suas
liberaes. Esses atrasos podem ser expressados no pior caso como "release jitters" (J).
Para determinar as modificaes necessrias no sentido de representar no clculo
dos tempos de resposta as variaes na liberao das tarefas, necessrio que se
introduza o conceito de perodo ocupado (busy period). Um perodo ocupado i
corresponde a uma janela de tempo Wi onde ocorre a execuo contnua de tarefas com
prioridade maior ou igual a i (pi = i). O "i-busy period" associado com a tarefa Ti
comea quando da liberao da instncia de Ti e parte do pressuposto que todas as
tarefas de prioridades maior que i esto na fila de pronto.
Se considerarmos a janela Wi, o limite mximo das ocorrncias de Tj nesse intervalo
dado por Wi /Pj. Porm ao se assumir que uma instncia de Tj, anterior ao incio de
Wi, experimenta um atraso mximo Jj na sua liberao determinando a interferncia
dessa instncia sobre Ti associada com Wi, o nmero de ativaes de Tj que interferem
com Ti passa a ser (Wi+Jj) / Pj. Nessas condies o clculo de Wi dado por
[TBW94] :
Wi + J j
Wi = C i + Cj [9 ]
j h p (i) Pj
onde a soluo de [9] conseguida pelo mesmo mtodo iterativo usado para resolver
[8]. Wi o intervalo entre a liberao e o termino de Ti. Para o clculo do tempo de
resposta mximo (Ri), correspondendo ao intervalo de tempo entre a chegada e o
trmino da instncia da tarefa Ti, necessrio que se considere tambm o atraso mximo
experimentado por Ti na sua liberao:
R i = Wi + J i . [10 ]
O teste de um conjunto de tarefas experimentando atrasos em suas liberaes leva

ento em considerao [9], [10] e a verificao da condio i:1in RiDi.
2.5.3 Deadline Arbitrrio
O teste baseado em tempos de resposta calculados a partir de [9] e [10] exato

quando aplicado em modelos com Di Pi. Porm em modelos de "deadlines" arbitrrios
onde "deadlines" podem assumir valores maiores que os respectivos perodos (Di > Pi),
esse teste deixa de ser uma condio suficiente [TBW94]. Tarefas que apresentam seus
"deadlines" maiores que o seus perodos, sofrem o que se pode chamar de
interferncias internas, ou seja, uma vez que se pode ter Di > Pi, ocorrncias anteriores
de uma mesma tarefa podem interferir numa ativao posterior.
necessrio que se estenda o conceito de "busy period" para se determinar o pior
caso de interferncia em uma tarefa Ti onde suas ativaes podem se sobrepor. O "i-
busy period" no comea mais com a liberao da instncia de Ti que se deseja calcular
o tempo de resposta. O perodo ocupado i continua sendo a janela de tempo Wi que
inclui essa instncia de Ti e que corresponde a maior execuo contnua de tarefas com
prioridade maior ou igual a i (pi = i). Porm, o incio desse perodo de execuo
contnua de tarefas se d com a liberao de outra ativao anterior de Ti. Nessa
extenso assumido que a execuo de qualquer liberao de uma tarefa ser atrasada
at que liberaes anteriores da mesma tarefa sejam executadas completamente.
Considera-se ento o "i-busy period" incluindo q+1 ativaes de Ti que podem se
sobrepor na concorrncia ao processador pois Di > Pi. O valor da janela de tempo Wi(q)
correspondente dado por [TBW94]:
Wi (q )
W i ( q ) = ( q + 1) C i +
j h p (i) Pj j
C . [1 1 ]
O valor q.Ci em [11] representa a interferncia interna que a ltima instncia de Ti

sofre em Wi(q). Por exemplo, se q=2 ento Ti ter trs liberaes em Wi(q). O tempo de
resposta da (q+1)sima ativao de Ti dada por:
R i ( q ) = W i ( q ) q Pi [1 2 ]
ou seja, o tempo de resposta dado considerando o desconto do nmero de perodos de

Ti em Wi(q), anteriores a (q+1)sima ativao de Ti. Para que se obtenha o tempo de
resposta mximo Ri da tarefa Ti necessrio que se faa a inspeo de todos "i-busy
periods", na ordem de valores crescentes de q (q=0, 1, 2, 3,..), at um valor de janela
que verifique a condio:
Wi ( q ) ( q + 1) Pi .
Esta janela corresponde ao maior valor de "i-busy period" que se consegue, antes da
execuo de uma tarefa menos prioritria que i [TBW94]. Nessas condies, o tempo
de resposta mximo Ri calculado por:
R i = m a x R i ( q ).
q = 0 , 1 , 2 ,...
Se o efeito de "deadlines" arbitrrios for includo em modelos onde as liberaes

no coincidem com os tempos de chegada das instncias da tarefa Ti, a janela de tempo
Wi(q) e o tempo de resposta Ri passam a ser dados, respectivamente, por:
Wi ( q ) + J j
W i ( q ) = ( q + 1) C i +
j h p (i) Pj
Cj

[1 3 ]
e R i = m a x ( J i + W i ( q ) q Pi ). [1 4 ]
q = 0 , 1 , 2 ,...
O teste de um conjunto de tarefas com "deadlines" arbitrrios e experimentando

atrasos em suas liberaes leva ento em considerao [13], [14] e a verificao da
condio i:1in RiDi. Este teste funciona como uma anlise a priori (em tempo de
projeto) vlida para qualquer poltica de prioridade fixa. A soluo iterativa da equao
[13] tem uma complexidade pseudo-polinomial que para propsitos prticos pode ser
assumida como polinomial [TBW94].
ta re fa s p e ri d ic a s Ji Ci Pi Di
ta r efa T 1 1 10 40 40
ta r efa T 2 3 10 80 25
ta r efa T 3 - 5 20 40
T a bela 2 .4 : T a r efa s com D ea d lin es A r bitr r ios
Como um exemplo de aplicao deste teste para modelos com "deadlines"

arbitrrios, considere o conjunto de tarefas dado pela tabela 2.4. Suponha que queremos
determinar o tempo de resposta mximo da tarefa T3. Considerando uma atribuio de
prioridades onde p1> p2> p3. A tarefa T3 sofre interferncia das outras duas e pela
equao [13], obtemos:
W (q ) + 1 W 3 (q ) + 3
W 3 ( q ) = ( q + 1 ) .5 + 3 .1 0 + .1 0
40 80
Para que se obtenha o tempo de resposta mximo R3 da tarefa T3 necessrio que se

faa a inspeo de todos "3-busy periods", na ordem de valores crescentes de q
(q=0, 1, 2, 3,..), at que o valor de janela seja limitado por: W3(q) (q+1).P3. Ento,
para q = 0 e usando a equao [13], obtido:
W 30 ( 0 ) = C 3 = 5
5 + 1 5 + 3
W 31 ( 0 ) = 5 + .1 0 + 8 0 .1 0 = 2 5
4 0
25 + 1 25 + 3
W 32 ( 0 ) = 5 + .1 0 + .1 0 = 2 5
4 0 8 0
O valor do tempo de resposta R3(0) dado por [12] e corresponde a 25. Com W3(0)
superando o perodo P3 (P3 = 20) ento, essa janela no corresponde ao maior "busy
2.6 Tarefas Dependentes:Compartilhamento de Recursos 35
period" de prioridade 3. Assumindo ento q =1:
W 30 ( 1 ) = C 3 = 5
5 + 1 5 + 3
W 31 ( 1 ) = 1 0 + .1 0 + 8 0 .1 0 = 3 0
4 0
30 + 1 30 + 3
W 32 ( 1 ) = 1 0 + .1 0 + .1 0 = 3 0
4 0 8 0
Com isto obtemos pela equao [12] R3(1) = W3(1) - P3 = 10. Como W3(1) < 2P3,
temos ento o mximo "3-busy period" envolvendo duas ativaes da tarefa T3. Logo o
tempo de resposta mximo da tarefa T3 o maior dos tempos de resposta obtidos, ou
seja, de valor 25, correspondendo a primeira ativao de T3 no maior "3-busy period".
A figura 2.8 mostra esse perodo ocupado de prioridade 3 onde T3 liberada em suas
duas ativaes em t = 0 e t = 20. Por sua vez, devido aos seus "releases jitters", as
tarefas T1 e T2 que chegam em 1 e 3, respectivamente, s so liberadas em t = 0. A
primeira ativao de T3 empurrada para fora de seu perodo interferindo com a
ativao seguinte da mesma tarefa.
tar efa T 1 - tare fas peridic as Ji Ci Pi Di

tar efa T 2 - tar efa T 1 1 10 40 40
tar efa T 2 3 10 80 25
tar efa T 3 -
tar efa T 3 - 5 20 40
T2 T1 T3 T3 d2
-3 -1 0 10 20 30
t
Fig u ra 2.8 : M aio r P ero do O cup ad o da T arefa T 3
2.6 Tarefas Dependentes:Compartilhamento de Recursos
Nos modelos discutidos at a presente seo, as tarefas eram apresentadas como

independentes o que, se considerarmos a grande maioria de aplicaes de tempo real,
no corresponde a uma premissa razovel. Em um ambiente multitarefas o
compartilhamento de recursos implcito e determina alguma forma de relao de
excluso entre tarefas. Comunicaes entre tarefas residindo no mesmo processador,
por exemplo, podem se dar atravs de variveis compartilhadas, usando mecanismos
como semforos, monitores ou similares para implementar a excluso mtua entre as
tarefas comunicantes.
p 1 > p 2 > p 3 > p 4

p e d id o d e e n tr a d a e m S C
T1
T2
T
e x e c u ta n d o e m S C
T4
F ig u r a 2 .9 : In v e rs o d e p rio rid a d e s t
O compartilhamento de recursos e as relaes de excluso decorrentes do mesmo,

determinam bloqueios em tarefas mais prioritrias. Esses bloqueios so identificados na
literatura de tempo real como inverses de prioridades. Considere o cenrio da figura
2.9, formado pelas tarefas peridicas T1, T2, T3 e T4, apresentadas na ordem crescente
de seus perodos. Uma escala construda sobre o conjunto de tarefas baseada no
algoritmo "Rate Monotonic". T1 e T4 compartilham um recurso guardado por um
mecanismo de excluso mtua. Na escala da figura 2.9, o bloqueio que T1 sofre pelo
acesso anterior de T4 ao recurso compartilhado caracteriza um exemplo de inverso de
prioridade: mesmo liberada a tarefa T1 no consegue evoluir devido ao bloqueio. A
tarefa T1, durante o bloqueio, sofre tambm interferncias de T2 e de T3. Esse fato
ocorre porque T4 a tarefa menos prioritria do conjunto e sofre preempes dessas
tarefas intermedirias. As preempes de T2 e de T3 sobre a tarefa T4 podem
caracterizar um bloqueio de T1 com durao de difcil determinao.
Quando as tarefas se apresentam como dependentes, a inverso de prioridades
inevitvel em um escalonamento dirigido a prioridades. O que seria desejvel que as
inverses de prioridades que eventualmente possam ocorrer nas escalas produzidas
sejam limitadas. nesse contexto que alguns mtodos para controlar o acesso em
recursos compartilhados foram introduzidos. Esses mtodos impem certas regras no
compartilhamento dos recursos de modo que o pior caso de bloqueio experimentado por
uma tarefa no acesso a uma varivel compartilhada possa sempre ser conhecido a
priori.
Nesse item examinamos duas destas tcnicas: o Protocolo Herana de Prioridade e
o Protocolo de Prioridade Teto (Priority Ceiling Protocol) desenvolvidos para
esquemas de prioridades fixas [SRL90]. A tcnica Poltica de Pilha (Stack Resource
Policy [Bak91]) prpria para escalonamentos de prioridades dinmicas apresentada
no anexo A.
2.6.1 Protocolo Herana de Prioridade
Uma soluo simples para o problema de inverses prioridades no limitadas seria

ter desabilitada a preempo quando tarefas entrassem em sees crticas [AuB90].
Esse mtodo de escalonamento hbrido (preemptivo e no preemptivo) evita as
interferncias de tarefas intermedirias, porm, bastante penalizante com tarefas mais
prioritrias que no usam os recursos compartilhados, quando as sees crticas
envolvidas no so pequenas.
O mtodo de Herana de Prioridade apresentado por [SRL90] corresponde a uma
soluo eficiente para tratar o problema de inverses de prioridades provocadas pelas
relaes de excluso. Nesse protocolo as prioridades deixam de ser estticas; toda vez
que uma tarefa menos prioritria bloqueia uma de mais alta prioridade em um recurso
compartilhado, a menos prioritria ascende prioridade da tarefa bloqueada mais
prioritria.
Descrio do Protocolo
O uso do Protocolo Herana de Prioridade (PHP) determina que as tarefas sejam
definidas possuindo uma prioridade nominal ou esttica, atribuda por alguma poltica
de prioridade fixa (RM, DM, etc.) e uma prioridade dinmica ou ativa derivada das
aes de bloqueio que ocorrem no sistema. Inicialmente, numa situao sem bloqueio
no sistema, todas as tarefas apresentam suas prioridades estticas coincidindo com suas
prioridades ativas. As tarefas so escalonadas tomando como base suas prioridades
ativas.
Quando uma tarefa Ti bloqueada em um semforo, sua prioridade dinmica ou
ativa transferida para a tarefa Tj que mantm o recurso bloqueado. Quando reassume,
Tj executa o resto de sua seo crtica com a prioridade herdada de Ti (pj = pi). Uma
tarefa herdada, ao se executar, sempre a mais alta das prioridades das tarefas que
mantenha sob bloqueio. No momento em que Tj ao completar sua seo crtica, libera o
semforo associado, a sua prioridade ativa retorna prioridade nominal ou assume a
mais alta prioridade das tarefas que ainda estejam sob seu bloqueio.
A aplicao do Protocolo Herana de Prioridade no exemplo anterior (da figura 2.9)
implica que T4 no mais sofrer de interferncias intermedirias (preempes de T2 e
T3) porque herda a prioridade de T1 em t=5 (figura 2.10). E, ao sair da sua seo crtica
(em t=7, figura 2.10), T4 volta ao nvel de sua prioridade original.
p 1 > p 2 > p 3 > p 4 b lo q u e io d ir e to p o r T 4
e x e c u ta n d o e m S C
T 2
T 3
b lo q u e io p o r h e r a n a
d e T 2 e T 3 p o r T 4
T 4
0 1 2 3 4 5 6 7 8 9 1 0 1 1 t
F ig u ra 2 .1 0 : E x e m p lo d o u s o d o P H P
Uma tarefa mais prioritria quando executando sob o PHP pode sofrer dois tipos de
bloqueios [But97]:
Bloqueio direto: que ocorre quando a tarefa mais prioritria tenta acessar o recurso
compartilhado j bloqueado pela tarefa menos prioritria.
Bloqueio por herana: ocorre quando uma tarefa de prioridade intermediria

impedida de continuar sua execuo por uma tarefa que tenha herdado a prioridade
de uma tarefa mais prioritria.
No exemplo da figura 2.10, as tarefas T2 e T3 sofrem bloqueios por herana em t =6
(T2 e T3 chegam em t = 6), e T1 est sujeita a um bloqueio direto em t = 5.
O PHP define um limite superior para o nmero de bloqueios que uma tarefa pode
sofrer de outras menos prioritrias. Se uma tarefa Ti pode ser bloqueada por n tarefas
menos prioritrias, isto significa que, em uma ativao, Ti pode ser bloqueada por n
sees crticas, uma por cada tarefa menos prioritria. Por outro lado, se houverem m
distintos semforos (recursos compartilhados) que podem bloquear diretamente Ti,
ento essa tarefa pode ser bloqueada no mximo a durao de tempo correspondente s
m sees crticas, sendo uma por cada semforo. Em [SRL90] ento assumido que sob
o Protocolo Herana de Prioridade, uma tarefa Ti pode ser bloqueada no mximo a
durao de min (n, m) sees crticas.
A ocorrncia de sees crticas aninhadas permite o surgimento de um terceiro tipo
de bloqueio: o transitivo. A figura 2.11, mostra quatro tarefas (T1, T2, T3 e T4) onde T2 e
T3 possuem sees aninhadas. T1 mostrada bloqueada por T2; por sua vez, a tarefa T2
bloqueada por T3 e, por fim, T3 bloqueada por T4. Nessa cadeia de bloqueios, a
tarefa T1 sofre um bloqueio indireto ou transitivo de T4. A tarefa T1 s retoma o seu
processamento quando houver a liberao, na seqncia, das sees crticas de T4, T3 e
T2, respectivamente. Bloqueios transitivos portanto, criam a possibilidade de que se
formem cadeias de bloqueios que podem levar at mesmo a situaes de deadlocks.
P rio rid a d e s : p 1 > p 2 > p 3 > p 4

b lo q u e io tr a n s itiv o :
T 4 h e rd a a p rio rid a d e d e T 1
S e e s C rtic a s :
T1
E x e c u ta n d o e m SC
T
T3
T4
0 1 2 3 4 5 6 7 8 9 10 11
t
F ig u ra 2 .1 1 : B lo q u e io tra n s itiv o
Extenses de Testes de Escalonabilidade Tomando como Base o PHP

Uma determinao precisa do valor de bloqueio mximo Bi que uma tarefa Ti pode
sofrer quando do uso do PHP certamente bem difcil, uma vez que, sees crticas de
tarefas menos prioritrias podem interferir com Ti atravs de diferentes tipos de
bloqueios. Dependendo da complexidade do modelo de tarefas, fica impraticvel a
determinao precisa de Bi. Alguns autores apresentam mtodos para estimativas desse
tempo de bloqueio ([BuW97], [But97] e [Raj91]). Um clculo mais preciso de Bi
envolve procuras exaustivas que considerando a complexidade do conjunto de tarefas
pode ser impraticvel.
O limite imposto pelo PHP no bloqueio mximo (Bi) que uma tarefa Ti pode sofrer
de tarefas menos prioritrias, tem que se refletir nas anlises de escalonabilidade de
esquemas baseados em prioridades fixas. Em [SRL90] e [SSL89] o teste do RM
(equao [2]) estendido no sentido de incorporar as relaes de excluso de um
conjunto de tarefas:
i C j Bi
[15 ]
1
+ i ( 2 i 1), i.
j =1 j
P Pi
O somatrio do teste acima considera a utilizao de tarefas com prioridade maior

ou igual a pi e o termo Bi /Pi corresponde utilizao perdida no bloqueio de Ti por
tarefas menos prioritrias. Para que um conjunto de n tarefas seja considerado
escalonvel pelo "Rate Monotonic", necessrio que as n condies geradas a partir
desse teste sejam verificadas.
ta r e f a s Ci Pi Bi
T1 6 18 2
T2 4 20 4
T3 10 50 0
T a b e la 2 .5
A tabela 2.5 apresenta um conjunto de tarefas peridicas com seus respectivos

bloqueios mximos quando executadas sob o PHP. O uso do teste [15] nesse conjunto
de tarefas implica nas relaes abaixo:
C1 B1
+ 1
P1 P1
C1 C2 B2
+ + 0 ,8 2
P1 P2 P2
C1 C2 C3
+ + 0 ,7 8
P1 P2 P3
Todas essas relaes acima se verificam para os valores de indicados na tabela 2.5;
o que indica que o conjunto escalonvel e todas as tarefas se executaro dentro de
seus "deadlines".
Uma outra variante desse teste onde a escalonabilidade pode ser verificada apenas
por uma equao s, tambm apresentado em [SRL90]:
n
Ci B B 1
+ m a x 1 , . . . . , n n . 2 n 1 .
1
[1 6 ]
i =1 Pi P Pn
O novo teste mais simples que o anterior porm mais restritivo e menos preciso.
Como exemplo, considere o uso do teste [16] na verificao da escalonabilidade do
mesmo conjunto de tarefas da tabela 2.5. A equao [16] aplicada s condies desse
mesmo conjunto implica em:
C1 C C B B 1
+ 2 + 3 + m a x 1 , 2 3 2 3 1
P1 P2 P3 P1 P2
onde, se substituirmos os valores da tabela 2.5, chegaremos a concluso que o conjunto

no escalonvel. Como esse teste mais restritivo, todo o conjunto descartado em
relao ao teste [16] deve ser verificado com o teste [15] no sentido de confirmar o
descarte. Porm o conjunto que passar pelo teste [16] certamente escalonvel.
Os testes para polticas de prioridades fixas, apresentados na seo 2.5, podem ser
facilmente estendidos no sentido de incluir os bloqueios que sofrem cada tarefa no
conjunto. O teste proposto em [LSD89] baseado em utilizao, na sua verso estendida
toma a seguinte forma, ([Fid98]) :
i t
P C j + Bi
j =1 j
U i (t ) = , i , min 0 < t Pi U i ( t ) 1. [17 ]
t
O bloqueio Bi nessa equao tambm apresentado como utilizao perdida no

bloqueio de Ti por tarefas menos prioritrias. O teste baseado em tempo de resposta
para modelos envolvendo "deadlines" arbitrrios apresentado em [TBW94] tambm
facilmente estendido:
Wi ( q ) + J j
W i ( q ) = ( q + 1) C i + B i +
j h p (i)
C j. [1 8 ]
Pj
O bloqueio Bi apresentado na equao [18] como uma interferncia sofrida por Ti.
Todos os testes apresentados com as extenses referentes ao limite mximo de bloqueio
definido sob o PHP, deixam de ser exatos e passam a ser condies suficientes. Isto
porque, o clculo de Bi conforme citado acima, no exato, refletindo um pessimismo
por vezes exagerado.
2.6.2 Protocolo de Prioridade Teto (Priority Ceiling Protocol)
A idia central no "Priority Ceiling Protocol" (PCP), introduzido em [SRL90],

limitar o nmero de bloqueios ou inverses de prioridades e evitar a formao de
cadeias de bloqueios e "deadlocks" em uma ativao de tarefa. O PCP dirigido para
escalonamentos de prioridade fixa, como o "Rate Monotonic". Esse protocolo uma
extenso do Protocolo Herana de Prioridade ao qual se adiciona uma regra de controle
sobre os pedidos de entrada em excluso mtua.
Em essncia, o PCP assegura no mximo uma inverso de prioridades por ativao.
Ou seja, se uma tarefa menos prioritria Tj tiver uma seo crtica executando em um
recurso compartilhado com Ti, ento nenhuma outra tarefa menos prioritria que Ti
conseguir entrar em seo crtica que possa tambm bloquear Ti. Essa regra evita
tambm que uma tarefa possa entrar em uma seo crtica se j houverem semforos
que podem lev-la a bloqueios.
Nesse protocolo, todas as tarefas apresentam tambm uma prioridade nominal ou
esttica, definida pelo RM. Uma prioridade ativa ou dinmica que incorpora o
mecanismo de herana do PHP, tambm usada para definir a incluso da tarefa nas
escalas em tempo de execuo. Sempre que uma tarefa menos prioritria bloquear uma
mais prioritria, sua prioridade ativa assume a prioridade da tarefa mais prioritria. A
herana de prioridades transitiva, ou seja, se uma tarefa menos prioritria T3 bloqueia

uma tarefa T2 de prioridade mdia e, por sua vez, T2 bloqueia uma tarefa mais
prioritria T1, ento T3 herda a prioridade de T1.
Todos os recursos acessados em excluso mtua possuem um valor de prioridade
teto (ceiling C(Sk)) que corresponde prioridade da tarefa mais prioritria que acessa
o recurso.
A regra que define as entradas ou no em sees crticas enunciada como se segue:
Uma tarefa s acessa um recurso compartilhado se sua prioridade ativa for maior que
a prioridade teto (ceiling) de qualquer recurso j previamente bloqueado. So
excludos dessa comparao recursos bloqueados pela tarefa requerente. Se Sl for o
semforo com maior prioridade teto entre todos os semforos bloqueados, ento uma
tarefa Ti s entrar em sua seo crtica se sua prioridade dinmica pi for maior que o
"ceiling" C(Sl). Se pi C(Sl) o acesso negado a Ti.
Quando nenhum recurso estiver bloqueado ento o acesso ao primeiro recurso ser
sempre permitido. A conseqncia do uso do Protocolo de Prioridade Teto (PCP) que
uma tarefa mais prioritria s pode ser bloqueada por tarefas menos prioritrias uma s
vez por ativao [SRL90].
O exemplo apresentado em [Kop92c] reproduzido aqui no sentido de ilustrar o
efeito do PCP sobre um conjunto de tarefas. As tarefas T1, T2 e T3 cujas evolues so
apresentadas na figura 2.12, acessam em excluso mtua os recursos R1, R2 e R3. A
prioridade teto de cada semforo definido segundo o compartilhamento dos recursos
indicado na figura: C(S1)=1, C(S2)=1 e C(S3)=2. Os eventos na evoluo das tarefas,
sinalizados na figura, so tambm descritos na prpria figura 2.12. Nesse exemplo, a
tarefa T1, em cada ativao, bloqueada no mximo uma vez por uma seo crtica de
uma tarefa menos prioritrio.
Alm dos bloqueios diretos e por herana, o PCP introduz uma outra forma de
bloqueio conhecida como bloqueio de "ceiling" onde uma tarefa fica bloqueada porque
no possui prioridade dinmica superior a maior prioridade teto dentre os recursos
ocupados. Esse bloqueio necessrio para evitar as cadeias de bloqueios e os
"deadlocks" [But97]. Na figura 2.12 a tarefa T1 sofre um bloqueio de "ceiling" no
tempo do evento 7.
O "Immediate Priority Ceiling Protocol (IPCP) uma verso do PCP cuja
finalidade principal a de apresentar um melhor desempenho. A herana de prioridade
no IPCP deixa de se dar quando a seo crtica bloqueia a tarefa mais prioritria. A
tarefa menos prioritria tem sua prioridade ativa elevada, assumindo logo no incio da
seo crtica a prioridade teto do recurso acessado [BuW97]. Uma conseqncia dessa
mudana que uma tarefa pode sofrer bloqueio somente no incio de sua execuo.
Uma vez que comece a executar, a tarefa ter todos os recursos que necessite para o seu
processamento. Sua execuo s poder ser postergada pelas interferncias de tarefas
mais prioritrias. O IPCP mais fcil de se implementar que o PCP e envolve menos
troca de contextos de tarefas. O "Priority Protect Protocol" apresentado nas
especificaes POSIX baseado no IPCP.
Prioridades : p1 > p2 > p 3 (com p1= 1, p 2 = 2 e p 3 = 3)
Semforos : S1 - S2 - S3 -
T1
T3
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
t
Eventos Descrio
1 T 3 comea sua execuo
2 T 3 entra em seo crtica (fecha o Semforo S 3 )
3 T 2 inicia seu processamento interrompendo T 3 (preempo de T 3).
4 T 2 sofre bloqueio direto: S 3 fechado por T 3 que reassume e herda prioridade de T 2.
5 T 3 entra na seo crtica aninhada ao fechar semforo S 2
6 T 1 inicia e interrompe T 3 . T 1 mais prioritria que T 3 com a prioridade herdada de T 2.
7 T 1 tenta fechar semforo S 1, bloqueado por ceiling; possui prioridade igual ao maior
ceiling de semforo j fechado pelas outras tarefas (C(S2 )=1).
8 T 3 libera semforo S 2 . T 1 reativado e interrompe T 3. T 1 entra em S1 .
9 T 1 libera S 1 .
10 T 1 fecha Semforo S2 .
11 T 1 libera S 2 .
12 T 1 termina e T 3 reassume na prioridade herdada de T 2 .
13 T 3 libera S 3 retornando a sua prioridade esttica. T2 interrompe T 3 e fecha S3 .
14,15,16,17 T 2 libera S 3 ; fecha e libera S 1 ; e completa. T 3 reassume e completa.
Figura 2.12: Exemplo de uso do PCP
Extenses de Testes de Escalonabilidade Tomando como Base o PCP

Os testes de escalonabilidade mostrados anteriormente quando da aplicao do
PHP sobre um conjunto de tarefas continuam vlidos na aplicao do Protocolo de
Prioridade Teto (PCP). A diferena est no valor limite de bloqueio mximo Bi que
pode experimentar uma tarefa Ti. No PCP esse valor limite corresponde a durao da
maior seo crtica de tarefas menos prioritrias que podem bloquear Ti. Logo, nas
equaes [16], [17] e [18], quando se considera o uso do PCP, Bi assume sempre o
valor da maior seo crtica que bloqueia Ti.

Uma seo crtica pertencente a uma tarefa Tj, guardada pelo semforo Sk e de
durao Dj,k pode bloquear por "ceiling" uma tarefa mais prioritria Ti se e somente se
[SRL90]: pi > pj e C(Sk) pi. O mximo bloqueio Bi que Ti pode sofrer dado pela
durao da maior seo crtica que pode bloquear por "ceiling" essa tarefa ([AuB90],
[But97]):
{
B i = m a x D j ,k
j ,k
(p j ) }
< p i (C ( S k ) p i ) .
ta r e f a s S1 S2 S3
ta r e f a T 1 1 1 0
ta r e f a T 2 1 0 1
ta r e f a T 3 0 4 8
T a b e la 2 .6
Para ilustrar o clculo de Bi sob o uso do PCP, considere a tabela 2.6 que descreve
as duraes de sees crticas (Dj,k) a partir de condies do problema apresentado na
figura 2.12. De acordo com a equao acima os bloqueios mximos por tarefas so
dados por:
B 1 = max (1,4) = 4
B 2 = max (8)= 8
B3 = 0
2.7 Tarefas Dependentes: Relaes de Precedncia
Em muitas aplicaes, alguns processamentos no podem ser executados em ordens

arbitrrias mas sim, em ordens previamente definidas, o que determina o surgimento de
relaes de precedncia entre tarefas do conjunto. As escalas produzidas devem
refletir as ordens parciais definidas atravs destas relaes.
Alguns autores preferem expressar as relaes de precedncia entre tarefas com o
uso de "offsets" [Aud93]. Neste caso, a tarefa sucessora de uma precedncia liberada
pela passagem do tempo (liberada por valor de tempo correspondente ao "offset" que
garante o tempo de resposta da predecessora). O uso de "offsets" pode representar em
sub-utilizao de recursos, uma vez que a sucessora sempre liberada por tempo em
situao de pior caso: um "offset" calculado para a pior situao possvel em termos
2.7 Tarefas Dependentes: Relaes de Precedncia 45
de tempo de resposta da tarefa predecessora.

Relaes de precedncia podem ser definidas atravs das necessidades de
comunicao e sincronizao entre as tarefas. As tarefas tipicamente, recebem
mensagens, executam seus processamentos e por fim, enviam seus resultados ou sinais
de sincronizao na forma de mensagens. Com isto, a liberao de uma tarefa sucessora
pode se dar por meio de mensagem [TBW94]. Uma conseqncia direta destas
liberaes por mensagem a existncia de "release jitters" nas liberaes de tarefas
sucessoras.
Conforme a tcnica usada para a liberao de sucessoras, seja por passagem de
tempo ou por mensagem, as relaes de precedncia so representadas nas anlises de
escalonabilidade, por valores de "offsets" ou de "jitters". Em ambos os casos, esses
valores devem garantir o pior caso de tempo de resposta da tarefa predecessora na
relao de precedncia. Ou seja, em termos de anlise de escalonabilidade, os dois
mtodos so equivalentes pois tanto "offsets" como "jitters" devem assumir valores que
garantam a execuo da predecessora no seu pior caso de tempo de resposta, antes da
liberao da sucessora. A diferena est em tempo de execuo; enquanto, a liberao
por passagem de tempo uma tcnica esttica onde o "offset" definido previamente,
impondo sempre o pior caso de liberao, a liberao por mensagem dinmica e o pior
caso de liberao eventualmente pode acontecer.
O conceito de atividade usado como a entidade encapsuladora de tarefas que se
comunicam e/ou se sincronizam. Cada atividade representada por um grafo orientado
acclico onde os nodos representam tarefas e os arcos identificam as relaes de
precedncia. As atividades so ditas sncronas (loosely synchronous activity) quando
as tarefas liberam suas sucessoras pelo envio de mensagens; no outro caso, onde a
liberao envolve "offsets", as atividades so identificadas como assncronas
(asynchronous activity) [BNT93]. Um exemplo de atividades assncronas pode ser
encontrada no sistema MARS [Kop97], onde as entidades encapsuladoras das tarefas
dependentes so identificadas como transaes e apresentam suas tarefas liberadas por
passagem de tempo no sentido de implementar as relaes de precedncia.
Na seqncia deste item, concentramos nossas descries em atividades sncronas
(liberaes por mensagem) para esquemas de prioridades fixas e nas relaes de
precedncia que, para efeito de anlise, so representadas como "jitters". Nessas
condies, o modelo de tarefas assume carga esttica e, portanto, uma aplicao
constituda por atividades peridicas. Cada atividade peridica Ai corresponde a uma
seqncia infinita de ativaes ocorrendo em intervalos regulares de tempo Pi (perodo
da atividade). Uma atividade Ai caracterizada por um "deadline" Di: limite mximo
associado concluso de todas as suas tarefas. As tarefas de uma mesma atividade
possuem os mesmos tempos de chegada, porm suas liberaes dependem dos tempos
de resposta de suas predecessoras.
A figura 2.13 mostra duas atividades: a primeira constituda de apenas uma tarefa T1
e uma segunda, formada pelas tarefas T2, T3 e T4. As relaes de precedncia nesta
segunda atividade implicam na ordem T2 T3 T4 2.
tarefas J i Ci Pi Di
T2
T1 1 10 40 40
T4 T2 3 10 80 25
T3 - 5 80 40
T4 - 10 80 80
T1 T3
Figura 2.13: Uma aplicao constituda por duas atividades
Quando se considera um grafo de precedncias (uma atividade), a maneira natural

de se atribuir prioridades seguindo as relaes do grafo com um decrscimo nas
prioridades das tarefas envolvidas, ou seja, as prioridades so decrescentes ao longo do
grafo de precedncias seguindo as orientaes dos arcos. Este tipo de atribuio,
respeitando as relaes de precedncia, se aproxima da poltica "Deadline Monotonic".
As comunicaes usando variveis compartilhadas conforme visto no item 2.6
podem levar a inverses de prioridades (bloqueios). Se a atribuio de prioridades
feita segundo as orientaes dos grafos e as liberaes de tarefa obedecem s relaes
de precedncia, diminuem as possibilidades de bloqueios e inverses de prioridades,
uma vez que as tarefas mais prioritrias so liberadas antes nas relaes de precedncia.
Considere como exemplo o conjunto de tarefas ilustrado na figura 2.13. Tomando as
relaes de precedncia e as restries temporais indicadas na figura, queremos
verificar a escalonabilidade do conjunto. A atribuio de prioridades feita segundo as
orientaes dos grafos; os ndices das tarefas representam as suas respectivas
prioridades (se Ti mais prioritria que Tj ento i < j).
O modelo introduzido coloca as atividades como sncronas o que implica em tratar
precedncias como "release jitters". Como as tarefas possuem "deadlines" relativos
menores que seus respectivos perodos, a verificao de escalonabilidade pode ser feita
usando as equaes [9] e [10] do item 2.5, onde os tempos de resposta so obtidos a
partir de :
Wi + J j
Wi = C i + Cj e R i = Wi + J i ,
j h p (i) Pj
2
As precedncias entre tarefas nas atividades podem ser expressas pela relao de ordem parcial
, definida sobre o conjunto de tarefas. Se Ti precede uma outra tarefa Tj (ou seja, Tj
sucessora de Ti), esta relao representada por TiTj, indicando que Tj no pode iniciar sua
execuo antes de Ti terminar. A relao transitiva.
2.7 Tarefas Dependentes: Relaes de Precedncia 47
onde a escalonabilidade verificada por : i Ri Di.

No clculo destes tempos devem ser consideradas as relaes de precedncia no
conjunto de tarefas. O teste acima permite a considerao de precedncias na forma de
"jitters". O valor de "jitter" de uma tarefa determinado a partir do tempo de resposta
mximo da sua predecessora (pior situao de liberao).
O conjunto de tarefas com relaes de precedncias, passa a ser tomado como um
conjunto de tarefas independentes com "jitters" associados. Mas as interferncias assim
calculadas, a partir de tarefas com "jitters" associados e tomadas como independentes,
resultam em tempos de respostas extremamente grandes e muitas vezes, irreais. Na
verdade, tarefas sujeitas a precedncias determinam cenrios mais restritos de
interferncia e bem distante do instante crtico [OlF97]. Por exemplo, na figura 2.13, a
tarefa T2 embora mais prioritria, no interfere com T3 e T4 porque ambas so liberadas
aps a sua concluso; a influncia de T2 sobre estas duas tarefas se d s na forma de
"jitter".
No caso da figura 2.13, T1 a mais prioritria e no sofre interferncia de outras
tarefas. O seu tempo de resposta dado por seu tempo de computao acrescentado
pelo "jitter" que sofre: R1 = C1+J1= 11. A tarefa T2 sofre interferncia s da tarefa T1 e
o seu tempo de resposta mximo calculado facilmente a partir das equaes [9] e [10]:
W 20 = C 2 = 1 0
10 + 1
W 21 = 1 0 + 10 = 20
4 0
20 + 1
W 22 = 1 0 + 10 = 20
4 0
Com W2 =20 e tomando J2=3, o valor do tempo de resposta dado por R2 = 23. A
tarefa T3, por sua vez, sofre interferncias de T1 e um "jitter" porque sua liberao
depende da concluso de T2 (J3 = R2):
W 30 = C 3 = 5
5 + 1
W 31 = 5 + 10 = 15
4 0
15 + 1
W 32 = 5 + 10 = 15
4 0
O tempo de resposta de T3 dado por: R3 = W3+J3 = 38. A tarefa T4, por sua vez,
sofre interferncias de T1 e T3 e um "jitter" de T2 (J4 = R2):
W 40 = C 4 = 10
10 + 1 10 + 23
W 41 = 1 0 + 10 + 5 = 25
4 0 8 0
25 + 1 25 + 23
W 42 = 1 0 + 10 + 5 = 2 5
4 0 80
A tarefa T4 tem o seu pior tempo de resposta portanto em 48 (R4=W4+J4). Se

compararmos os tempos de resposta encontrados com os "deadlines' relativos das
respectivas tarefas na figura 2.13, verificamos que as tarefas so escalonveis..
No modelo de tarefas apresentado, as relaes de precedncia so implementadas a
partir de ativaes por mensagens. Os tempos em comunicaes locais nos modelos de
tarefas ideais so desconsiderados; em situaes reais, tempos no desprezveis podem
ser adicionados aos tempos de computao das tarefas predecessoras (emissoras de
mensagens), aproximando ento o modelos reais de premissas de tempos nulos em
comunicaes locais.
Os clculos de tempos de resposta em ambientes distribudos, envolvendo
precedncias, no muito explorado na literatura [Fid98]. As atividades nestes
ambientes se estendem por vrios ns (vrios domnios de escalonamento local) o que
implica em precedncias remotas. Estas situaes exigem consideraes especiais.
Solues para problemas distribudos devem se basear na assim chamada holistic
schedulability analisys para sistemas de tempo real distribudos [TiC94]: O "release
jitter" de uma mensagem depende do pior caso de tempo de resposta da tarefa emissora.
O pior caso de tempo de resposta de uma tarefa receptora depende do tempo de resposta
de suas mensagens.
2.8 Escalonamento de Tarefas Aperidicas
Todas as tcnicas de escalonamento apresentadas at este item eram dirigidas para

modelos de tarefas peridicas. Mas aplicaes de tempo real, de um modo geral,
envolvem tanto tarefas peridicas como aperidicas. Examinamos neste item o
escalonamento de tarefas aperidicas em abordagens mistas, envolvendo tarefas crticas
e no crticas. As tarefas peridicas so assumidas como crticas, necessitando de
garantias em tempo de projeto para condies de pior caso. As tarefas aperidicas
podem envolver diferentes requisitos temporais: crticos, no crticos ou ainda sem
requisitos temporais.
As aperidicas apresentando um mnimo intervalo entre suas ativaes e um
"deadline hard" so identificadas como tarefas espordicas, possuindo um
comportamento temporal determinista o que facilita, portanto, a obteno de garantias
em tempo de projeto. As tarefas aperidicas que no possuem seus tempos de chegada
conhecidos e tambm no se caracterizam por um intervalo mnimo entre suas
ativaes, definem o que se pode chamar de uma carga computacional dinmica. Com
estas ltimas tarefas possvel a obteno de garantias dinmicas ou, ainda, usar
tcnicas de melhor esforo no sentido de execut-las segundo as disponibilidades do
2.8 Escalonamento de Tarefas Aperidicas 49
processador em tempo de execuo. As aperidicas que apresentam "deadlines hard" e

necessitam de garantias dinmicas em seus escalonamentos so chamadas de tarefas
aperidicas "firm". As tarefas aperidicas com requisitos no crticos ("deadline soft") e
as sem requisitos temporais (aplicaes no de tempo real) necessitam apenas de bons
tempos de resposta.
Num quadro misto, uma questo que pode ser colocada est ligada ao tipo de
poltica adequado para tarefas peridicas e que possa ser estendido para carga dinmica:
so as polticas de prioridade fixa (RM, DM e etc.) ou polticas de prioridade dinmica
(EDF) as mais apropriadas? As polticas baseadas em prioridade fixa foram sempre as
preferidas para esquemas mistos de escalonamento. Embora apresentem melhor fator de
utilizao, se comparado com esquemas de prioridade fixa, as polticas de prioridade
dinmica como o EDF eram consideradas por alguns autores at pouco tempo como
instveis para tratar com carga dinmica [SSL89]. Nos ltimos anos, a direo dos
trabalhos tem mudado e o EDF tem sido tambm alvo de extenses para
escalonamentos mistos. Os algoritmos dinmicos apresentam os mais altos limites de
escalonabilidade o que permite uma maior utilizao do processador o que, por sua vez,
aumenta a capacidade de processamento da carga aperidica.
As sobras de processador nas escalas so importantes para o escalonamento de
tarefas aperidicas em modelos hbridos. Existem dois tipos de abordagens para a
determinao de sobras de processador: as solues baseadas em servidores [SSL89] e
as baseadas em tomadas de folgas (slack stealing) [DtB93], [LeR92]. Neste texto so
apresentadas unicamente tcnicas de escalonamento para tarefas aperidicas baseadas
no conceito de servidor. Os escalonamentos hbridos neste captulo so construdos com
polticas de prioridade fixa [SSL89]. No Anexo A so apresentados escalonamentos
mistos usando polticas de prioridade dinmica [SpB96].
2.8.1 Servidores de Prioridade Fixa [LSS87, SSL89]
As tcnicas examinadas nesse item so para polticas baseadas em prioridades fixas,

mais precisamente, o "Rate Monotonic". As sobras nas escalas de carga peridica, so
determinadas estaticamente, em tempo de projeto, e posteriormente, em tempo de
execuo, so atribudas ao processamento aperidico usando o conceito de servidor.
Servidor de "Background"
Este servidor extremamente simples. A idia central corresponde em atender as
requisies aperidicas quando a fila de prontos envolvendo tarefas peridicas est
vazia, ou seja, se tarefas peridicas no esto se executando ou pendentes, o
processador entregue para a carga aperidica.
A determinao de prioridades nesta abordagem feita atribuindo - segundo o RM -
as prioridades mais altas para as tarefas peridicas. As prioridades mais baixas so
destinadas para as tarefas aperidicas. Como conseqncia, o "Background Server"
(BS) apresenta tempos de resposta muito altos para cargas aperidicas. Se a carga
envolvendo as tarefas peridicas alta, ento a utilizao deixada para o servio de
"Background" baixa ou no freqente.
ta r e f a s Ci Pi Di pi ta r e f a A -
ta r e f a p e r i d ic a A 4 10 10 1
ta r e f a p e r i d ic a B 8 20 20 2 ta r e f a B -
ta r e f a a p e r i d ic a C 1 - - 3
ta r e f a a p e r io d ic a D 1 - - 3 ta r e f a C -
ta r e f a D -
A ,B C A D A ,B
0 2 4 6 8 10 12 14 16 18 20 22 24 t
F ig u r a 2 .1 4 : S e r v id o r a d e B a c k g r o u n d
A figura 2.14 ilustra um exemplo introduzido em [SSL89] onde duas tarefas

peridicas e duas requisies aperidicas so executadas usando uma atribuio de
prioridades RM. Com base no teste do RM, a carga peridica tem garantia em tempo de
projeto pois a sua utilizao no passa o limite de 0,828 (equao [2], item 2.4). As
requisies C e D so executadas no fim da escala da figura 2.16, depois que a carga
peridica foi completada.
O BS bastante simples na sua implementao, porm s aplicvel quando as
requisies aperidicas no so crticas e a carga peridica no alta.
"Polling Server"
O esquema do "Polling Server" (PS) consiste na definio de uma tarefa peridica
para atender a carga aperidica [SSL89]. Um espao aberto periodicamente na escala
para a execuo da carga aperidica, atravs da tarefa Servidora de "Polling". A tarefa
servidora possui um perodo PPS e um tempo de computao CPS e, como as outras
tarefas da carga peridica do sistema, tem a sua prioridade atribuda segundo o "Rate
Monotonic". Em cada ativao, a tarefa servidora executa as requisies aperidicas
pendentes dentro do limite de sua capacidade CPS o tempo destinado para o
atendimento de carga aperidica em cada perodo da servidora.
Quando no houver requisies aperidicas pendentes, a tarefa PS se suspende at a
sua nova chegada, no prximo perodo. Neste caso, a sua capacidade CPS entregue
para a execuo de tarefas peridicas pendentes. Se um pedido aperidico ocorre logo
depois da suspenso da tarefa servidora, o pedido deve aguardar at o incio do prximo
perodo da tarefa PS.
tarefas Ci Pi Di pi tarefa A -
tarefa peridica A 4 10 10 3
tarefa peridica B 8 20 20 2 tarefa B -
tarefa servidora PS 1 5 - 1
tarefa aperidica C 1 - - - tarefa C -
tarefa aperiodica D 0,5 - - -
tarefa D -
A ,B C A D A ,B
0 2 4 6 8 10 12 14 16 18 20 22 24 t
C PS
0 5 6 10 15 16 20
F igura 2.15: A lgortm o P olling Server
O mesmo exemplo usado com o BS mostrado na figura 2.15 onde a carga

aperidica escalonada segundo o algoritmo PS. Nesse caso, a tarefa servidora criada
com capacidade CPS de uma unidade e o perodo PPS de 5 unidades. Na ativao da
servidora em t=0 no existe carga aperidica e a sua capacidade entregue para a
execuo das tarefas peridicas. Em t = 5, a chegada de uma requisio aperidica C
coincide com a chegada da servidora PS. Com isto, a capacidade CPS consumida
totalmente at t = 6. No perodo seguinte da servidora (t = 10), novamente no existe
carga aperidica pendente e a capacidade da servidora, que foi restaurada no seu
mximo no incio deste perodo, entregue a carga peridica. A servidora, por no estar
mais ativa, no atende a segunda requisio aperidica D que chega em t=12. No incio
de seu perodo seguinte (em t=15), esta requisio executada, consumindo a metade
da capacidade da servidora, conforme mostra a figura.
A interferncia da tarefa servidora sobre o conjunto de tarefas peridicas do sistema
no pior caso igual a interferncia causada por uma tarefa com tempo de computao
CPS e perodo PPS ou seja, dada a utilizao do PS, a escalonabilidade do conjunto
peridico garantido por :
n
+ P S (n + 1) 2 1 ,
Ci C

1
( n + 1)
i =1 Pi PP S
U P ( n + 1) 2 1 + U S .
1
ou seja ( n + 1)
A abordagem do "Polling Server", se comparada com a abordagem BS, melhora o

tempo de resposta mdio de tarefas aperidicas. O PS porm no fornece servio de
resposta imediato para processamentos aperidicos. O tempo de resposta de requisies

aperidicas depende do perodo e da capacidade da tarefa servidora.
"Deferrable Server"
O "Deferrable Server" (DS) tambm baseado na criao de uma tarefa peridica
que no conjunto de tarefas da carga esttica, recebe uma prioridade segundo uma
atribuio RM. Ao contrrio do PS, o DS conserva a sua capacidade tempo destinado
para o processamento aperidico mesmo quando no existir requisies durante a
ativao da tarefa DS. Requisies no peridicas podem ser atendidas no nvel de
prioridade da tarefa servidora, enquanto a sua capacidade CDS no se esgotar no perodo
correspondente. No incio de cada perodo da tarefa servidora, a sua capacidade
processamento restaurada.
Por preservar sua capacidade, a abordagem DS fornece melhores tempos de resposta
para as tarefas aperidicas que o "Polling Server". Como a tarefa servidora usualmente
executa na prioridade mais alta do conjunto peridico, se a capacidade for suficiente, o
atendimento de requisies aperidicas imediato.
ta re fa s Ci Pi Di pi
t a r e fa A -
t a r e fa p e r i d i c a A 4 10 10 3
t a r e fa B -
t a r e fa p e r i d i c a B 8 20 20 2
t a r e fa s e r v i d o r a P S 1 5 - 1 t a r e fa C -
t a r e fa a p e r i d i c a C 1 - - -
t a r e fa D -
t a r e fa a p e r i o d i c a D 0 ,5 - - -
A ,B C A D A ,B
0 2 4 6 8 10 12 14 16 18 20 22 24 t
C DS
0 5 6 10 12 15 20
F ig u r a 2 .1 6 : A lg o r t m o D e fe r r a b le S e r v e r
A figura 2.16 ilustra o uso do algoritmo DS no escalonamento da carga aperidica

com o mesmo exemplo introduzido em [SSL89]. Neste exemplo criada uma tarefa
servidora com capacidade CDS=1 e de perodo PDS = 5. Na ativao da servidora em
t=0 no existe carga aperidica e a sua capacidade preservada durante todo o perodo
PDS. Em t=5, a chegada de uma requisio aperidica C coincide com a chegada da
servidora DS, o que determina o consumo total da capacidade da servidora at t=6
(figura 2.16). No perodo seguinte da servidora (t=10), a capacidade CDS novamente

preenchida ao seu mximo. Este valor de capacidade se mantm at a chegada da
requisio aperidica D em t=12 que ento consome 0,5 da capacidade da servidora at
t=12,5. No incio do perodo seguinte da servidora (t=15), a sua capacidade volta ao
seu valor mximo (CDS=1). A figura 2.16 confirma sobre o mesmo exemplo usado nas
tcnicas anteriores, o melhor desempenho do servidor DS sobre os anteriores em termos
de tempo de resposta e servio de resposta imediata.
Quando usando a poltica RM, a influncia da tarefa servidora DS sobre a utilizao
da carga peridica no pode ser determinada de maneira to simples como no caso do
PS. O comportamento da servidora com a prioridade mais alta, podendo se executar em
qualquer ponto do seu perodo no captada pelo teste do RM (equao [2], item 2.4).
Nas condies do teste original do RM, a tarefa peridica de mais alta prioridade
necessita executar em seu tempo de chegada; qualquer atraso pode prejudicar as tarefas
menos prioritrias. Em [SSL89], derivada do ajuste no teste do RM para captar o
comportamento singular da servidora DS, apresentada uma relao entre a utilizao
da servidora e a utilizao da carga peridica:
U +2
U P ln DS . [19]
2U DS + 1
A equao [19] vlida somente para um muito grande nmero de tarefas

peridicas no sistema.
Servidor Troca de prioridade (Priority Exchange Server)

Uma outra tcnica de escalonamento apresentada em [LSS87] e [SSL89] para o
processamento de requisies aperidicas em escalonamento hbrido o "Priority
Exchange Server" (PE). Diferentemente do DS, neste servidor, diante da ausncia de
requisies aperidicas, a capacidade de processamento aperidico CPE (tempo de
computao da tarefa servidora) preservada executando trocas de prioridades da
servidora com tarefas peridicas pendentes. No ser discutido neste texto o algoritmo
do PE devido a pouca possibilidade de aplicao deste servidor ligada complexidade
do mecanismo de troca de prioridades. Os leitores interessados podem encontrar
informaes sobre este servidor nas indicaes bibliogrficas acima.
Servidor Espordico
O "Sporadic Server" (SS), a exemplo dos algoritmos DS e PE, outra tcnica
introduzida em [SSL89] que apresenta bons tempos de resposta e de servio imediato
para requisies aperidicas. Com caractersticas semelhantes a dos anteriores, foi
introduzido para possibilitar a execuo de tarefas aperidicas com restries crticas.
O SS cria uma tarefa peridica que atua em um s nvel de prioridade para executar
requisies aperidicas. Para entender o funcionamento do algoritmo do SS
necessrio que se introduza alguns termos:
ps : corresponde ao nvel de prioridade em execuo no processador;
pi : um dos nveis de prioridades do sistema.
Intervalo Ativo : uma prioridade pi dita em um intervalo ativo quando

pi ps.
Intervalo de Prioridade Desativada: uma prioridade pi dita desativada

quando pi > ps.
Tempo de Preenchimento RTi : define o instante de tempo em que se d a

restaurao da capacidade consumida durante o intervalo em que a
prioridade pi estava ativa.
A tarefa servidora no SS preserva sempre a sua capacidade no nvel em que foi
projetada. Mas difere das outras abordagens anteriores na forma do preenchimento de
sua capacidade:
Se a servidora tem seu tempo computao (capacidade) consumido em um

de seus perodos, o preenchimento correspondente ocorrer no seu tempo
de preenchimento (RTi) que determinado adicionando o valor do
perodo da servidora ao tempo de incio do intervalo onde pi era ativo e
ocorreu o consumo considerado.
A quantidade a ser preenchida igual a capacidade do servidor consumida

no intervalo ativo.
A figura 2.17 apresenta um exemplo de um escalonamento hbrido com um servidor
espordico possuindo prioridade mdia no conjunto de tarefas peridicas. Neste
exemplo tambm apresentado em [SSL89], a tarefa servidora SS definida com
capacidade CSS=2,5 e perodo PSS=10. Em t=0, a tarefa A (a mais prioritria) comea a
executar. A prioridade ps em execuo (ps = pA) ento maior que a prioridade da
servidora SS (pSS); o que define o primeiro intervalo ativo da servidora SS nesta
execuo de A (pSS< pA). Neste intervalo no ocorre consumo de capacidade CSS devido
a ausncia de requisies aperidicas.
Em t=4,5 uma requisio aperidica C chega e como a tarefa SS mais prioritria
que B (tarefa em execuo), ocorre a preempo da tarefa peridica. O consumo da
capacidade da servidora por parte de C vai at t = 5 quando, pela chegada da tarefa
peridica A, ocorre a interrupo da tarefa aperidica C. Pelo RM a tarefa A a mais
prioritria. Concluda esta ativao de A, a tarefa C reassume. Em t = 6,5 o
processamento aperidico C concludo. O tempo de preenchimento (RTi), referente ao
consumo de capacidade por parte da requisio C, programado considerando o
intervalo ativo correspondente (pSS ps) que, neste caso, inicia com a chegada da
requisio aperidica (t = 4,5). Portanto, como pode ser visto na figura 2.17, o
preenchimento da capacidade consumida neste intervalo ocorre em t=14,5
(RTi=ta+PSS). A preempo de C pela tarefa A em t = 5 no define dois intervalos
ativos da servidora para as duas partes de C da figura 2.17. Na verdade, um mesmo
intervalo ativo se mantm durante as execues de C e A porque, entre os tempos t=4,5
e t = 6,5, a condio pSS ps se mantm como vlida.
tarefa A - ta refa s Ci Pi Di pi
tarefa p e ri d ic a A 1 5 5 1
tarefa B - tarefa p e ri d ic a B 6 14 14 3
tarefa serv id o ra S S 2 ,5 10 - 2
tarefa C - tarefa ap eri d ica C 1 - - -
tarefa ap erio d ica D 1 - - -
tarefa D - C D
A B A A B A A
0 2 4 6 8 10 12 14 16 18 20 22 24 t
C SS
3
2
1
0 2 4 5 6 8 10 12 14 16 18 20
F ig u ra 2 .1 7 : A lg o rtm o S p o rad ic S erv er
Uma outra requisio aperidica (tarefa D) chega em outro intervalo ativo da

servidora SS. A requisio D tambm interrompe a tarefa B e consome uma unidade de
CSS. O tempo de incio do intervalo ativo de D coincide com a sua chegada e, portanto, o
tempo de preenchimento (RTi) correspondente deve ocorrer em t=18.
A tarefa servidora SS no apresenta um comportamento convencional de tarefa
peridica, uma vez que, a capacidade desta servidora preservada no mesmo nvel
como o DS e a sua execuo postergada at a ocorrncia de uma requisio
aperidica. Porm em [SSL89], provado que a tcnica de preenchimento da
capacidade da servidora compensa este comportamento no convencional, permitindo
que, em termos de anlise de escalonabilidade, esta tarefa possa assumir um
comportamento peridico. Ou seja, a servidora SS pode ser substituda no teste do RM
([2] no item 2.4) por uma tarefa peridica com perodo PSS e tempo de computao CSS.
A limitao que a servidora SS impe sobre uma carga peridica dada por :
2
U ln . [2 0 ]
P
U SS + 1
A equao [20] idntica obtida para o servidor PE e tambm s vlida para um

nmero muito grande de tarefas peridicas no sistema.
A tabela 2.7 mostra um exemplo de comparao das utilizaes dos servidores DS,
PE e SS quando envolvidos com uma mesma carga peridica ([SSL89]). O algoritmo
SS possui a simplicidade do DS e a vantagem da maior capacidade do PE para o
processamento de requisies aperidicas. Porm, diferente destes outros algoritmos, o
SS pode tambm ser usado na garantia em tempo de projeto.
ta r e f a s C i P i U i (% )
ta r e f a 1 2 10 2 0 ,0
ta r e f a 2 6 14 4 2 ,9
se rv id o r D S 1 ,0 0 5 2 0 ,0
se rv id o r P E 1 ,3 3 5 2 6 ,7
se rv id o r S S 1 ,3 3 5 2 6 ,7
T a b e la 2 .7 : U tiliz a o d o s s e r v id o re s D S , P E e S S
Na verdade, o SS foi introduzido com o objetivo de garantir a execuo de tarefas

espordicas um caso especial de aperidicas onde existe um limite conhecido como o
mnimo intervalo entre ativaes (mini). Os "deadlines" associados a estas tarefas so
crticos ("hard") e, portanto, precisam de uma garantia em tempo de projeto. Esta
garantia pode ser obtida criando uma servidora SS para tratar exclusivamente uma
tarefa espordica nas suas diversas ativaes. A servidora SS assume os "deadlines" das
requisies da tarefa associada. O perodo PSS, por sua vez, deve ser no mximo igual
ao intervalo mnimo entre ativaes da tarefa espordica (mini). Esta tarefa servidora
conserva a capacidade de processamento aperidico no seu nvel de prioridade at a
ocorrncia de uma requisio espordica. A capacidade CSS da servidora deve ser
suficiente para atender as necessidades de tempo de computao da tarefa espordica
associada, em cada uma de suas ativaes. Nestas condies, os "deadlines" crticos
podem ser garantidos em tempo de projeto.
O algoritmo SS pode ser usado para garantir tarefas espordicas apresentando
"deadlines" relativos (Di) iguais ou menores que os seus respectivos intervalos
mnimos entre ativaes (mini). Nos casos onde os "deadlines" relativos so iguais aos
respectivos intervalos mnimos, as prioridades da tarefa servidora SS e da carga
peridica so determinadas seguindo uma atribuio RM e as escalas so produzidas
usando os mesmos algoritmos citados acima.
Para os casos onde tarefas espordicas apresentam Di < mini a atribuio RM no
pode ser usada; necessria uma outra atribuio de prioridades que no seja mais
baseada na freqncia de chegada das tarefas peridicas. A figura 2.18 ilustra um
exemplo de uma escala com atribuio RM onde ocorre uma sobrecarga com perda de
"deadline" da tarefa aperidica C em t=10. Neste exemplo, a servidora SS que possui o
"deadline" relativo mais restritivo (DSS=10) apresenta o maior perodo (PSS=32) e
portanto a menor prioridade segundo o RM.
ta re fa s Ci Pi Di M in i pi t a r e fa A -
t a r e fa p e r i d i c a A 4 12 12 - 1
t a r e fa B -
t a r e fa p e r i d i c a B 4 20 20 - 2
t a r e fa C -
t a r e fa s e r v i d o r a S S 8 32 10 - 3
t a r e fa a p e r i d i c a C 8 - 10 32 -
A ,B ,C A B
dC
0 2 4 6 8 10 12 14 16 18 20 22 24 t
F ig u r a 2 . 1 8 : S e r v id o r S S e R M u s a d o s e m c a r g a a p e r i d ic a c o m D i = M i n i
Nos casos de tarefas espordicas com Di<mini, so necessrias polticas que sejam
dirigidas por "deadlines", permitindo ento a atribuio do mais alto nvel de prioridade
servidora SS associada. A poltica de atribuio esttica "Deadline Monotonic" a
mais apropriada nestes casos. Na figura 2.19 uma escala mostrada com o mesmo
conjunto de tarefas sujeito a uma atribuio DM de prioridades e onde todos os
"deadlines" so respeitados. A tarefa C se executa em t=0 (a servidora SS a tarefa
mais prioritria) e, o preenchimento da capacidade consumida correspondente ocorre
em t=32, portanto, antes de esgotado o intervalo mnimo entre ativaes de C (minC).
ta r efa A -
ta re fa s Ci Pi Di M in i pi
ta r efa B - ta r efa p er i d ica A 4 12 12 - 2
ta r efa p er i d ica B 4 20 20 - 3
ta r efa C -
ta r efa ser v id o r a S S 8 32 10 - 1
ta r efa a p er id ica C 8 - 10 32 -
A ,B ,C A B
dC
0 4 8 12 16 20 24 28 32
t
CSS
0 4 8 12 16 20 24 28 32
F ig u ra 2 .1 9 : S e rvid o r S S e D M u sad o s e m c arg a a p e ri d ic a co m D i < M in i

2.8.2 Consideraes sobre as Tcnicas de Servidores
Algumas das premissas assumidas para os servidores seguiram modelos de tarefas

originais dos algoritmos de escalonamento usados, mas isto no limita o uso destas
tcnicas de servidores. Os algoritmos de servidores apresentados neste texto podem ser
usados em modelos com tarefas peridicas possuindo "deadlines" relativos arbitrrios e
com recursos compartilhados. Neste caso a anlise de escalonabilidade deve levar em
considerao as particularidades do modelo de tarefas usado.
Neste texto, as requisies aperidicas foram apresentadas como processamentos
sem prazos ("deadlines"), escalonadas segundo abordagens de melhor esforo usando
polticas FIFO. Tarefas aperidicas podem possuir restries temporais e serem
ordenadas segundo estas restries com polticas diferentes das que conduzem a
ordenao das peridicas no escalonamento hbrido. As tarefas aperidicas necessitando
a cada ativao de uma garantia dinmica so identificadas como tarefas firmes (item
2.8). Neste caso, um teste de aceitao necessrio para verificar a escalonabilidade da
tarefa aperidica recm chegada junto com as tarefas previamente garantidas. Se o teste
falha a tarefa aperidica descartada. Em [But97] discutido essa verificao de
tarefas firmes. Os algoritmos PS, PE e DS so apropriados na verificao dinmica da
escalonabilidade de tarefas aperidicas firmes. O servidor SS, por sua vez, permite o
tratamento de tarefas espordicas que necessitam de garantias em tempo de projeto para
os seus "deadlines hard".
2.9 Concluso
Em sistemas onde as noes de tempo e de concorrncia so tratadas explicitamente,

conceitos e tcnicas de escalonamentos formam o ponto central na previsibilidade do
comportamento de sistemas de tempo real. Esse captulo se concentrou sobre tcnicas
para escalonamentos dirigidos a prioridades. Essa escolha na abordagem de
escalonamento porque a mesma cobre diversos aspectos de possveis comportamentos
temporais em aplicaes de tempo real e, tambm, devido a importncia da literatura
disponvel.
Vrios problemas de escalonamento que podem ser vistos como extenses aos
problemas propostos em [LiL73] foram examinados neste captulo. Particularmente,
foram apresentados escalonamentos de tarefas peridicas com "deadlines" arbitrrios,
o compartilhamento de recursos e a implementao de relaes de precedncia. As
tarefas aperidicas so escalonadas usando escalonamentos hbridos baseados no
conceito de servidor. Todos estes problemas foram discutidos usando atribuies de
prioridades fixas neste captulo. Estes mesmos problemas so revistos com polticas de
prioridade dinmica no Anexo A. Escalonamentos com atribuies dinmicas como os
definidos pelo EDF, embora determinem uma maior utilizao apresentam sempre uma
complexidade maior em tempo de execuo.
2.9 Concluso 59
A grande difuso de suportes (ncleos, sistemas operacionais), na forma de

produtos, que baseiam seus escalonamentos em mecanismos dirigidos a prioridade
sem dvida uma forte justificativa para o uso das tcnicas apresentadas neste captulo
em problemas prticos. Alguns dos algoritmos apresentados nesse captulo so
recomendados por entidades de padronizao como a POSIX e a OMG ("Object
Management Group" [OMG98]).
Leituras complementares recomendadas referente ao assunto tratado neste captulo
so encontradas em: [AuB90], [Bak91], [Fid98], [RaS94], [SRL90], [SSL89], [Spu96],
[TBW94].
Captulo 3
Suportes para Aplicaes de Tempo Real
Em geral, aplicaes so construdas a partir dos servios oferecidos por um sistema

operacional. No caso das aplicaes de tempo real, o atendimento dos requisitos
temporais depende no somente do cdigo da aplicao, mas tambm da colaborao
do sistema operacional no sentido de permitir previsibilidade ou pelo menos um
desempenho satisfatrio. Muitas vezes os requisitos temporais da aplicao so to
rigorosos que o sistema operacional substitudo por um simples ncleo de tempo real,
o qual no inclui servios como sistema de arquivos ou gerncia sofisticada de
memria. Ncleos de tempo real oferecem uma funcionalidade mnima, mas so
capazes de apresentar excelente comportamento temporal em funo de sua
simplicidade interna.
Este captulo discute aspectos de sistemas operacionais cujo propsito suportar
aplicaes de tempo real. O objetivo inicial estabelecer as demandas especficas das
aplicaes de tempo real sobre o sistema operacional e definir a funcionalidade mnima
que vai caracterizar os ncleos de tempo real. Tambm so apresentadas algumas
solues existentes no mercado. Uma questo importante a ser discutida a capacidade
dos sistemas operacionais de serem analisados com respeito a escalonabilidade, como
discutido no captulo anterior.
3.1 Introduo
Assim como aplicaes convencionais, aplicaes de tempo real so mais facilmente

construdas se puderem aproveitar os servios de um sistema operacional. Desta forma,
o programador da aplicao no precisa preocupar-se com a gerncia dos recursos
bsicos (processador, memria fsica, controlador de disco). Ele utiliza as abstraes de
mais alto nvel criadas pelo sistema operacional (tarefas, segmentos, arquivos).
Sistemas operacionais convencionais encontram dificuldades em atender as
demandas especficas das aplicaes de tempo real. Fundamentalmente, sistemas
operacionais convencionais so construdos com o objetivo de apresentar um bom
comportamento mdio, ao mesmo tempo que distribuem os recursos do sistema de
forma eqitativa entre as tarefas e os usurios. Em nenhum momento existe uma
preocupao com previsibilidade temporal. Mecanismos como caches de disco,
memria virtual, fatias de tempo do processador, etc, melhoram o desempenho mdio
do sistema mas tornam mais difcil fazer afirmaes sobre o comportamento de uma
62 3. Suportes para Aplicaes de Tempo Real
tarefa em particular frente s restries temporais.

Aplicaes com restries de tempo real esto menos interessadas em uma
distribuio uniforme dos recursos do sistema e mais interessadas em atender requisitos
tais como perodos de ativao e "deadlines".
O atendimento de tais requisitos, em geral, demanda cuidados na gerncia dos
recursos do sistema que no so tomados em sistemas operacionais convencionais. Um
exemplo claro o conceito de "inverso de prioridade" (ver captulo 2), o qual muito
importante no contexto de tempo real mas completamente ignorado em sistemas
operacionais convencionais.
Sistemas operacionais de tempo real ou SOTR so sistemas operacionais onde
especial ateno dedicada ao comportamento temporal. Em outras palavras, so
sistemas operacionais cujos servios so definidos no somente em termos funcionais
mas tambm em termos temporais. Estes aspectos sero discutidos na seo 3.3.
Alm do aspecto temporal, algumas funcionalidades especficas so normalmente
exigidas em um SOTR. Estas exigncias decorrem do fato da maioria das aplicaes de
tempo real serem construdas como programas concorrentes. Logo, imperativo que o
SOTR fornea as abstraes necessrias, isto , tarefas e mecanismos para comunicao
entre tarefas. A seo 3.2 discute os aspectos funcionais dos SOTR.
Neste contexto importante notar a diferena entre plataforma alvo ("target
system") e plataforma de desenvolvimento ("host system"). A plataforma alvo inclui o
hardware e o SOTR onde a aplicao vai executar quando concluda. Por exemplo,
pode ser o computador embarcado em um telefone celular. A plataforma de
desenvolvimento inclui o hardware e o SO onde o sistema desenvolvido, isto , onde
as ferramentas de desenvolvimento executam. Normalmente trata-se de um computador
pessoal executando um sistema operacional de propsito geral (SOPG). Um SOPG
neste caso permite um melhor e mais completo ambiente de desenvolvimento, pois
tipicamente possui mais recursos do que a plataforma alvo (que tal desenvolver
software no prprio telefone celular ?). Entretanto, a depurao exige o SOTR e as
caractersticas da plataforma alvo. Tipicamente a plataforma de desenvolvimento
usada enquanto for possvel, sendo as etapas finais de depurao realizadas na
plataforma alvo. Em qualquer caso, o objetivo deste captulo analisar sistemas
operacionais de tempo real unicamente no papel de plataforma alvo.
3.2 Aspectos Funcionais de um Sistema Operacional

Tempo Real
Como qualquer sistema operacional, um SOTR procura tornar a utilizao do

computador mais eficiente e mais conveniente. A utilizao mais eficiente significa
mais trabalho obtido a partir do mesmo hardware. Isto obtido atravs da distribuio
dos recursos do hardware entre as tarefas. Uma utilizao mais conveniente diminui o
3.2 Aspectos Funcionais de um Sistema Operacional Tempo Real 63
tempo necessrio para a construo dos programas. Isto implica na reduo do custo do
software, na medida em que so necessrias menos horas de programador. Por exemplo,
atravs de funes que simplificam o acesso aos perifricos, escondendo os detalhes do
hardware, ou ainda funes que gerenciam o espao em disco ou na memria principal,
livrando o programador da aplicao deste trabalho.
Em geral, as facilidades providas por um sistema operacional de propsito geral so
bem vindas em um SOTR. O objetivo deste captulo no descrever sistemas
operacionais em geral, mas sim tratar dos servios que so fundamentais para um
SOTR. Desta forma, esta seo trata apenas dos seguintes aspectos: tarefas e "threads",
a comunicao entre elas, instalao de tratadores de dispositivos e interrupes e a
disponibilidade de temporizadores.
Entretanto, bom lembrar que a maioria das aplicaes tempo real possui uma parte
(talvez a maior parte) de suas funes sem restries temporais. Logo, preciso
considerar que o SOTR deveria, alm de satisfazer as necessidades das tarefas de tempo
real, fornecer funcionalidade apropriada para as tarefas convencionais. Aspectos como
suporte para interface grfica de usurio, protocolos de comunicao para a Internet,
fogem do escopo de um SOTR que execute apenas tarefas de tempo real. Porm, so
aspectos importantes quando considerado que uma aplicao tempo real tambm possui
vrios componentes convencionais.
3.2.1 Tarefas e "Threads"
Um programa que executado por apenas uma tarefa chamado de programa

sequencial. A grande maioria dos programas escritos so programas sequenciais. Neste
caso, existe somente um fluxo de controle durante a execuo. Um programa
concorrente executado simultaneamente por diversas tarefas que cooperam entre si,
isto , trocam informaes. Neste contexto trocar informaes significa trocar dados ou
realizar algum tipo de sincronizao. necessrio a existncia de interao entre tarefas
para que o programa seja considerado concorrente.
Na literatura de sistemas operacionais os termos tarefa e processo so
frequentemente utilizados com o mesmo sentido. Tarefas ou processos so abstraes
que incluem um espao de endereamento prprio (possivelmente compartilhado), um
conjunto de arquivos abertos, um conjunto de direitos de acesso, um contexto de
execuo formado pelo conjunto de registradores do processador, alm de vrios outros
atributos cujos detalhes variam de sistema para sistema. O tempo gasto para chavear o
processador entre duas tarefas definido por este conjunto de atributos, isto , o tempo
necessrio para mudar o conjunto de atributos em vigor.
Uma forma de tornar a programao concorrente ao mesmo tempo mais simples e
mais eficiente utilizar a abstrao "thread". "Threads" so tarefas leves, no sentido
que os nicos atributos particulares que possuem so aqueles associados com o contexto
de execuo, isto , os registradores do processador. Todos os demais atributos de uma
"thread" so herdados da tarefa que a hospeda. Desta forma, o chaveamento entre duas
"threads" de uma mesma tarefa muito mais rpido que o chaveamento entre duas
tarefas. Por exemplo, como todas as "threads" de uma mesma tarefa compartilham o
mesmo espao de endereamento, a MMU ("memory management unit") no afetada
pelo chaveamento entre elas. No restante deste captulo ser suposto que o SOTR
suporta "threads". Logo, o termo tarefas ser usado para denotar um conjunto de
recursos tais como espao de endereamento, arquivos, "threads", etc, ao passo que
"thread" ser usado para denotar um fluxo de execuo especfico.
Aplicaes de tempo real so usualmente organizadas na forma de vrias "threads"
ou tarefas concorrentes. Logo, um requisito bsico para os sistemas operacionais de
tempo real oferecer suporte para tarefas e "threads. Embora programas
concorrentes possam ser construdos a partir de tarefas, o emprego de "threads"
aumenta a eficincia do mesmo. Devem ser providas chamadas de sistema para criar e
destruir tarefas e "threads", suspender e retomar tarefas e "threads", alm de chamadas
para manipular o seu escalonamento.
Durante a execuo da aplicao as "threads" passam por vrios estados. A figura
3.1 procura mostrar, de maneira simplificada, quais so estes estados. Aps ser criada, a
"thread" est pronta para receber o processador. Entretanto, como possivelmente vrias
"threads" aptas disputam o processador, ela dever esperar at ser selecionada para
execuo pelo escalonador. Uma vez selecionada, a "thread" passa para o estado
executando. A "thread" pode enfrentar situaes de bloqueio quando solicita uma
operao de entrada ou sada, ou ento tenta acessar uma estrutura de dados que est em
uso por outra "thread". Neste momento ela para de executar e passa para o estado
bloqueada. Quando a causa do bloqueio desaparece, ela volta a ficar pronta para
executar. A figura 3.1 diferencia como um tipo especial de bloqueio a situao na qual a
"thread" solicita sua suspenso por um intervalo de tempo, ou at uma hora futura pr-
determinada. Neste caso, a "thread" dita inativa. Ela voltar a ficar pronta quando
chegar o momento certo. Este estado tpico de uma "thread" com execuo peridica,
quando a ativao atual j foi concluda e ela aguarda o instante da prxima ativao.
Observe que "threads" peridicas tambm podem ser implementadas atravs da criao
de uma nova "thread" no incio de cada perodo e de sua destruio to logo ela conclua
seu trabalho relativo quele perodo. Entretanto, o custo (overhead) associado com a
criao e a destruio de "threads" maior do que o custo associado com a suspenso e
reativao, resultando em um sistema menos eficiente. importante notar que a figura
3.1 descreve o funcionamento tpico de um sistema operacional genrico. Uma
descrio exata da semntica de cada estado depende de detalhes que, na prtica,
variam de sistema para sistema. Por exemplo, quando um escalonamento esttico
garante que todos os recursos que a "thread" precisa para executar estaro disponveis
no momento certo, ento ela nunca passar pelo estado bloqueada.
Criao pronta executando Destruio
inativa bloqueada
Figura 3.1 - Estados de uma "thread".

Uma questo sempre presente quando o assunto "thread" a convenincia de
implementa-las a nvel de "kernel" ou a nvel de biblioteca. Quando implementadas a
nvel de biblioteca, uma nica "thread" reconhecida pelo "kernel" usada para executar
diversas "threads" da aplicao, atravs de uma multiprogramao implementada por
rotinas ligadas com a aplicao e ignoradas pelo "kernel". Este tipo de "thread" oferece
um chaveamento de contexto mais rpido e menor custo para criao e destruio.
Entretanto, como o "kernel" reconhece a existncia de apenas uma "thread", se esta
ficar bloqueada ento todas as "threads" da tarefa ficaro bloqueadas. Alm disto, a
soluo a nvel de biblioteca no capaz de aproveitar multiprocessamento quanto este
existe. A discusso sobre as vantagens de um tipo e outro longa e pode ser encontrada
em livros de sistemas operacionais tal como [SiG98]. Neste texto suposto que as
"threads" so implementadas pelo "kernel", o qual tambm responsvel pelo seu
escalonamento.
3.2.2 Comunicao entre Tarefas e "Threads"
Uma aplicao tempo real tipicamente um programa concorrente, formado por

tarefas e "threads" que se comunicam e se sincronizam. A literatura sobre sistemas
operacionais convencionais trata este assunto com bastante detalhe. Existem duas
grandes classes de solues para a construo de um programa concorrente: troca de
mensagens e variveis compartilhadas.
A troca de mensagens baseada em duas operaes simples: "enviar mensagem" e
"receber mensagem". Na verdade estas duas operaes oferecem a possibilidade de um
grande nmero de variaes, na medida em que so alteradas caractersticas como
forma de endereamento, armazenamento intermedirio, situaes de bloqueio,
tolerncia a falhas, etc. Uma descrio completa do mecanismo foge ao escopo deste
livro e pode ser encontrada em [SiG98] ou [TaW97]. O importante notar que tanto a
comunicao como a sincronizao so feitas atravs das mesmas operaes. Enquanto
a comunicao acontece atravs da mensagem enviada, a sincronizao acontece atravs
do bloqueio da "thread" at que ela receba uma mensagem ou at que a mensagem
enviada por ela seja lida pela "thread" destinatria. Esta soluo especialmente
conveniente em sistemas distribudos.
Nas solues baseadas em variveis compartilhadas o sistema operacional oferece,
alm da memria compartilhada para hospedar estas variveis, algum mecanismo de

sincronizao auxiliar. A comunicao entre "threads" acontece atravs da leitura e
escrita de um conjunto compartilhado de variveis. A sincronizao deve ser explcita,
atravs de semforos, monitores, "spin-locks", regies crticas condicionais, ou algum
outro mecanismo deste tipo (uma descrio destes mecanismos pode ser encontrada em
[SiG98]). Em geral esta soluo somente possvel quando as "threads" envolvidas
executam no mesmo computador. Embora existam implementaes de memria virtual
compartilhada, onde o mecanismo de memria virtual usado para criar a iluso de uma
memria compartilhada que no existe no hardware, este mecanismo possui um custo
elevado e no vivel em sistemas de tempo real.
Estas duas classes de solues so equivalentes no sentido de que qualquer
programa concorrente pode ser implementado com uma ou com outra. Entretanto, a
forma como o programa concorrente estruturado deve levar em conta o mecanismo de
comunicao adotado. Em geral, memria compartilhada mais eficiente que troca de
mensagens. Com memria compartilhada no existe a necessidade de copiar os dados
da memria do remetente para uma rea do sistema operacional e depois para a
memria do destinatrio. As tarefas alteram diretamente as variveis compartilhadas.
Entretanto, em sistemas distribudos mensagens so a forma natural de comunicao.
Muitos sistemas operacionais oferecem os dois mecanismos.
Observe que a correta programao da comunicao e sincronizao das tarefas em
um programa concorrente garante o seu comportamento funcional, mas no temporal.
Isto , o resultado lgico do programa ser sempre correto, independentemente da
ordem na qual as tarefas so executadas. Entretanto, o correto comportamento temporal
vai depender do escalonamento das tarefas e da capacidade do hardware de cumprir
com os requisitos temporais.
No sentido inverso, possvel afirmar que algumas solues de escalonamento
tempo real j citadas resolvem tambm o problema de sincronizao entre tarefas e
"threads". Por exemplo, o escalonamento baseado em executivo cclico (ver captulo 2)
determina "que tarefa executa quando" ainda em tempo de projeto. A construo da
grade de execuo pode ser feita de tal forma que, alm de atender aos requisitos
temporais, ela tambm resolve os problemas de excluso mtua e relaes de
precedncia entre as tarefas. Neste caso, no existe a necessidade de mecanismos
explcitos de sincronizao.
3.2.3 Instalao de Tratadores de Dispositivos
Freqentemente os sistemas de tempo real lidam com perifricos especiais,

diferentes daqueles normalmente encontrados em computadores de escritrio. Por
exemplo, aplicaes visando automao industrial ou o controle de equipamentos em
laboratrio empregam diferentes tipos de sensores e atuadores. Algumas vezes
dispositivos so desenvolvidos sob medida para o projeto em questo.
fundamental que o projetista da aplicao possa desenvolver os seus prprios

tratadores de dispositivos ("device drivers") e, de alguma forma, incorpora-los ao
sistema operacional. Esta na verdade uma tcnica usual. Normalmente os vendedores
de perifricos fornecem, alm do perifrico propriamente dito, tratadores apropriados
para os sistemas operacionais mais populares. No caso dos sistemas operacionais de
tempo real a situao mais complexa pois:
Se o SOTR usado no for bastante conhecido, o fornecedor do perifrico
poder no fornecer um tratador apropriado para ele. Isto obriga o projetista da
aplicao a portar para o SOTR usado um tratador para aquele perifrico que
tenha sido originalmente desenvolvido para outro sistema operacional.
Se o perifrico for desenvolvido sob medida, ento um tratador de dispositivo
apropriado para ele ter que ser desenvolvido.
Muitas vezes a aplicao e o perifrico esto fortemente integrados, e o cdigo da
aplicao confunde-se com o cdigo do que seria o tratador do dispositivo. Isto
acontece principalmente no contexto dos sistemas embutidos ("embedded systems").
Neste caso importante que o SOTR permita que a aplicao instale os seus prprios
tratadores de interrupes, para que as interrupes do perifrico sejam atendidas pelo
cdigo apropriado. Em sistemas operacionais de propsito geral, multi-usurios, a
instalao de tratadores de interrupo considerada uma operao perigosa e,
portanto, permitida apenas ao prprio "kernel" do sistema operacional ou tarefas
especiais. Sistemas operacionais de tempo real frequentemente executam apenas uma
aplicao, para um nico usurio, que o conhecedor da aplicao e de suas
necessidades. Desta forma, a instalao de tratadores de interrupo por tarefas normais
passa a ser aceitvel.
3.2.4 Temporizadores
Embora seja possvel conceber uma aplicao tempo real que nunca precise "ler a
hora" ou "aguardar um certo intervalo de tempo", esta no a situao mais comum.
Tipicamente as aplicaes precisam realizar operaes que envolvem a passagem do
tempo, tais como:
Ler a hora com o propsito de atualizar um histrico;
Realizar determinada ao a cada X unidades de tempo (ativao peridica);
Realizar determinada ao depois de Y unidades de tempo a partir do instante
atual;
Realizar determinada ao a partir do instante absoluto de tempo Z.
Tais operaes permitem a implementao de tarefas peridicas, "time-outs",
"watch-dogs", etc. importante que o SOTR oferea um conjunto de servios que
atenda estas necessidades. Tipicamente o sistema possui pelo menos um temporizador
("timer") implementado em hardware, o qual capaz de gerar interrupes com uma

dada frequncia. Cabe ao SOTR utilizar este temporizador do hardware para criar a
iluso de mltiplos temporizadores lgicos. A cada interrupo do temporizador em
hardware o SOTR atualiza cada um dos temporizadores lgicos e executa as operaes
necessrias.
Uma questo importante ligada aos temporizadores a sua resoluo ou
granularidade. Esta dada pela frequncia do temporizador do hardware. Para o SOTR
o tempo avana de maneira discreta, um perodo do temporizador do hardware de cada
vez. Por exemplo, suponha que este gere uma interrupo a cada 100 ms, isto , sua
resoluo de 100 ms. Se uma tarefa qualquer solicitar ao SOTR que determinada
rotina seja executada uma vez a cada 1250 ms, na verdade o intervalo de tempo entre
duas ativaes sucessivas desta rotina ser de 1200 ms ou de 1300 ms. Dependendo da
implementao do SOTR, a rotina ser ativada uma vez a cada 1200 ms, uma vez a cada
1300 ms ou ainda atravs da intercalao de intervalos de tempo de 1200 ms e 1300 ms.
Esta ltima forma provavelmente a melhor, pois resulta em um tempo mdio de espera
que aproxima-se dos 1250 ms. Em geral a resoluo pode ser aumentada alterando-se a
programao do temporizador em hardware. Entretanto, o tratador destas interrupes,
que implementa os diversos temporizadores lgicos, representa um custo ("overhead")
para o sistema. Aumentar a frequncia das interrupes significa aumentar este custo. O
importante que a resoluo dos temporizadores seja apropriada para a aplicao em
questo, isto , os erros devido a granularidade dos relgios do sistema possam ser
desprezados.
Existem outras fontes de impreciso alm da resoluo do temporizador no
hardware. Mesmo que a tarefa solicite sua suspenso pelo tempo equivalente a um
nmero inteiro de interrupes, a solicitao pode ocorrer no meio entre duas
interrupes. Alm disto, quando passar o tempo estipulado, a fila do processador pode
incluir tarefas ou "threads" com prioridade mais alta. Em resumo, qualquer
temporizao realizada pelo SOTR ser sempre uma aproximao. Ela ser to mais
exata quanto maior for a resoluo do temporizador em hardware e maior for a
prioridade da ao associada com a temporizao.
Um servio adicional que o SOTR pode disponibilizar a sincronizao da hora do
sistema com a UTC ("Universal Time Coordinated"). Os cristais de quartzo utilizados
nos computadores como fonte para as oscilaes que permitem medir a passagem do
tempo so imprecisos. Desta forma, alguma referncia externa deve ser usada para
manter o relgio do sistema sincronizado com a UTC. Uma forma cada vez mais
popular o sistema GPS ("Global Possitioning System"), que utiliza uma antena local
recebendo sinais de satlites. Embora o posicionamento da antena seja crtico neste tipo
de sistema, ele relativamente barato e fcil de instalar.
No caso de um sistema distribudo, cabe tambm ao sistema operacional manter os
relgios dos diferentes computadores sincronizados entre si. claro que, se cada
computador do sistema possuir o seu prprio receptor GPS, a sincronizao entre eles
ser automtica. Entretanto, em funo do custo e da necessidade de colocar antenas,
tipicamenrte apenas alguns computadores da rede tero seu relgio sincronizado com o
3.3 Aspectos Temporais de um Sistema Operacional Tempo Real 69
mundo exterior. Os demais devero sincronizar-se com estes, atravs de algum

protocolo. Exemplos podem ser encontrados em [VRC97] e [FeC97]. Todo protocolo
de sincronizao de relgios deixa um erro residual. A implementao deste protocolo
no "kernel" do sistema operacional deixa um erro residual menor do que quando ele
implementado pela prpria aplicao, pois o cdigo do "kernel" est menos sujeito a
interferncias durante a sua execuo do que o cdigo da aplicao. Existem tambm
solues de sincronizao de relgio via hardware, as quais so mais caras porm muito
mais precisas.
Em geral programas tambm precisam de rotinas para manipular datas e horas em
formatos tradicionais. Por exemplo, converter entre diferentes formatos e realizar
operaes aritmticas como calcular a diferena em horas entre duas datas ou calcular
em que dia da semana caiu determinada data. Tipicamente estes servios no so
providos pelo SOTR e sim por bibliotecas associadas com o suporte de execuo da
linguagem de programao usada. Como formatos para data e hora podem variar de
linguagem de programao para linguagem de programao, tais operaes so melhor
providas pelo suporte da prpria linguagem.
3.3 Aspectos Temporais de um Sistema Operacional

Tempo Real
Alm dos aspectos funcionais, tambm presentes em sistemas operacionais de

propsito geral, os aspectos temporais de um SOTR so muito importantes. Eles esto
relacionados com a capacidade do SOTR fornecer os mecanismos e as propriedades
necessrios para o atendimento dos requisitos temporais da aplicao tempo real. O
propsito desta seo estabelecer alguns critrios para avaliar a qualidade temporal de
um dado sistema operacional.
Uma vez que tanto a aplicao como o SOTR compartilham os mesmos recursos do
hardware, o comportamento temporal do SOTR afeta o comportamento temporal da
aplicao. Por exemplo, considere a rotina do sistema operacional que trata as
interrupes do temporizador em hardware. O projetista da aplicao pode ignorar
completamente a funo desta rotina, mas no pode ignorar o seu efeito temporal, isto ,
a interferncia que ela causa na execuo da aplicao. Esta interferncia deve ser de
alguma forma includa nos testes de escalonabilidade descritos no captulo 2.
O fator mais importante a vincular aplicao e sistema operacional so os servios
que este ltimo presta. A simples operao de solicitar um servio ao sistema
operacional atravs de uma chamada de sistema significa que: (1) o processador ser
ocupado pelo cdigo do sistema operacional durante a execuo da chamada de sistema
e, portanto, no poder executar cdigo da aplicao; (2) a capacidade da aplicao
atender aos seus "deadlines" passa a depender da capacidade do sistema operacional em
fornecer o servio solicitado em um tempo que no inviabilize aqueles "deadlines".
Em resumo, com respeito ao comportamento temporal do sistema, qualquer anlise

deve considerar conjuntamente aplicao e sistema operacional. Isto equivale a dizer
que os requisitos temporais que um SOTR deve atender esto completamente atrelados
aos requisitos temporais da aplicao tempo real que ele dever suportar. Uma vez que
existe um amplo espectro de aplicaes de tempo real, com diferentes classes de
requisitos temporais, tambm existiro diversas solues possveis para a construo de
SOTR, cada uma mais apropriada para um determinado contexto. Por exemplo, o
comportamento temporal exigido de um SOTR capaz de suportar o controle de vo em
um avio ("fly-by-wire") muito diferente daquele esperado de um SOTR usado para
videoconferncia. O captulo 2, ao explorar as solues de escalonamento tempo real
existentes, deu uma idia da diversidade existente nesta rea.
Neste ponto importante destacar que a teoria de tempo real, descrita no captulo
anterior, recente. Embora a referncia mais antiga seja sempre [LiL73], somente na
dcada de 90 os modelos de tarefas suportados pela teoria de escalonamento foram
estendidos a ponto de tornarem-se verdadeiramente teis. Estes avanos da teoria esto
sendo gradativamente absorvidos pelos desenvolvedores de SOTR. Entretanto, ainda
hoje (incio de 2000), existe uma distncia entre a teoria de escalonamento e a prtica
no desenvolvimento de sistemas de tempo real. O texto deste captulo reflete esta
dicotomia. De um lado a teoria buscando a previsibilidade, de outro a prtica fazendo
"o que possvel" nos ambientes computacionais existentes, muitas vezes confundindo
tempo real com alto desempenho. No meio disto temos os sistemas operacionais de
tempo real, lentamente evoluindo do conceito "desempenho" para o conceito
"previsibilidade".
3.3.1 Limitaes dos Sistemas Operacionais de Propsito Geral
As aplicaes tempo real desenvolvidas esto cada vez mais complexas, o que exige
uma sempre crescente funcionalidade do suporte de tempo real. Por exemplo, cada
vez mais comum a necessidade de interfaces grficas, conexo via rede local ou mesmo
Internet, algoritmos de controle mais inteligentes.
Ao mesmo tempo, existem razes de ordem econmica para a utilizao de solues
de prateleira ("off-the-shelf"). Em particular, usar um sistema operacional de propsito
geral no projeto significa usar um sistema operacional tipicamente mais barato, para o
qual existe uma grande quantidade de ambientes de desenvolvimento e tambm mais
fcil contratar programadores experientes.
O que impede o emprego de sistemas operacionais de propsito geral so as
restries temporais da aplicao. Assim, uma das primeiras decises que o projetista
de uma aplicao tempo real deve tomar : " realmente necessrio usar um SOTR" ?
A dificuldade desta deciso minimizada pela existncia de uma classe de SOTR
que simplesmente um sistema operacional popular adaptado para o contexto de tempo
real. Estes sistemas foram adaptados no sentido de mostrar alguma preocupao com a
resposta em tempo real. O resultado final obtido com eles melhor do que quando um
sistema operacional de propsito geral utilizado, mas no capaz de oferecer
previsibilidade determinista.
Independentemente do contexto em questo, diversas tcnicas populares em
sistemas operacionais de propsito geral so especialmente problemticas quando as
aplicaes possuem requisitos temporais. Por exemplo, o mecanismo de memria
virtual capaz de gerar grandes atrasos (envolve acesso a disco) durante a execuo de
uma "thread". Os mecanismos tradicionais usados em sistemas de arquivos, tais como
ordenar a fila do disco para diminuir o tempo mdio de acesso, fazem com que o tempo
para acessar um arquivo possa variar muito. Em geral, aplicaes de tempo real
procuram minimizar o efeito negativo de tais mecanismos de duas formas:
Desativando o mecanismo sempre que possvel (no usar memria virtual);
Usando o mecanismo apenas em tarefas sem requisitos temporais rigorosos
(acesso a disco feito por tarefas sem requisitos temporais, ou apenas requisitos
brandos).
Todos os sistemas operacionais desenvolvidos ou adaptados para tempo real
mostram grande preocupao com a diviso do tempo do processador entre as tarefas.
Entretanto, o processador apenas um recurso do sistema. Memria, perifricos,
controladores tambm deveriam ser escalonados visando atender os requisitos
temporais da aplicao. Entretanto, muitos sistemas ignoram isto e tratam os demais
recursos da mesma maneira empregada por um sistema operacional de propsito geral,
isto , tarefas so atendidas pela ordem de chegada.
Outro aspecto central o algoritmo de escalonamento empregado. Tipicamente
qualquer sistema operacional dispe de escalonamento baseado em prioridades. Neste
caso, bastaria que a prioridade das "threads" de tempo real fossem mais elevadas do
que as "threads" associadas com tarefas convencionais ("time-sharing" e
"background"). Entretanto, a maioria dos sistemas operacionais de propsito geral
inclui mecanismos que reduzem automaticamente a prioridade de uma "thread" na
medida que ela consome tempo de processador. Este tipo de mecanismo utilizado para
favorecer as tarefas com ciclos de execuo menor e diminuir o tempo mdio de
resposta no sistema. Entretanto, em sistemas de tempo real a justa distribuio de
recursos entre as tarefas menos importante do que o atendimento dos requisitos
temporais.
Considere, por exemplo, o algoritmo de escalonamento utilizado em verses
tradicionais do sistema operacional Unix, tais como o Unix System V release 3 (SVR3)
ou o Berkeley Software Distribution 4.3 (4.3BSD).
O Unix tradicional emprega prioridade varivel. Quando uma tarefa liberada e
possui prioridade maior do que a tarefa que est executando, existe um chaveamento de
contexto e a tarefa recm liberada passa a ser executada. Tarefas com a mesma
prioridade dividem o tempo do processador atravs do mecanismo de fatias de tempo.
Entretanto, duas caractersticas tornam este sistema problemtico para tempo real.
Primeiro, a prioridade de cada tarefa varia conforme o seu padro de uso do

processador, como ser descrito a seguir. Depois, uma tarefa executando cdigo do
"kernel" no pode ser preemptada. Desta forma, a latncia at o disparo de uma tarefa
de alta prioridade inclui o maior caminho de execuo existente dentro do "kernel".
As prioridades variam entre 0 e 127, onde um nmero menor representa prioridade
mais alta. Os valores entre 0 e 49 so reservados para tarefas executando cdigo do
"kernel". Os valores entre 50 e 127 so para tarefas em modo usurio.
O descritor de tarefa contm, entre outras informaes:
A prioridade atual da tarefa, p_pri;
A prioridade desta tarefa quando em modo usurio, p_usrpri;
Uma medida da utilizao recente de processador por esta tarefa, p_cpu;
Um fator de gentileza definido pelo programador ou administrador do sistema,
p_nice;
Quando em modo usurio, a tarefa possui sua prioridade definida por p_usrpri, isto
, p_pri = p_usrpri. Quando uma tarefa liberada dentro do "kernel" aps ter acordado
de um bloqueio ela recebe um "empurro temporrio", na forma de uma prioridade
p_pri que mais alta (nmero menor) do que o seu p_usrpri. Cada razo de bloqueio
tem uma "sleep priority" associada, a qual determina a "fora do empurro". Por
exemplo, a prioridade aps ficar esperando por entrada de terminal 28 e a prioridade
aps ficar esperando por um acesso ao disco 20, independentemente do que a tarefa
faz ou de seus requisitos temporais, caso eles existam. Quando uma tarefa acorda, p_pri
recebe a "sleep priority" correspondente ao bloqueio. A prioridade da tarefa retornar
para o valor p_usrpri quando esta voltar para modo usurio.
O valor de p_usrpri depende dos valores de p_cpu e de p_nice da tarefa em questo.
O fator de gentileza um nmero entre 0 e 39, cujo valor padro ("default") 20. O
valor de p_cpu inicial zero na criao da tarefa. A cada interrupo do temporizador
("tick"), o valor p_cpu da tarefa em execuo naquele instante incrementado, at um
valor mximo de 127.
Simultaneamente, a cada segundo, os valores p_cpu de todas as tarefas so
reduzidos por um fator de decaimento ("decay factor"). Por exemplo, so multiplicados
por 1/2, ou so multiplicados por decay, onde
decay = ( 2 * load_average ) / ( 2 * load_average + 1 ) e o valor load_average o
nmero mdio de tarefas aptas a executar dentro do ltimo segundo.
A prioridade da tarefa quando executando cdigo da aplicao calculada atravs
da frmula p_usrpri = 50 + ( p_cpu / 4 ) + ( 2 * p_nice ). Em funo deste recalculo,
pode haver um chaveamento de contexto. Isto acontece quando a tarefa em execuo
fica com prioridade mais baixa do que qualquer outra tarefa apta a executar,
considerando-se os novos valores de p_usrpri de todas as tarefas.
A soluo de escalonamento do SVR3 e do 4.3BSD engenhosa e permite um bom
desempenho quando as maiores preocupaes so a justa distribuio de recursos entre

as tarefas e o tempo mdio de resposta do sistema. Entretanto, quando a qualidade
temporal de sistema avaliada em termos do nmero de "deadlines" cumpridos ou do
atraso mdio em relao ao "deadline" de cada tarefa, esta soluo no mais
apropriada. Seu comportamento depende em grande parte da dinmica do sistema,
tirando do projetista o poder de controlar com maior exatido o tratamento que cada
tarefa recebe. Um dos aspectos centrais de um SOTR usar um algoritmo de
escalonamento que permita ao programador um controle maior sobre a execuo das
tarefas.
3.3.2 Chaveamento de Contexto e Latncia de Interrupo
Fornecedores de SOTR costumam divulgar mtricas para mostrar como o sistema

em questo mais ou menos apropriado para suportar aplicaes de tempo real. Estas
mtricas refletem a prtica da construo de aplicaes tempo real nas ltimas dcadas,
e muitas vezes esto mais ligadas desempenho do que ao cumprimento de restries
temporais. A seo 3.3.2 descreve as mtricas como encontradas na literatura. A seo
3.3.3 procura analisar a sua relao com o tempo de resposta das tarefas.
Uma mtrica muito utilizada o tempo para chaveamento entre duas tarefas. Este
tempo inclui salvar os registradores da tarefa que est executando e carregar os
registradores com os valores da nova tarefa, incluindo qualquer informao necessria
para a MMU ("memory management unit") funcionar corretamente. Em geral esta
mtrica no inclui o tempo necessrio para decidir qual tarefa vai executar, uma vez que
isto depende do algoritmo de escalonamento utilizado.
Outra mtrica frequentemente utilizada pelos fornecedores de SOTR a latncia at
o inicio do tratador de uma interrupo do hardware. Imagina-se que eventos
importantes e urgentes no sistema sero sinalizados por interrupes de hardware e,
desta forma, importante iniciar rapidamente o tratamento destas interrupes. Observe
que, no caso mais simples, suposto que a rotina que trata a interrupo capaz de
sozinha gerar uma resposta apropriada para o evento sinalizado. Colocar cdigo da
aplicao no tratador de interrupes uma soluo perigosa, pois este cdigo executa
com direitos totais dentro do "kernel". Entretanto, esta forma permite respostas
extremamente rpidas da aplicao um evento externo. Do ponto de vista da anlise
de escalonabilidade, este tratador de interrupes corresponderia a uma tarefa com a
prioridade mais alta do sistema. Ele gera interferncia sobre as demais tarefas, mas no
recebe interferncia de nenhuma outra. A latncia de interrupo equivale ao "release
jitter" desta tarefa especial.
A latncia no disparo de um tratador de interrupo inclui o tempo que o hardware
leva para realizar o processamento de uma interrupo, isto , salvar o contexto atual
("program counter" e "flags") e desviar a execuo para o tratador da interrupo.
Tambm necessrio incluir o tempo mximo que as interrupes podem ficar
desabilitadas. Por exemplo, um "kernel" que executa com interrupes desabilitadas

inclui na latncia a maior sequncia de instrues que podem ser executadas dentro
dele, tipicamente uma chamada de sistema complexa. Por outro lado, esta soluo tem a
vantagem de permitir ao tratador da interrupo acessar livremente as estruturas de
dados do "kernel", pois garantido que esto em um estado consistente quando ele
ativado. Este acesso ocorre quando o tratador de interrupo necessita algum servio do
"kernel", como liberar uma tarefa para execuo futura.
Sistemas mais modernos, como o Unix SVR4, utilizam "kernel" com pontos de
preempo previamente programados. Desta forma, quando uma interrupo de
hardware acionada e a tarefa executando est dentro do "kernel", o tratador da
interrupo no precisar esperar que a tarefa executando complete a chamada, mas
apenas chegue no prximo ponto de preempo, quando o chaveamento de contexto
ocorrer. Estes pontos de preempo so colocados no cdigo do "kernel" em pontos
onde suas estruturas de dados esto consistentes. Desta forma, o tratador da interrupo
pode acessar livremente as estruturas de dados do "kernel", desde que tambm as deixe
em um estado consistente ao final de sua execuo.
Finalmente, a forma mais apropriada para um SOTR, usar um "kernel"
completamente interrompvel. Desta forma, no importa se a tarefa em execuo est ou
no executando cdigo do "kernel", o tratador de interrupo imediatamente
disparado. Se as estruturas de dados do "kernel" so compartilhadas entre a tarefa
executando o cdigo do "kernel" e o tratador de interrupes, elas devem ser protegidas
por algum mecanismo de sincronizao. Por exemplo, interrupes podem ser
desabilitadas pela tarefa somente enquanto ela estiver acessando uma estrutura de dados
usada pelo tratador de interrupes.
A figura 3.2 ilustra as 3 situaes. Na situao (A) o "kernel" executa com
interrupes desabilitadas e o tratador da interrupo somente ativado quando a tarefa
em execuo deixa o "kernel". Na situao (B) o tratador da interrupo acionado
assim que a tarefa chega no prximo ponto de interrupo. Aps a execuo do tratador
da interrupo a tarefa retoma a sua execuo. Na situao (C) o tratador ativado o
mais cedo possvel, depois do que a tarefa retoma a sua execuo dentro de um "kernel"
que pode ser interrompido a qualquer momento. Obviamente, a situao (C) oferece a
menor latncia at o incio do tratador de interrupo.
interrupo
latncia
(A)
k-des hw
trat
tempo
interrupo
latncia k-hab = Kernel com interrupes habilitadas
(B) k-des = Kernel com interrupes desabilitadas
hw = Tempo que o hardware leva para ativar o tratador
k-des hw k-des trat = Cdigo que trata a interrupo do hardware
trat
interrupo tempo
(C) latncia
k-hab hw k-hab
trat
tempo
Figura 3.2 - Formas do "kernel" lidar com interrupes de hardware.
3.3.3 Relao entre Mtricas e Tempo de Resposta
Mtricas como o tempo de chaveamento e o tempo de latncia so teis no sentido

de quanto menor elas forem em um dado SOTR, tanto melhor. Elas tambm so
relativamente fceis de medir, conhecendo-se o programa fonte do "kernel". Alm disto,
estes valores so necessrios no momento de aplicar os testes de escalonabilidade
descritos no captulo anterior. Entretanto, elas no so as nicas responsveis pelos
tempos de resposta. Tambm importante lembrar que as diversas tarefas e
interrupes do sistema causam interferncias que devem ser contabilizadas. Po sua vez,
os conflitos decorrentes de recursos compartilhados, tanto a nvel de aplicao como a
nvel de "kernel" causam situaes de bloqueio e de inverso de prioridades que
tambm contribuem para os tempos de resposta no sistema. Todos estes fatores devem
ser computados e somente a aplicao correta de um teste de escalonabilidade ser
capaz de determinar se as restries temporais sero ou no cumpridas.
Uma questo importante a ser analisada a relao entre a latncia at o incio do
tratador de interrupo e o tempo total de resposta, ou seja, o tempo entre a sinalizao
do evento atravs de uma interrupo de hardware e a respectiva resposta do sistema ao
ambiente. Esta relao depende do nvel de complexidade do tratador de interrupes.
Em linhas gerais podemos classificar os tratadores de interrupes em quatro tipos:
Tratador simples, executa cdigo da aplicao e no precisa de qualquer servio
ou estrutura de dados do "kernel";
Tratador complexo, executa cdigo da aplicao mas necessita servio ou
estrutura de dados do "kernel";
Tratador apenas libera tarefa simples da aplicao, que no utiliza o "kernel";
Tratador libera tarefa complexa da aplicao, que utiliza o "kernel".

Como o tratador simples no acessa rotinas ou estruturas de dados do "kernel", no
necessrio qualquer cuidado com o estado do "kernel" no momento que o tratador
ativado. Como o prprio nome indica, esta a situao mais simples. A figura 3.2 e o
texto da seo anterior foram construdos supondo este tipo de tratador.
No caso de um tratador complexo, necessrio assegurar que as estruturas de dados
do "kernel" esto consistentes no momento que ele ativado. No caso do "kernel" que
no pode ser interrompido, no existe problema. Quando o "kernel" pode ser
interrompido apenas em pontos previamente definidos, necessrio tomar o cuidado de
posicionar tais pontos em locais do cdigo do "kernel" onde as estruturas de dados
esto consistentes e podem ser acessadas pelo tratador da interrupo. Finalmente, no
caso de um "kernel" que pode ser interrompido a qualquer momento, todas as estruturas
de dados passveis de acesso pelo tratador devem ser protegidas de alguma forma, como
por exemplo desabilitar interrupes.
Ainda considerando o tratador complexo em "kernel" totalmente interrompvel, para
que o tratador da interrupo possa ficar bloqueado a espera da liberao de uma
estrutura de dados, possvel associar ao tratador de interrupes uma semntica de
"thread". Por isto, em sistemas onde o "kernel" pode ser interrompido a qualquer
momento e o tratador da interrupo necessita acessar estruturas de dados do "kernel", a
soluo mais elegante fazer com que o tratador de interrupes apenas libere uma
"thread" que, ao ser escalonada, far o acesso ao "kernel". Embora o ato de liberar uma
"thread" para execuo necessite, por si s, acesso a estruturas de dados do "kernel",
este acesso simples e rpido e possveis inconsistncias podem ser evitadas
desabilitando-se interrupes por rpidos instantes, quando estas estruturas forem
manipuladas. Alis, este o nico momento no qual as interrupes precisam realmente
ficar desabilitadas.
Quando o tratador apenas libera uma tarefa da aplicao, simples ou complexa, seu
comportamento similar quele que libera uma "thread" para executar cdigo do
"kernel". Cabe ao cdigo da tarefa da aplicao realmente tratar o evento sinalizado
pela interrupo.
Uma vez definidos os quatro tipos de tratadores de interrupo, podemos analisar a
relao entre a latncia de interrupo e o tempo de resposta do sistema. No caso de um
tratador simples, o tempo de resposta dado pela latncia de interrupo somada ao
tempo de execuo do tratador, pois o seu comportamento equivale ao de uma tarefa
com a prioridade mais alta do sistema.
Em alguns sistemas as interrupes de hardware possuem nveis de prioridade.
Neste caso, quando o tratador da interrupo X est executando, interrupes de
prioridade igual ou inferior esto automaticamente desabilitadas, ao passo que
interrupes com prioridade superior continuam habilitadas. Neste caso, o tratador da
interrupo X poder sofrer interferncia dos tratadores das interrupes mais
importantes, o que aumenta o seu tempo de resposta. A figura 3.3 ilustra as duas
situaes.
Apenas 1 tratador Tratador 1 interrompido pelo tratador 2
interrupo
int.1 int.2
resposta
resposta 1
latncia resposta 2
latncia
trat trat.1 latncia trat.1
tempo trat.2
tempo
Figura 3.3 - Tempo de resposta de um tratador simples.

O comportamento de um tratador complexo depende da forma como o "kernel" foi
programado. No caso de "kernel" que no admite interrupes ou admite em pontos
previamente definidos, o tratador pode acessar livremente o "kernel" e, portanto, seu
tempo de resposta ser dado pela latncia de interrupo somada com o seu tempo de
execuo. No caso de tratador complexo em "kernel" que pode sofrer interrupes, o
trabalho realmente feito pela "thread" liberada pelo tratador. Do ponto de vista do
sistema, o tempo de resposta definido pela concluso desta "thread". Alm de
eventuais interferncias de outras "threads" com prioridade mais elevada, a "thread"
liberada poder enfrentar bloqueios no momento de acessar o "kernel". Isto ocorre
quando ela necessita de um recurso que estava alocado para outra "thread" no momento
que a interrupo de hardware ocorreu. A figura 3.4 ilustra esta situao. O cdigo
"trat" inclui a identificao da interrupo que ocorreu, a incluso da "thread" na fila do
processador e a execuo do escalonador, o qual seleciona a "thread" recm liberada
para execuo e carrega o seu contexto de execuo.
int.1
resposta
latncia ctx outra ctx
trat
thread thread
tempo
ctx - Tempo para chavear o contexto
outra - Tempo at a outra thread liberar o recurso necessrio
Figura 3.4 - Comportamento de tratador complexo em "kernel" que sofre

interrupes.
No caso de tratadores que liberam tarefas da aplicao, a situao no diferente.
No caso de tarefa simples, o seu tempo de resposta vai depender das interferncias de
tarefas com prioridade mais alta, mas no haver bloqueio devido a conflitos no
"kernel", pois a mesma no precisa do "kernel" para executar. No caso de tarefas
complexas existe a possibilidade de conflito no "kernel" e, portanto, de bloqueios.

Inclusive, a tarefa liberada poder encontrar estruturas de dados do "kernel" bloqueadas
("locked") por outras tarefas de mais baixa prioridade. Mas isto ocorre apenas se houver
coincidncia entre as necessidades da "thread" suspensa e da "thread" liberada.
Observe que se mecanismos tradicionais para sincronizao entre "threads" forem
utilizados, existe a possibilidade de inverso de prioridades (ver captulo 2).
Como mostrado nesta seo, o tempo de chaveamento e o tempo de latncia so
importantes mas no contam toda a estria. Um dos maiores problemas atualmente para
implementar os algoritmos descritos no captulo 2 exatamente o desconhecimento do
projetista da aplicao a respeito dos conflitos decorrentes de recursos compartilhados,
principalmente a nvel de "kernel". Entretanto, fica claro que a teoria de escalonamento
apresentada no captulo anterior pode ser aplicada, desde que conhecidas todas as fontes
de interferncia e de bloqueio presentes no sistema, tanto a nvel de aplicao quanto a
nvel de "kernel".
3.3.4 Tempo de Execuo das Chamadas de Sistema
Uma terceira mtrica importante para qualquer SOTR o tempo de execuo de

cada uma das chamadas de sistema suportadas. Infelizmente, estes tempos de execuo
dependem muitas vezes do estado do "kernel" quando a chamada feita. O manual de
um SOTR pode informar quanto tempo a chamada de sistema para enviar uma
mensagem entre duas tarefas ("send") demora, apenas para a execuo do "send" na
perspectiva da tarefa remetente, em funo do cenrio encontrado. Por exemplo:
5 microsegundos quando no existe tarefa bloqueada esperando por ter
executado um "receive";
7 microsegundos quando existe tarefa a ser liberada;
16 microsegundos quando existe tarefa mais prioritria bloqueada esperando
pela mensagem e a manipulao de filas maior.
Para calcular o tempo de resposta do sistema no pior caso necessrio ser
pessimista e considerar que o "kernel" estar no estado que resulta no maior tempo de
execuo possvel para a chamada em questo. No exemplo, a anlise de
escalonabilidade vai assumir que um "send" demora 16 microsegundos para a tarefa
remetente. Quanto mais complexo for o SOTR, mas difcil ser calcular estes tempos.
Alm disto, eles dependem da arquitetura onde o sistema executado. Na prtica tais
valores raramente esto disponveis para o projetista da aplicao.
3.3.5 Outras Mtricas
As sees 3.2 e 3.3 deste captulo procuram destacar o que normalmente

considerado requisito para um sistema operacional ser considerado de tempo real.

Entretanto, esta uma rea na qual no existe consenso absoluto. Na verdade a
definio de SOTR depende do tipo de aplicao em questo. Desta forma, os SOTRs
herdam das aplicaes um enorme conjunto de possibilidades. Um problema adicional
est na terminologia usada pelos fornecedores de SOTR. A descrio de cada sistema
feita pelo prprio fornecedor orientada mais pelo marketing do que pelo tcnico.
Desta forma, comum encontrar o mesmo termo sendo usado por diferentes
fornecedores para conceitos diferentes, ou o mesmo conceito associado com termos
diferentes por fornecedores diferentes.
Em [TBU98] apresentado um programa de avaliao de SOTR independente de
fornecedor que define como requisitos mnimos:
Multi-tarefas ou "multi-threads" com escalonamento baseado em prioridade
preemptiva.
Prioridades so associadas com a execuo das tarefas ou "threads", e deve
existir um nmero suficiente de nveis de prioridades diferentes para atender a
aplicao alvo.
Deve incluir um mecanismo de sincronizao entre "threads" com
comportamento previsvel.
Deve existir algum mecanismo para prevenir a inverso de prioridades.
O comportamento do sistema operacional em termos de mtricas deve ser
conhecido e previsvel, para todos os possveis cenrios de carga.
Em funo do exposto nas sees anteriores deste captulo podemos tambm listar
uma srie de propriedades e mtricas importantes no momento de selecionar um sistema
operacional que dever suportar aplicaes de tempo real. As mais importantes so:
possvel desativar todos aqueles mecanismos que tornam o comportamento
temporal menos previsvel, sendo memria virtual o exemplo tpico ?
Os tratadores de dispositivo atendem as requisies conforme as prioridades da
aplicao ou simplesmente pela ordem de chegada ?
A mesma questo pode ser feita com respeito aos mdulos do sistema
responsveis pela alocao de memria e pelo sistema de arquivos.
O "kernel" do sistema pode ser interrompido a qualquer momento para a
execuo de um tratador de interrupo ?
Uma "thread" executando cdigo do "kernel" pode ser preemptada por outra
"thread" de prioridade mais alta, quando esta outra deseja executar cdigo da
aplicao ?
Uma "thread" executando cdigo do "kernel" pode ser preemptada por outra
"thread" de prioridade mais alta, quando esta outra deseja fazer uma chamada
de sistema ?
Qual o tempo necessrio para chavear o contexto entre duas "threads" da

mesma tarefa ?
Qual o tempo necessrio para chavear o contexto entre duas "threads" de
tarefas diferentes ?
Qual a latncia at o incio da execuo de um tratador de interrupes ?
Qual o tempo de execuo de cada chamada de sistema ?
Qual o maior intervalo de tempo contnuo no qual as interrupes permanecem
desabilitadas ?
No caso do sistema permitir vrias "threads" executarem simultaneamente
cdigo do "kernel", qual o pior caso de bloqueio associado com as estruturas de
dados ?
Um problema sempre encontrado no momento de medir tempos em um SOTR a
necessidade de uma referncia temporal confivel. Em geral um SOTR dispe de
temporizadores. Entretanto, muitas vezes a resoluo e/ou a preciso no so suficientes
para o propsito pretendido. Alm disto, a incluso de cdigo dentro do prprio SOTR
para fazer as medies acaba por alterar o comportamento temporal do sistema. As
melhores medies so realizadas atravs de hardware externo ao sistema sendo
medido. Este hardware externo fica responsvel por observar eventos, medir intervalos
de tempo e armazenar a informao para posterior anlise. A nica alterao necessria
no sistema sendo medido a externalizao dos eventos de interesse. Isto pode ser feito
atravs da alterao de valor em um dado pino na porta paralela ou atravs de um
acesso a certo endereo de entrada e sada, quando o barramento estiver sendo
monitorado atravs de um "bus analyser".
No caso de mtricas obtidas a partir da instrumentalizao do software, importante
observar que na maioria das vezes os tempos medidos variam muito em funo da carga
e da prpria sequncia de eventos no momento da medio. Por exemplo, considere a
latncia associada com o atendimento de uma interrupo de hardware. A figura 3.5
mostra o formato tpico de um grfico onde so colocadas muitas medidas consecutivas
desta latncia. A diferena entre o menor e o maior valor medido pode alcanar ordens
de grandeza. Isto fica claro na figura 3.6, onde aparece a distribuio das medidas ao
longo de vrios intervalos. Neste caso possvel observar que os intervalos [21,30] e
[81,90] dominam o grfico, indicando que a estrutura interna do SOTR tal que
existem dois cenrios tpicos que definem o tempo de latncia na maioria das vezes.
Estes valores em geral dependem da carga no sistema. A distribuio das medidas de
latncia pode ser afetada pelo aumento da carga. Neste caso, um efeito possvel ma
figura 3.6 o deslocamento das barras para a direita, ou seja, em direo a tempos de
latncia maiores, a medida que a carga aumenta.
Latncia Medida (40 medidas)
100
80
60
40
20
0 1 5 10 15 20 25 30 35 40
Figura 3.5 - Latncia medida em 40 oportunidades consecutivas.
Distribuio das Latncias Medidas

14
12
10
8
6
4
2
0
11..20 21..30 31..40 41..50 51..60 61..70 71..80 81..90 91..100
Figura 3.6 - Distribuio das latncias medidas conforme sua durao.

A mensagem das figuras 3.5 e 3.6 clara: simplesmente valores mdios e varincia
no bastam no caso de sistemas de tempo real. Embora o valor mximo possa ser
utilizado para garantir um comportamento de pior caso, o conhecimento da distribuio
de probabilidade pode abrir caminho para otimizaes do sistema.
Existe ainda a questo do escalonamento do processador, que obviamente deve ser
analisado no sentido de determinar se ele apropriado ou no para a aplicao em
questo. Embora a teoria de escalonamento tempo real tenha evoludo muito durante a
dcada passada, apenas agora os sistemas operacionais comeam a adaptar-se no
sentido de suportar a teoria desenvolvida. Prova disto o fato da maioria dos sistemas
operacionais de tempo real disponveis no mercado no responderem a maioria das
perguntas listadas acima.
3.3.6 Abordagens de Escalonamento e o Sistema Operacional
A abordagem de escalonamento a ser utilizada determinada pela natureza da

aplicao: crtica ou no, carga esttica ou no, etc. A questo fundamental para quem
vai usar um SOTR determinar sua capacidade de suportar a abordagem de
escalonamento escolhida para o projeto.
A leitura do captulo 2 deste livro deixa claro que escalonamento baseado em
prioridades preemptivas suficiente, desde que os atrasos e bloqueios associados com o
SOTR sejam conhecidos.
Talvez o maior obstculo aplicao da teoria de escalonamento seja a dificuldade
em determinar os tempos mximos de execuo de cada tarefa, pois eles dependem de
vrios fatores como o fluxo de controle, a arquitetura do computador ("cache",
"pipeline", etc), a velocidade de barramento e do processador, etc. Embora existam
ferramentas experimentais nesta rea, ainda no existem ferramentas com qualidade
comercial que automaticamente informem o tempo mximo de execuo de determinada
tarefa em determinado computador.
Existem alguns caminhos para contornar este problema. Em tempo de projeto,
quando o cdigo ainda no existe, possvel estimar os tempos de execuo das rotinas
(mtodos) dos diferentes mdulos (objetos) e usar estas estimativas como dados de
entrada nas equaes do captulo 2. Obviamente os resultados so, tambm eles,
estimativas. Entretanto, como em tempo de projeto o cdigo ainda no existe, o
melhor que pode ser feito. Esta estimativa possui uma grande utilidade. Ela permite
detectar, ainda durante o projeto, problemas futuros com respeito aos tempos de
resposta das tarefas, ou seja, detectar que no ser possvel atender aos requisitos
temporais especificados com a arquitetura de hardware e software escolhida. A soluo
poder ser substituir o processador por outro mais rpido, mudar a linguagem de
programao por uma que gere cdigo mais eficiente, alterar a especificao para
aumentar perodos e "deadlines" ou ainda eliminar funcionalidades inicialmente
previstas. Detectar a necessidade de alteraes desta magnitude antes de iniciar a
programao certamente muito melhor do que fazer alteraes deste tipo depois que
toda a aplicao j estiver programada.
Uma vez que a aplicao esteja programada, possvel analisar se as estimativas
usadas em tempo de projeto foram adequadas. Embora existam ferramentas que fazem
isto automaticamente, so ainda projetos acadmicos, sem a qualidade necessria para
utilizao em projetos comerciais. Uma alternativa medir os tempos de execuo.
Neste caso, o tempo de execuo de cada tarefa medido um grande nmero de vezes,
atravs de testes em condies controladas. Os resultados tem tipicamente o formato
das figuras 3.5 e 3.6. Embora no exista a garantia de que o pior caso tenha sido
observado nas medies, elas fornecem uma boa idia para o tempo de execuo da
tarefa. Dependendo do tipo de aplicao, uma margem de segurana pode ser associada
aos tempos medidos, isto , ser considerado como tempo mximo de execuo o maior
tempo de execuo observado multiplicado por um fator de segurana. A partir da
3.4 Tipos de Suportes para Tempo Real 83
estimativa do tempo mximo de execuo de cada tarefa, possvel aplicar as equaes

do captulo 2 e analisar se a aplicao ou no escalonvel.
Outro grande obstculo aplicao da teoria de escalonamento obter os atrasos e
bloqueios associados com o SOTR, em funo de chamadas de sistema, interrupes de
hardware, acesso a perifricos, etc. Como destacado na seo 3.3, a anlise de
escalonabilidade requer o conhecimento de detalhes do SOTR que na maioria das vezes
no so disponibilizados pelo fornecedor. Este quadro est mudando lentamente na
medida que os fornecedores percebem a importncia desta informao para os
desenvolvedores de aplicao. Enquanto isto, o projetista de uma aplicao tempo real
fica com trs alternativas:
Desenvolver um suporte proprietrio, que ele ento conhecer em detalhe;
Selecionar um suporte que fornea as informaes necessrias;
Selecionar um suporte que no fornece as informaes necessrias para a
anlise de escalonabilidade e adotar uma abordagem de escalonamento do tipo
melhor esforo.
Quando a aplicao do tipo tempo real brando ("soft real-time"), a preocupao do
projetista resume-se a escolher um sistema operacional com boas propriedades
temporais. Muitas vezes a teoria de escalonamento sequer empregada, no sentido que
no feita uma anlise matemtica de escalonabilidade. Caractersticas como
escalonamento baseado em prioridades preemptivas, "kernel" que executa com
interrupes habilitadas e chaveamento de contexto rpido melhoram o desempenho de
qualquer sistema, independentemente da anlise matemtica. Entretanto, somente a
aplicao dos testes de escalonabilidade descritos no captulo 2 capaz de garantir o
atendimento de requisitos temporais do tipo "hard".
3.4 Tipos de Suportes para Tempo Real
A diversidade de aplicaes gera uma diversidade de necessidades com respeito ao

suporte para tempo real, a qual resulta em um leque de solues com respeito aos
suportes disponveis, com diferentes tamanhos e funcionalidades. De uma maneira
simplificada podemos classificar os suportes de tempo real em dois tipos: ncleos de
tempo real (NTR) e sistemas operacionais de tempo real (SOTR). O NTR consiste de
um pequeno "kernel" com funcionalidade mnima mas excelente comportamento
temporal. Seria a escolha indicada para, por exemplo, o controlador de uma mquina
industrial. O SOTR um sistema operacional com a funcionalidade tpica de propsito
geral, mas cujo "kernel" foi adaptado para melhorar o comportamento temporal. A
qualidade temporal do "kernel" adaptado varia de sistema para sistema, pois enquanto
alguns so completamente re-escritos para tempo real, outros recebem apenas algumas
poucas otimizaes. Por exemplo, o sistema operacional Solaris um "kernel" que
implementa a funcionalidade Unix, mas foi projetado para fornecer uma boa resposta
temporal.
Obviamente a soluo de escalonamento oferecida em cada suporte tambm varia, e
depende do mercado alvo. Todas as abordagens apresentadas no captulo 2 encontram
utilidade em algum cenrio de aplicao e acabam sendo incorporadas em algum tipo de
suporte. As solues mais populares so o executivo cclico para NTR dedicados e
escalonamento baseado em prioridades, mas sem garantias, para SOTR. Uma lista de
suportes para tempo real com cerca de 100 referncias pode ser encontrada no anexo 2.
A figura 3.7 procura resumir os tipos de suportes encontrados na prtica. Esta uma
classificao subjetiva, mas permite entender o cenrio atual. Alm do NTR e do SOTR
descritos antes, existem outras duas combinaes de funcionalidade e comportamento
temporal. Obter funcionalidade mnima com pouca previsibilidade temporal trivial,
qualquer ncleo oferece isto. Por outro lado, obter previsibilidade temporal determinista
em um sistema operacional completo muito difcil e ainda objeto de estudo pelos
pesquisadores das duas reas. Embora no seja usual atualmente, razovel supor que
existiro sistemas deste tipo no futuro.
Funcionalidade
mnima completa
Previsibilidade Ncleo de
Futuro...
maior Tempo Real
Previsibilidade Qualquer Ncleo Sistema Operacional

menor Simples Adaptado
Figura 3.7 - Tipos de suportes para aplicaes de tempo real.
3.4.1 Suporte na Linguagem
importante observar que muitas vezes o suporte de tempo real existe, mas fica
escondido do programador da aplicao. Duas situaes so freqentes, especialmente
com NTR. possvel esconder o suporte dentro da prpria linguagem (como em ADA
ou Java) ou do ambiente de programao. Neste caso, os servios normalmente
associados com o sistema operacional no so obtidos atravs de chamadas de sistemas,
mas sim atravs de construes da prpria linguagem de programao. Por exemplo,
no existe alocao e liberao de memria explcita em Java. Muitos ambientes
integrados de desenvolvimento (IDE "Integrated Development Environment")
incluem extensas bibliotecas e pacotes que tambm so usados pelo programador no
lugar das chamadas de sistema.
3.4 Tipos de Suportes para Tempo Real 85
Outra possibilidade aparece em propostas onde no existe a figura de um sistema

operacional separado da aplicao, mas sim um conjunto de mdulos que implementam
servios tpicos de sistemas operacionais e so ligados junto com o cdigo da aplicao.
Neste caso, o projetista da aplicao identifica os servios tpicos de sistemas
operacionais que sero necessrios, seleciona os mdulos que implementam tais
servios e os liga, atravs de um ligador ("link-editor"), aos mdulos da aplicao,
gerando um nico cdigo executvel. De qualquer forma, o suporte para tempo real
estar presente, embora "disfarado".
3.4.2 "Microkernel"
Em funo da dificuldade de prover todos os servios com bom comportamento

temporal, sistemas podem ser organizados em camadas. Na medida em que subimos na
estrutura de camadas, os servios tornam-se mais sofisticados e o comportamento
temporal menos previsvel. A figura 3.8 ilustra um sistema com apenas 3 camadas alm
da aplicao. Alm do hardware existe um "microkernel" que oferece servios bsicos
tais como alocao e liberao de memria fsica, instalao de novos tratadores de
dispositivos e mecanismo para sincronizao de tarefas. O "kernel" do sistema oferece
servios tais como sistema de arquivos e protocolos de comunicao. Assim, a
aplicao tem a sua disposio uma gama completa de servios. Entretanto, quando os
requisitos temporais da aplicao exigem um comportamento melhor, ela pode acessar
diretamente o "microkernel" e at mesmo o hardware. Obviamente este tipo de soluo
mais apropriado para sistemas onde apenas uma aplicao executada, ou todas as
aplicaes esto associadas com o mesmo usurio. Ao permitir que a aplicao acesse
diretamente as camadas inferiores do sistema e at mesmo o hardware, o sistema
operacional abre mo do completo controle sobre o que a aplicao pode e no pode
fazer.
Aplicao
Kernel
Microkernel
Hardware
Figura 3.8 Estratificao de servios em um sistema.
3.4.3 Escolha de um Suporte de Tempo Real
Na verdade muito difcil comparar diferentes SOTR com a finalidade de escolher

aquele mais apropriado para um dado projeto. A escolha de um SOTR no trabalho

simples. Por exemplo, este captulo procurou mostrar os diversos fatores que
influenciam a previsibilidade temporal de um sistema. Entre os fatores que tornam a
escolha difcil podemos citar:
Diferentes SOTR possuem diferentes abordagens de escalonamento.
Desenvolvedores de SOTR publicam mtricas diferentes.
Desenvolvedores de SOTR no publicam todas as mtricas e todos os dados
necessrias para uma anlise detalhada. Por exemplo, detalhes internos sobre o
"kernel" no esto normalmente disponveis.
As mtricas fornecidas foram obtidas em plataformas diferentes.
O conjunto de ferramentas para desenvolvimento de aplicaes que suportado
varia muito.
Ferramentas para monitorao e depurao das aplicaes variam.
As linguagens de programao suportadas em cada SOTR so diferentes.
O conjunto de perifricos suportados por cada SOTR varia.
O conjunto de plataformas de hardware suportados varia em funo do SOTR.
Cada SOTR possui um esquema prprio para a incorporao de novos
tratadores de dispositivos ("device-drivers") e o esforo necessrio para
desenvolver novos tratadores varia de sistema para sistema.
Diferentes SOTR possuem diferentes nveis de conformidade com os padres.
A poltica de licenciamento e o custo associado variam muito conforme o
fornecedor do SOTR (desde custo zero at "royaltes" por cpia do produto
final vendida).
3.5 Exemplos de Suportes para Tempo Real
Esta seo descreve vrias solues disponveis no mercado ou na Internet para o

suporte a aplicaes de tempo real. Como citado antes, existem dezenas seno centenas
de solues, nos mais variados nveis de preo, robustez, funcionalidade e
previsibilidade temporal. O conjunto de solues escolhido para ser apresentado aqui
procura ilustrar os tpicos apresentados nas sees anteriores, sem ter a preteno de
ser um levantamento preciso do mercado. Inicialmente o padro Posix decrito com
maior profundidade, por ser um padro que procura definir caractersticas de
portabilidade para aplicaes, sem dependncias de fornecedores de sistemas
operacionais, e por ser seguido em maior ou menor grau pela maioria dos sistemas
operacionais (Solaris, QNX, etc). Em seguida discutido o escalonamento nos sistemas
3.5 Exemplos de Suportes para Tempo Real 87
Unix SVR4 e Solaris, para mostrar a evoluo do mesmo em direo a um melhor

comportamento temporal. Os sistemas ChorusOS e QNX so apresentados como
solues comerciais especficas para tempo real. Finalmente, o sistema operacional RT-
Linux descrito, por ser uma alternativa vivel dentro do contexto do software livre. O
anexo C deste livro contm uma lista com cerca de 100 sistemas operacionais de tempo
real, incluindo o respectivo endereo na Internet.
3.5.1 Posix para Tempo Real
Posix um padro para sistemas operacionais, baseado no Unix, criado pela IEEE
(Institute of Electrical and Eletronic Engineers). Posix define as interfaces do sistema
operacional mas no sua implementao. Logo, possvel falar em Posix API
("Application Programming Interface"). Na verdade a quase totalidade dos sistemas
operacionais implementam chamada de sistema atravs de interrupo de software. O
Posix padroniza a sintaxe das rotinas de biblioteca que por sua vez executam as
interrupes de software que so a verdadeira interface do "kernel". Isto necessrio
porque a forma de gerar interrupes de software depende do processador em questo e
no pode ser realmente padronizada, ao passo que rotinas de biblioteca podem. Alm da
sintaxe em C, a semntica das chamadas Posix definida em linguagem natural. Como
parte da semntica, so definidas abstraes e uma terminologia prpria. Como Posix na
verdade procurou padronizar o Unix, as abstraes usadas j eram conhecidas da
maioria dos programadores.
O padro Posix na verdade dividido em diversos componentes. Em sua primeira
verso o padro definia apenas a API de um sistema operacional de propsito geral.
Entretanto novos elementos foram includos com o passar do tempo, incluindo a
interface para servios que so importantes no contexto de tempo real. Posix herdou do
Unix o termo "processo", com o mesmo significado do termo "tarefa" empregado neste
texto. Nesta seo vamos continuar usando "tarefa" para manter a coerncia com o resto
do captulo, mesmo nos momentos que a literatura Unix usaria a palavra "processo".
Muitos sistemas operacionais de tempo real possuem uma API proprietria. Neste
caso, a aplicao fica amarrada aos conceitos e s primitivas do sistema em questo.
Um porte da aplicao para outro sistema operacional dificultado pela
imcompatibilidade no somente das chamadas e parmetros, mas das prprias
abstraes suportadas.
Usando um SOTR que compatvel com Posix, a aplicao fica amarrada aos
conceitos e s primitivas do Posix. Alm disto, o porte da aplicao entre sistemas
diferentes, mas compatveis com o Posix, fica muito facilitado. Muitos SOTR
atualmente j suportam a API do Posix, como pode ser constatado atravs de uma visita
s pginas listadas em http://www.cs.bu.edu/pub/ieee-rts.
A documentao do Posix aparece dividida em diversos documentos. Por exemplo,
o padro 1003.1 descreve a funcionalidade bsica de um sistema operacional Unix e
inclui chamadas de sistema para gerncia de tarefas, dispositivos, sistemas de arquivo e

comunicao entre tarefas bsica (IPC "inter-process communication"). O padro
1003.1b estende o 1003.1 para tempo real, incluindo semforos, escalonamento com
prioridades, temporizadores, primitivas para IPC melhoradas e arquivos para tempo
real. O padro 1003.1c permite mltiplas "threads" no mesmo espao de
endereamento. O padro 1003.1d estende ainda mais o 1003.1b para tempo real,
incluindo facilidades para instalar tratadores de interrupo. Como este livro trata de
sistemas de tempo real, qualquer referncia ao "padro Posix" inclui automaticamente o
bsico e tambm todas as extenses definidas para tempo real.
O padro 1003.13 define perfis ("profiles"), isto , subconjuntos de facilidades que
aparecem nos diversos padres e juntas formam uma soluo apropriada para uma
determinada classe de aplicaes. Uma vez que o padro Posix extenso, implementar
todos os recursos previstos implica em muito software. A idia usar Posix mesmo em
pequenos sistemas embutidos em equipamentos industriais e domsticos. Muitas
empresas iro preferir desenvolver implementaes parciais, e os perfis ajudam a
diminuir as variaes possveis dentro do universo de solues Posix. Para tempo real
foram definidos vrios perfis:
Pequeno sistema controlando um ou mais dispositivos, nenhuma interao com
operador, no tem sistema de arquivos, apenas uma tarefa com mltiplas
"threads";
Inclui sistema de arquivos e entrada e sada assncrona;
Inclui suporte para MMU ("Memory Management Unit"), vrias tarefas com
mltiplas "threads", mas sem sistema de arquivos;
Capaz de executar uma mistura de tarefas tempo real com tarefas
convencionais, inclui MMU, dispositivos de armazenamento (discos, fitas, etc),
suporte para rede, etc.
Um aspecto central para as aplicaes de tempo real o escalonamento. Posix
suporta escalonamento baseado em prioridades, as quais podem ser definidas em tempo
de execuo. No mnimo 32 nveis de prioridades devem ser suportados, embora o
nmero exato seja definido por cada implementao. Em conjunto com o esquema de
prioridades existem polticas de escalonamento que definem como so escalonadas
"threads" com a mesma prioridade. Isto pode ser feito via FIFO ("First-In First-Out"),
fatias de tempo ou outra poltica qualquer definida pela implementao. Desta forma o
programador sabe que pode contar com um escalonamento bsico em todos os SOTR
tipo Posix, ao mesmo tempo que permite inovaes neste campo.
A princpio as "threads" so criadas para competir com todas as outras "threads" do
sistema pelo tempo do processador. Entretanto, a competio tambm pode acontecer
por tarefa, sendo ento necessrio definir um critrio para dividir o tempo do
processador entre tarefas. Uma implementao Posix em particular pode suportar
apenas uma destas opes ou ambas.
Posix inclui as primitivas clssicas "fork" para criao de uma tarefa filha e "wait"
para esperar pelo trmino de outra tarefa. Alm disto, cada tarefa pode conter vrias
"threads". As "threads" de uma mesma tarefa compartilham o seu espao de
endereamento mas possuem alguns atributos particulares, como o tamanho da sua pilha
individual.
Com respeito a mecanismos de sincronizao, o padro oferece uma coleo deles.
Posix inclui semforos que podem ser usados para sincronizar "threads" de diferentes
tarefas. Embora semforos possam ser usados para sincronizar "threads" da mesma
tarefa, o custo envolvido alto e existem alternativas mais eficientes. Alm das
tradicionais operaes P e V, existe uma operao P no bloqueante e uma primitiva
para determinar o valor atual do semforo.
Quando o objetivo da sincronizao garantir o acesso exclusivo a uma seo
crtica, Posix oferece a construo "mutex". Uma varivel tipo "mutex" suporta as
operaes "lock" e "unlock" e sua implementao mais eficiente do que semforos.
Variveis "mutex" tambm suportam os protocolos de herana de prioridade e uma
variao do "prioriry ceiling".
A sincronizao baseada em condies pode ser construda atravs de variveis
condio. Uma "thread" fica bloqueada junto a uma varivel condio atravs das
operaes "wait" ou "timedwait". Ela acordada quando outra "thread" executar uma
operao "signal" (acorda uma "thread") ou "broadcast" (acorda todas as "threads")
sobre a varivel condio em questo.
Cada varivel condio associada com uma varivel "mutex" quando criada.
Para ficar bloqueado em uma varivel condio uma "thread" deve ter antes executado
um "lock" sobre o "mutex" associado. No momento que a "thread" ficar bloqueada na
varivel condio o "mutex" automaticamente liberado. Da mesma forma, quando
uma "thread" acordada da varivel condio, automaticamente solicitado um "lock"
sobre o "mutex" associado. A "thread" somente retoma sua execuo aps ter obtido
novamente o "lock" sobre o "mutex". Embora o Posix no especifique qual "thread"
ganha o "mutex" quando uma "thread" acorda outra, o escalonamento baseado em
prioridades resolve a questo executando a "thread" com maior prioridade. Esta
operao conjugada de "mutex" e varivel condio permite facilmente a
implementao de construes do tipo monitores, como descrito em [BuW97]. Isto
pode ser feito atravs de disciplina de programao e chamadas diretas ao sistema
operacional ou ento pode ser usado por um compilador para implementar monitores a
nvel da linguagem de programao.
Posix tambm define um mecanismo chamado fila de mensagens, o qual
semelhante a caixas postais, pois a comunicao assncrona e o endereamento
indireto (endereo de fila e no de tarefa). Cada fila de mensagens pode ter vrios
leitores e vrios escritores. Mensagens podem ter prioridades, usada ento para ordenar
as mensagens na fila. Filas de mensagens podem ser usadas para a comunicao entre
"threads" da mesma tarefa mas, em funo do custo associado, faz mais sentido usa-las
para a comunicao entre "threads" de tarefas diferentes. "Mutexes" e variveis
compartilhadas o mecanismo mais apropriado para "threads" da mesma tarefa.

Uma fila de mensagem recebe um nome ao ser criada. Para ser acessada ela deve ser
aberta, de maneira semelhante a um arquivo. As operaes so tambm semelhantes s
operaes utilizadas para acessar arquivos. Uma mensagem enviada atravs da
operao "send". Ela recebida atravs da operao "receive", a qual pode ser
bloqueante ou no bloqueante. Quando vrias "threads" esto esperando para retirar
uma mensagem de uma fila vazia, o escalonamento baseado em prioridades define qual
ser atendida antes. O mesmo pode acontecer com vrias "threads" esperando para
colocar uma mensagem na fila, pois a mesma pode ter uma capacidade mxima definida
no momento de sua criao.
Posix suporta a existncia de vrios relgios simultaneamente, cada um possui um
identificador prprio. O padro exige que cada implementao oferea no mnimo um
relgio, chamado CLOCK_REALTIME, com resoluo mnima de 20 ns. Esta
resoluo diz respeito aos parmetros mas no garante que a passagem do tempo no
sistema seja medida em termos de intervalos de 20 ns cada. Uma espera relativa
obtida atravs da chamada sleep (mltiplo de segundo) ou da chamada "nanosleep"
(resoluo maior). A "thread" ser bloqueada no mnimo pelo tempo solicitado.
Um aspecto importante do Posix, como de resto de qualquer sistema operacional
tipo Unix, so os sinais. Durante a execuo de uma tarefa erros do tipo "acesso ilegal a
memria" (SIGSEGV), "instruo ilegal" (SIGILL) e "diviso por zero" (SIGFPE) so
detectados pelo "kernel" que gera um sinal para informar a aplicao. O programador
da aplicao pode tratar este tipo de erro associando uma rotina da aplicao que ser
executada sempre que este sinal for gerado. Aps a execuo do tratador do sinal, a
tarefa retomada a partir do ponto onde foi interrompida. O mecanismo de sinais
importante para aplicaes de tempo real pois permite a implementao de tcnicas de
tolerncia a faltas. Entretanto, por ser um mecanismo assncrono (se e quando vai
ocorrer desconhecido do programador), ele dificulta a anlise de escalonabilidade do
sistema.
Uma utilizao clssica de sinais no contexto de tempo real aparece associada com
temporizadores. Uma tarefa pode solicitar uma determinada temporizao ao "kernel"
ou a uma biblioteca. A tarefa avisada que a temporizao terminou pelo sinal
SIGALRM. Sinais tambm podem ser utilizados para sinalizar a chegada de uma
mensagem em uma fila at ento vazia, quando no existem "threads" bloqueadas
esperando.
Acontecimentos importantes na vida da aplicao tambm podem ser indicados por
sinais. Por exemplo, a perda de um "deadline", uma falha no hardware, uma mudana
no modo de operao ("mode change") podem ser programados na forma da emisso de
um ou mais sinais por parte da "thread" que detecta o evento. As demais tarefas da
aplicao recebem o sinal e mudam o seu comportamento em funo do evento que ele
sinaliza. Este estilo de programao complexo e sujeito a "bugs". Efeito semelhante
pode ser obtido atravs de uma "thread" que espera pela ocorrncia do evento e ento
aborta ou suspende as "threads" envolvidas e toma as providncias necessrias para que
a aplicao responda de forma adequada ao evento sinalizado. Embora as duas formas

de programao sejam equivalentes em poder de expresso, o uso de "threads" e
mecanismos de sincronizao explcitos gera um cdigo mais legvel do que sinais
assncronos.
Para aplicaes convencionais o Posix define os sinais SIGUSR1 e SIGUSR2, os
quais no carregam qualquer informao adicional alm do prprio sinal. Para tempo
real definido um conjunto de sinais entre SIGRTMIN e SIGRTMAX, com no mnimo
8 sinais. Estes sinais podem carregar dados adicionais alm da sinalizao em si e so
enfileirados, ao passo que os outros tipos de sinais no so enfileirados mas
sobrescritos. Alm disto, caso vrios sinais de tempo real estejam enfileirados para uma
dada tarefa, aquele com menor valor sempre entregue antes.
Muitos sinais so gerados pelo "kernel", por tratar-se de uma situao de erro ou por
estarem associados com uma ao de teclado (Control-C normalmente gera SIGINT). O
cdigo da aplicao pode gerar sinais atravs da chamada de sistema "kill" (sinais
convencionais) e da chamada de sistema "sigqueue" (sinais de tempo real). So
necessrias chamadas diferentes em funo dos parmetros adicionais passados com os
sinais de tempo real.
O conceito de sinais foi introduzido j nas primeiras verses do Unix, por volta de
1970, quando o conceito de "threads" no era comum e estas no eram suportadas pelo
Unix. O conceito de sinais coerente com um fluxo de execuo por tarefa, mas foi
necessrio adapta-lo para o contexto de mltiplas "threads". Alguns sinais so enviados
para uma "thread" especfica, outros so enviados para uma "thread" qualquer da
tarefa, novas primitivas foram criadas especialmente para lidar com a existncia de
"threads". Uma anlise detalhada do servio de sinais foge do escopo deste livro. Na
verdade sinais foram utilizados originalmente, em grande parte, para contornar a falta
de "threads". Com a disponibilidade de mltiplas "threads" por tarefa a utilidade dos
sinais diminuiu muito. Entretanto, existe uma enorme quantidade de cdigo para Unix
que utiliza sinais (sem falar nos prprios programadores). Esta situao dever perdurar
por muito tempo.
Uma descrio completa do Posix capaz de ocupar um livro inteiro, como em
[Gal95]. Pelo resumo apresentado nesta seo possvel perceber que, em termos
funcionais, o Posix cobre as necessidades expostas no incio do captulo. Na verdade ele
oferece muito mais do que o necessrio para sistemas tempo real pequenos. O
mecanismo de perfis ("profiles") permite a um implementador de SOTR fornecer
apenas as facilidades Posix que so importantes para o mercado pretendido. Mesmo
existindo esta flexibilidade sobre quais facilidades estaro presentes em uma dada
implementao Posix, as facilidades presentes devem implementar as abstraes e
apresentar as interfaces previstas no padro. Desta forma, programadores sempre
encontraro um ambiente de programao familiar. Cabe apenas ao projetista escolher a
implementao Posix com as facilidades apropriadas.
importante notar que, como o padro extenso, a compatibilidade com Posix
quase sempre completa com alguns perfis e parcial com outros. Muitas vezes o
fornecedor de um SOTR anuncia vagamente que "segue o Posix", sem especificar o

perfil em questo ou se algo parcial e no corresponde exatamente a um perfil
padronizado. Parece ser algo bom para o marketing do SOTR mas obriga o projetista da
aplicao fazer um estudo detalhado do sistema operacional. Existe um processo formal
de homologao (ver http://www.computer.org), mas a maioria dos SOTR no mercado
no passaram por ele.
Muitos SOTR suportam duas interfaces, uma Posix e uma proprietria. Isto acontece
porque a interface proprietria j existia e sobre ela foi implementada uma biblioteca
com interface Posix, ou porque na interface proprietria podem ser feitas otimizaes
que resultam em melhor desempenho.
importante observar que o padro Posix preocupa-se com as interfaces e a
funcionalidade. Com respeito aos aspectos temporais a questo mais complexa. Na
verdade o padro no especifica (propositadamente) como o "kernel" deve ser
implementado, qual deve ser o tempo de execuo de cada chamada de sistema, qual
deve ser o tempo de processador gasto para executar funes do sistema. Sendo assim,
estes elementos dependem totalmente da implementao Posix sendo usada. Pode-se
contar com aquilo que est no padro, como escalonamento baseado em prioridades e
variveis "mutex" suportanto uma variao do "priority ceiling protocol". Entretanto,
como discutido antes neste captulo, uma boa lista de perguntas sobre o comportamento
temporal ainda fica para ser respondida por quem implementa o sistema operacional.
3.5.2 Escalonamento no Unix SVR4
Embora o Unix SVR4 no implemente exatamente a soluo de escalonamento do

Posix, elas so semelhantes. Seja como for, a soluo do SVR4 muito melhor do que
aquela apresentada antes como a do Unix tradicional. Uma descrio detalhada deste
sistema operacional, assim como de vrias outras verses do Unix, pode ser encontrada
em [Vah96]. Novamente vamos utilizar a palavra "tarefa" para denotar o conceito
associado com o termo "processo" no mundo Unix.
No SVR4 classes de escalonamento definem a poltica de escalonamento para as
tarefas. Como "default", SVR4 fornece duas classes: "time-sharing" e tempo real. A
tarefa com prioridade maior sempre executa, com exceo de partes no interrompveis
do "kernel". Existem 160 nveis de prioridades, onde um nmero maior representa uma
prioridade mais elevada. Existe uma diviso prvia entre as classes de escalonamento: 0
a 59 para a classe time-sharing, 60 a 99 so prioridades usadas pelo cdigo do sistema e
os nmeros entre 100 e 159 so utilizados pelas tarefas da classe de tempo real.
Uma tarefa executando cdigo do "kernel" pode ser preemptada apenas nos pontos
de interrupo ("preemption points"). A atribuio e atualizao das prioridades de
cada tarefa feita pela classe em questo. Novas classes de escalonamento podem ser
escritas e instaladas no sistema. O cdigo de uma classe de escalonamento organizado
de forma semelhante a um tratador de dispositivo ("device-driver"), pois deve fornecer
cdigo para suportar uma interface padro definida pelo SVR4, cujas rotinas sero
chamadas sempre que uma deciso de escalonamento envolvendo tarefas daquela classe
forem necessrias. Desta forma, alm das duas classes providas sempre, o projetista
livre para criar sua prpria soluo de escalonamento. Obviamente ser muito mais fcil
portar a aplicao para outras instalaes se apenas as classes de escalonamento bsicas
forem utilizadas.
A classe "time-sharing" a classe "default" das tarefas. Tarefas possuem
prioridades variveis, definidas em tempo de execuo. Fatias de tempo so usadas para
dividir o tempo do processador entre tarefas de mesma prioridade. A durao da fatia de
tempo depende da prioridade da tarefa (menor prioridade, maior fatia). Em vez de
recalcular a prioridade de cada tarefa a cada segundo (como no Unix SVR3), o SVR4
recalcula a prioridade de uma tarefa somente na ocorrncia de eventos associados com a
tarefa. Desta forma o custo computacional deste reclculo drasticamente reduzido.
A prioridade reduzida sempre que a fatia de tempo esgotada pela tarefa. A
prioridade elevada sempre que a tarefa fica bloqueada por alguma razo ou fica muito
tempo sem esgotar sua fatia de tempo (provavelmente porque outras tarefas de maior
prioridade esto sempre tomando o processador). O reclculo rpido, pois o evento
em geral afeta uma nica tarefa de cada vez.
O descritor de uma tarefa contm, entre outros campos:
ts_timeleft - tempo restante na fatia;
ts_cpupri - parte da prioridade definida pelo sistema;
ts_upri - parte da prioridade definida pelo usurio (nice, entre -20 e +19);
ts_umdpri - prioridade em modo usurio, ts_cpupri + ts_upri, valor mximo de
59;
ts_dispwait - nmero de segundos desde o incio da fatia.
Quando uma tarefa acorda de um bloqueio dentro do "kernel" a sua nova prioridade
dentro do "kernel" determinada pela condio de bloqueio da qual acorda. Ao voltar
para modo usurio a prioridade definida pelo campo ts_umdpri. Uma tabela de
parmetros determina como ts_cpupri calculada. Ela contm uma entrada para cada
nvel de prioridade possvel no sistema. Os campos desta tabela determinam o
funcionamento de um mecanismo de envelhecimento ("aging").
A classe tempo real utiliza prioridades entre 100 e 159, maiores que qualquer tarefa
time-sharing. Quando uma tarefa tempo real liberada, ela obtm o processador
imediatamente no caso de estar executando uma tarefa time-sharing em modo usurio.
No caso de uma tarefa "time-sharing" estar executando cdigo do "kernel", a tarefa
tempo real ser obrigada a esperar que a tarefa "time-sharing" execute at atingir o
prximo ponto de interrupo do "kernel". Esta espera pode ser relativamente grande e
prejudica bastante o tempo de resposta das tarefas de tempo real no Unix SVR4.
Cada tarefa tempo real caracterizada pela sua prioridade e pela sua fatia de tempo.
A tabela de parmetros empregada por esta classe contm apenas a fatia de tempo
"default" para cada nvel de prioridade. Tipicamente so fatias maiores para prioridades
menores, pois espera-se que as tarefas de prioridade maior sejam muito curtas.
Entretanto, como fatias de tempo so usadas apenas para tarefas de mesma prioridade,
este mecanismo pode ser completamente ignorado em anlises de escalonabilidade.
Uma figura de mrito importante a latncia desde uma interrupo de hardware at
o disparo da tarefa que trata este evento. Quando o evento ocorre ele sinalizado por
uma interrupo. Existe o processamento da interrupo, a qual libera a tarefa de tempo
real. Se houver uma tarefa "time-sharing" executando cdigo do "kernel", ser
necessrio esperar que ela chegue at o prximo ponto de interrupo. Neste momento
ocorre o chaveamento de contexto e a tarefa tempo real inicia a sua execuo. O cdigo
da aplicao executado, respondendo ao evento. Observe que, para o tempo de
resposta da tarefa tempo real, ainda seria necessrio incluir as interferncias e bloqueios
causados por outras tarefas tempo real da prpria aplicao.
Certamente a soluo de escalonamento do SVR4 melhor do que a soluo Unix
tradicional. Entretanto, ainda no satisfatria para muitas aplicaes de tempo real,
pois em geral melhora o desempenho mas no resolve completamente o problema da
previsibilidade. Alm do "kernel" no ser interrompvel em qualquer ponto, difcil
ajustar o sistema para um conjunto misto de aplicaes. Por exemplo, experincias
envolvendo um editor simples, uma tarefa em "background", e uma sesso de vdeo
usando X-server, mostraram que nenhuma atribuio de classes e prioridades resolve
completamente o problema de compartilhamento do processador neste sistema
operacional. Alm disto, os tempos das chamadas de sistema e os tempos mximos de
bloqueio dentro do "kernel" no so conhecidos.
3.5.3 Escalonamento no Solaris 2.x
O Solaris uma variao do Unix fornecido pela Sun Microsystems. A soluo de

escalonamento do sistema operacional Solaris melhora o escalonamento do Unix SVR4
em vrios aspectos. O "kernel" do Solaris completamente preemptvel, isto ,
interrupes podem acontecer mesmo quando uma "thread" est executando cdigo do
"kernel". Na verdade as interrupes so desabilitadas apenas muito rapidamente em
alguns poucos pontos. Isto diminui a latncia no atendimento das interrupes mas
exige que as estruturas de dados do "kernel" sejam protegidas por mecanismos de
sincronizao. Interrupes na verdade ativam "threads" especiais do "kernel", que
podem ficar bloqueadas se necessrio. Isto acontece quando a "thread" especial
necessita acessar uma estrutura de dados em uso por uma "thread" normal. As
"threads" associadas com interrupes possuem a prioridade mais alta no sistema.
Da mesma forma que o Unix SVR4, so empregadas classes de escalonamento.
Alm das classes fornecidas, novas classes podem ser carregadas dinamicamente. O
escalonador suporta multiprocessamento, usando uma fila nica de "threads" para todos
os processadores. A exceo so as "threads" de interrupo, associadas

necessariamente com o processador onde a interrupo aconteceu. Isto necessrio pois
o tratamento da interrupo de hardware pode exigir o acesso a um controlador de
dispositivo conectado com aquele processador em particular.
Embora o modelo bsico seja elegante, existe tambm o que poderia ser chamado de
"escalonamento escondido". Por exemplo, quando uma tarefa vai voltar para modo
usurio depois de executar cdigo do "kernel", verificado se existe alguma pendncia
nos mdulos do "kernel" que implementam "streams" ("streams" so tipicamente
associadas com protocolos de comunicao). Caso exista, esta tarefa executa a
pendncia, "prestando um favor" para as tarefas que esto usando os servios dos
"streams". Se estas tarefas possurem prioridade menor do que aquela deixando o
"kernel", temos uma situao de inverso de prioridades. Este problema no to
grande pois o Solaris utiliza nas "threads" do "kernel" uma prioridade menor do que as
"threads" de tempo real. Mas se forem as "threads" de tempo real que esto usando os
"streams", ento elas sero prejudicadas.
Com respeito a inverso de prioridades devido ao compartilhamento de estruturas de
dados, o "kernel" do Solaris suporta parcialmente herana de prioridades. Ocorre que
dentro do "kernel" so usados quatro tipos de mecanismos de sincronizao. "Mutexes"
suportam corretamente herana de prioridades, mas no caso dos semforos e das
variveis condio o dono do "lock" ("thread" que bloqueou o recurso) no conhecido
e a herana de prioridade no pode ser usada. Existe ainda um mecanismo do tipo
"bloqueio leitor/escritor" onde a herana de prioridades funciona apenas para os
escritores e o primeiro leitor.
Uma anlise completa do "kernel" Solaris foge do escopo deste livro (ver [Vah96]).
Entretanto, os problemas apresentados nos pargrafos anteriores ilustra o nvel de
complexidade presente na anlise temporal do "kernel" de um sistema operacional
completo como o Solaris. No sem razo que sistemas operacionais com
funcionalidade completa podem at ser rpidos, mas no apresentam um
comportamento determinista.
3.5.4 ChorusOS
O sistema operacional ChorusOS (http://www.sun.com/chorusos/), fornecido pela

Sun Microsystems, a base para tempo real da soluo de software proposta pela Sun
para o setor de telecomunicaes. O ChorusOS pode ser considerado como o sistema
operacional de tempo real que complementa o sistema operacional Solaris. Com estes
dois sistemas operacionais a Sun procura prover uma soluo completa para o setor de
telecomunicaes, no que se refere a sistemas operacionais.
O mercado visado pelo sistema operacional ChorusOS principalmente o dos
equipamentos de telecomunicaes. O ChorusOS usado em centrais pblicas e
privadas de telefonia, assim como em sistemas de comunicao de dados, "switches",
sistemas de mensagens faladas, estaes de telefonia celular, "web-phones", telefones

celulares e sistemas de transmisso via satlite.
Alm do sistema operacional propriamente dito, a Sun comercializa o "Sun
Embedded Workshop", um ambiente integrado de desenvolvimento (IDE "Integrated
Development Environment") que inclui as ferramentas e todos os componentes
necessrios para construir instncias executveis do ChorusOS. Esta IDE sempre
adaptada para uma determinada plataforma alvo e uma plataforma de desenvolvimento.
Presentemente as seguintes plataformas alvo so suportadas:
ix86 (desenvolvimento no Solaris ou no Windows NT);
UltraSPARC IIi (desenvolvimento no Solaris);
PPC603, 604, 750, 821, 823, 860, 8260 (desenvolvimento no Solaris);
PPC603, 604, 750, 860 (desenvolvimento no Windows NT).
O ChorusOS tambm o sistema operacional subjacente ao "JavaOS for
Consumers". O "JavaOS for Consumers" aproveita a capacidade do "microkernel" do
ChorusOS em suportar vrias plataformas alvo e prover um ambiente de tempo real para
o desenvolvimento de aplicaes em Java visando a eletrnica de consumo.
O ChorusOS emprega uma arquitetura baseada em componentes que permite a
incluso de diferentes servios no executvel do sistema operacional. Isto permite um
ajuste fino do "kernel", de acordo com o plataforma alvo, a memria disponvel e as
necessidades da aplicao. O "kernel" pode iniciar com apenas 10 Kbytes e crescer a
medida que componentes so acrescentados. Mltiplas personalidades e APIs podem
executar simultaneamente sobre a mesma plataforma de hardware. Isto facilita a
integrao de aplicaes j existentes em novos sistemas que executam sobre o
ChorusOS. As seguintes APIs so suportadas:
API nativa do CHORUS;
RT-POSIX (1003.1b/lc);
Java runtime and services;
Sistemas operacionais legados.
O ChorusOS inclui um "microkernel" de 10 Kbytes, que suporta uma nica
aplicao composta por vrias "threads". A gerncia de interrupes de hardware e de
software deve ser provida pela aplicao. Para aplicaes maiores pode ser usado um
"kernel" que suporta mltiplos usurios independentes alm de programas de sistema.
Aplicaes podem executar no espao de endereamento do sistema ou de usurio.
Existe um escalonador de tempo real com prioridades preemptivas e FIFO para
"threads" de mesma prioridade. Alternativamente, pode ser usado um escalonador que
suporta vrias classes de tarefas, incluindo "prioridade preemptiva e FIFO", "prioridade
com fatias de tempo", "estilo Unix" ou ento uma poltica definida pela aplicao.
A gerncia de memria inclui 4 possibilidades: Gerncia da memria fsica, sem
proteo; Mltiplos espaos de endereamento protegidos; Espaos de endereamento

paginados protegidos; Memria virtual com paginao sob demanda.
A comunicao entre tarefas inclui troca de mensagens com transparncia de
distribuio, caixas postais e filas de mensagens tempo real. Para sincronizao existem
semforos, "mutexes", "mutexes" de tempo real (reduzem a inverso de prioridade) e
sinalizao de eventos.
Existe amplo suporte para servios de tempo e gerncia de interrupes. O mesmo
acontece com sistemas de arquivos, os quais incluem: UFS e FFS do Unix com
apontadores de 64 bits; "Flash File System" baseado no sistema de arquivos do MS-
DOS mas com nomes longos; compartilhamento de arquivos atravs do NFS (cliente e
servidor); etc.
Com respeito a redes de comunicao, o ChorusOS oferece uma pilha TCP/UDP/IP
completa, incluindo suporte para mltiplas interfaces de rede, roteamento entre
mltiplas interfaces, IP "forwarding", IP "multicast". Suporta "sockets". Inclui SLIP e
PPP, DHCP, servidores de nomes, rsh, Xclients (Xlib, Xt, Xmu, Xext, Xaw) alm do
Sun RPC. A nvel de hardware suporta ethernet, linha serial, VME-backplane e cPCI.
Como pode ser visto, o ChorusOS um sistema operacional flexvel com respeito ao
seu tamanho. Todas as caractersticas listadas antes (sistemas de arquivos, protocolos de
rede, etc) so configurveis. Assim, o projetista da aplicao inclui na sua verso do
ChorusOS apenas as facilidades realmente necessrias. Com respeito ao comportamento
temporal, a documentao da Sun bastante restrita, situao na verdade tpica. O
dados disponveis informam apenas o tempo tpico do chaveamento de tarefas e a
mxima latncia at o disparo de um tratador de interrupo. Um SOTR com amplos
recursos pode tornar-se um problema, pois quanto mais funcionalidade do sistema
utilizada, mais difcil fica prever o seu comportamento temporal.
3.5.5 Neutrino e QNX
O sistema operacional QNX consiste de um "microkernel"

(http://www.qnx.com/products/os/qnxrtos.html) e uma coleo de mdulos opcionais
para os servios como sistemas de arquivos, redes, interfaces grficas de usurio, etc. O
"microkernel" responsvel por criar tarefas, gernciar a memria e controlar
temporizadores. O "microkernel" tambm inclui API POSIX.1 certificada e muitos
servios tempo real do POSIX.1b. Esta diviso em "microkernel" e mdulos permite ao
QNX ser pequeno o bastante para ser colocado em ROM, mas ser capaz de crescer
atravs da adio de mdulos at transformar-se em um sistema operacional distribudo
com funcionalidade completa. O software de rede do QNX chamado FLEET e cria um
conjunto homogneo de recursos que podem ser acessados de forma transparente.
O QNX inclui relgios e temporizadores estilo Posix, interrupes aninhadas,
instalao e desinstalao dinmica de tratadores de interrupes e compartilhamento
de memria. O QNX suporta 32 nveis de prioridades preemptivas e oferece a escolha

do algoritmo de escalonamento para tarefas de mesma prioridade. Uma caracterstica
interessante, servidores podem ter a sua prioridade definida pelas mensagens que eles
recebem dos clientes.
Diversos sistemas de arquivos podem ser executados simultaneamente, entre eles:
Sistema de arquivos Posix, com semntica POSIX.1 e Unix completa; Sistema de
arquivos embutido ("embedded"), em diversas verses; Protocolo SMB ("Server
Message Block") para compartilhamento de arquivos; NFS; Sistema de arquivos DOS;
Sistema de arquivos para CD-ROM; etc.
Algumas mtricas so apresentadas na documentao do QNX. Estes valores foram
medidos em um processador Pentium/133 com um Adaptec 2940 Wide SCSI controller,
um Barracuda SCSI-Wide disk drive, um 100 Mbit PCI-bus Digital 21040 Ethernet
card, e um 10 Mbit ISA-bus NE2000 Ethernet card:
Chaveamento de contexto: 1.95 sec (completo, a nvel de usurio);
Latncia de interrupo: 4.3 sec;
Latncia de escalonamento:7.8 sec;
Disk I/O (baseado em registros de 16384 bytes): 4 Mbytes/s (leitura) e 5,3
Mbytes/s (escrita);
Network throughput: 1.1 Mbytes/s (10 Mbit Ethernet) e 7.5 Mbytes/s (100 Mbit
Ethernet).
Abaixo apresentada a latncia de interrupes e tarefas. Todos os tempos so
dados em microsegundos:
Processor Chaveamento de contexto Latncia de interrupo
Pentium/133 1.95 4.3
Pentium/100 2.6 4.4
486DX4 6.75 7
386/33 22.6 15
Com interrupes aninhadas, estas latncias de interrupo representam a latncia
no pior caso para a interrupo de maior prioridade. A prioridade de uma interrupo
pode ser definida pela aplicao e a latncia de interrupes associadas com prioridades
menores definida em parte pelos tempos de execuo dos tratadores de interrupo
especficos da aplicao.
O QNX suporta diversos processadores, tais como AMD lanSC300/310/400/410,
Am386 DE/SE, Cyrix MediaGX, Intel386 EX, Intel486, ULP Intel486, Pentium
(com/sem MMX), Pentium Pro, Pentium II, STPC da STMicroelectonics, e todos os
processadores genricos baseados em x86 (386 e depois). Alm disto, existe suporte
para uma enorme variedade de barramentos e perifricos.
Outro sistema operacional de tempo real comercializado pela mesma empresa o

QNX Neutrino (http://www.qnx.com/products/os/neutrino.html). O "microkernel" do
Neutrino fornece servios de tempo real essenciais para aplicaes embutidas
("embedded"), incluindo troca de mensagens, servios de "threads" do Posix,
"mutexes", variveis condio, semforos, sinais e escalonamento. Ele pode ser
estendido para suportar as filas de mensagens do Posix, sistemas de arquivos, redes de
computadores, e outras facilidades a nvel de sistema operacional atravs de mdulos de
servio que so plugados ao "microkernel".
A arquitetura do Neutrino baseada em troca de mensagens e forma um barramento
de software que permite a aplicao plugar e desplugar mdulos do sistema operacional
sem necessidade de reinicializar o sistema. O resultado um sistema operacional
bastante flexvel.
Por exemplo, possvel ligar ("to link") o cdigo da aplicao diretamente com o
"microkernel" para criar uma imagem de memria nica, com mltiplas "threads", para
sistemas embutidos pequenos (soluo muitas vezes empregada tambm por executivos
de tempo real mais simples). Alternativamente, possvel executar o mdulo "gerente
de tarefas" e obter todos os servios de um modelo tradicional de tarefas, como
proteo de memria e mltiplas aplicaes, com APIs baseadas no Posix. Entre os
mdulos disponveis existe:
Sistema de janelas para plataformas com recursos limitados;
Mdulos de inicializao que so descartados aps a sua execuo;
Gerncia de tarefas, com "threads", proteo de memria, etc;
Diversos sistemas de arquivos, incluindo o "Embeddable QNX Filesystem
Manager" compatvel com Posix 1003.1, sistemas de arquivos para memria
Flash e "CD-ROM Filesystem Manager";
Protocolos TCP/IP, incluindo ftp, ftpd, telnet, telnetd e outros, alm de PPP e
rede local;
Gerncia de linhas seriais.
A lista de processadores suportados pelo Neutrino inclui: x86 - 386, i386 EX,
Am386SE/DE, AMD lanSC400/410, 486, Cyrix MediaGX, Pentium, Pentium Pro,
Pentium II, PowerPC - 401, 403, 603e, 604e, 750, MPC860, MPC821, MPC823, MIPS
- R4000, R5000, NEC VR4300/4102/4111, VR5000, IDT R4700, QED
RM5260/5270/5261/5271.
Na verdade o QNX e o QNX Neutrino ocupam faixas sobrepostas do mercado de
sistemas operacionais de tempo real. A princpio o Neutrino voltado para aplicaes
menores, embutidas, ao passo que o QNX tradicional visa aplicaes maiores,
possivelmente distribudas. Mas existe uma certa fatia do mercado que pode ser
atendida tanto por um como pelo outro.
3.5.6 Linux para Tempo Real
Linux um sistema operacional com fonte aberto, estilo Unix, originalmente criado
por Linus Torvalds a partir de 1991 com o auxlio de desenvolvedores espalhados ao
redor do mundo. Linux "free software" no sentido que pode ser copiado, modificado,
usado de qualquer forma e redistribudo sem nenhuma restrio. Entretanto, ningum
usando Linux ou criando uma adaptao do Linux pode tornar o produto resultante
proprietrio. Desenvolvido sob o "GNU General Public License", o cdigo fonte do
Linux est disponvel de graa para todos.
O sistema operacional Linux uma implementao independente do Posix e inclui
multiprogramao, memria virtual, bibliotecas compartilhadas, protocolos de rede
TCP/IP e muitas outras caractersticas consistentes com um sistema multiusurio tipo
Unix. Uma descrio completa do Linux no cabe neste livro. Alm da pgina oficial
http://www.linux.org, qualquer pesquisa na Internet ou na livraria vai revelar uma
enorme quantidade de material sobre o assunto.
O Linux convencional segue o estilo de um "kernel" Unix tradicional, no baseado
em "microkernel", e portanto no apropriado para aplicaes de tempo real. Por
exemplo, em [ENS99] descrita uma aplicao onde uma aplicao de controle de
aproximao de aeronaves em aeroportos executada simultaneamente com outros
programas que representam uma carga tipicamente encontrada em sistemas operacionais
de tempo real. A aplicao em questo utiliza um servidor grfico X e deve apresentar
as informaes dentro de certos limites de tempo, o que a caracteriza como uma
aplicao de tempo real "soft". O sistema operacional Linux kernel 2.0 foi utilizado.
Mesmo quando a aplicao tempo real executa na classe "real-time" e as demais
aplicaes executam na classe "time-sharing" o desempenho no foi completamente
satisfatrio. Em especial, tarefas "daemon" que executam servios tanto para aplicaes
de tempo real como para aplicaes convencionais executam com sua prpria
prioridade e atendem as requisies pela ordem de chegada. Neste momento, as tarefas
de tempo real perdem a vantagem que tem com respeito a poltica de escalonamento e
passam a ter o mesmo atendimento que qualquer outra tarefa.
Entretanto, o "kernel" do Linux possui um recurso que facilita sua adaptao para o
contexto de tempo real. Embora o "kernel" seja monoltico e ocupe um nico espao de
endereamento, ele aceita "mdulos carregveis em tempo de execuo", os quais
podem ser includos e excludos do "kernel" sob demanda. Estes mdulos executam em
modo privilegiado e so usados normalmente na implementao de tratadores de
dispositivos ("device-drivers"), sistemas de arquivos e protocolos de rede. No caso dos
sistemas de tempo real, esta caracterstica facilita a transferncia de tecnologia da
pesquisa para a prtica. Solues de escalonamento tempo real podem ser implantadas
dentro do "kernel" de um sistema operacional de verdade. Como o cdigo fonte do
"kernel" do Linux aberto, possvel estudar o seu comportamento temporal, algo que
impossvel com SOTR comerciais cujo "kernel" tipicamente uma caixa preta.
Na pgina http://www.linux.org/projects/software.html esto listados vrios projetos
de software ligados ao Linux, os quais incluem novos componentes, aplicaes e

"device-drivers". No momento que este livro est sendo escrito (incio de 2000),
existem trs projetos envolvendo adaptaes do Linux para tempo real citados nesta
pgina, os quais sero descritos a seguir. Vrios outros projetos e experincias tambm
foram apresentados no "Real Time Linux Workshop" em Vienna-Austria, em 1999,
cujos anais podem ser obtidos em http://www.thinkingnerds.com/projects/rtl-ws/rtl-
ws.html. Um dos projetos apresentados foi o LINUX-SMART, desenvolvido no Brasil
(IME-USP). Em [Vie99] pode ser encontrada uma descrio do LINUX-SMART,
juntamente com uma excelente reviso da problemtica relacionada com Linux para
tempo real.
Real-Time Linux
O RT-Linux (http://luz.cs.nmt.edu/~rtlinux/) uma extenso do Linux que se prope
a suportar tarefas com restries temporais crticas. O seu desenvolvimento iniciou no
"Department of Computer Science" do "New Mexico Institute of Technology".
Atualmente o sistema mantido principalmente pela empresa FSMLabs e j est em
desenvolvimento a sua segunda verso.
O RT-Linux um sistema operacional no qual um "microkernel" de tempo real co-
existe com o "kernel" do Linux. O objetivo deste arranjo permitir que aplicaes
utilizem os servios sofisticados e o bom comportamento no caso mdio do Linux
tradicional, ao mesmo tempo que permite tarefas de tempo real operarem sobre um
ambiente mais previsvel e com baixa latncia. O "microkernel" de tempo real executa o
"kernel" convencional como sua tarefa de mais baixa prioridade (Tarefa Linux), usando
o conceito de mquina virtual para tornar o "kernel" convencional e todas as suas
aplicaes completamente interrompveis ("pre-emptable").
Todas as interrupes so inicialmente tratadas pelo "microkernel" de tempo real, e
so passadas para a Tarefa Linux somente quando no existem tarefas de tempo real
para executar. Para minimizar mudanas no "kernel" convencional, o hardware que
controla interrupes emulado. Assim, quando o "kernel" convencional "desabilita
interrupes", o software que emula o controlador de interrupes passa a enfileirar as
interrupes que acontecerem e no forem completamente tratadas pelo "microkernel"
de tempo real.
Tarefas de tempo real no podem usar as chamadas de sistema convencionais nem
acessar as estruturas de dados do "kernel" Linux. Tarefas de tempo real e tarefas
convencionais podem comunicar-se atravs de filas sem bloqueio e memria
compartilhada. As filas, chamadas de RT-FIFO, so na verdade "buffers" utilizados
para a troca de mensagens, projetadas de tal forma que tarefas de tempo real nunca so
bloqueadas.
Uma aplicao tempo real tpica consiste de tarefas de tempo real incorporadas ao
sistema na forma de mdulos de "kernel" carregveis e tambm tarefas Linux
convencionais, as quais so responsveis por funes tais como o registro de dados em
arquivos, atualizao da tela, comunicao via rede e outras funes sem restries
temporais. Um exemplo tpico so aplicaes de aquisio de dados. Observe que tanto

as tarefas de tempo real como o prprio "microkernel" so carregadas como mdulos
adicionais ao "kernel" convencional. Esta soluo no suporta requisitos temporais
durante a inicializao do sistema, o que na verdade acontece tambm com todos os
sistemas operacionais de tempo real.
Os servios oferecidos pelo "microkernel" de tempo real so mnimos: tarefas com
escalonamento baseado em prioridades fixas e alocao esttica de memria. A
comunicao entre tarefas de tempo real utiliza memria compartilhada e a
sincronizao pode ser feita via desabilitao das interrupes de hardware. Existem
mdulos de "kernel" opcionais que implementam outros servios, tais como um
escalonador EDF e implementao de semforos. O mecanismo de mdulos de "kernel"
do Linux permite que novos servios sejam disponibilizados para as tarefas de tempo
real. Entretanto, quanto mais complexos estes servios mais difcil ser prever o
comportamento das tarefas de tempo real.
A descrio feita aqui refere-se a primeira verso do RT-Linux, a qual provia apenas
o essencial para tarefas de tempo real. A segunda verso manteve o projeto bsico mas
aumentou o conjunto de servios disponveis para tarefas de tempo real, ao mesmo
tempo que procurou fornecer uma interface Posix tambm a nvel do "microkernel". A
incluso do Posix deve-se principalmente demanda de empresas que gostariam de
portar aplicaes existentes para este sistema, e a disponibilidade de uma interface
Posix no "microkernel" tornar este trabalho bem mais fcil.
RED-Linux
O objetivo do projeto RED-Linux (http://linux.ece.uci.edu/RED-Linux/) fornecer
suporte de escalonamento tempo real para o Linux, atravs da integrao de
escalonadores baseados em prioridade, baseados no tempo e baseados em
compartilhamento de recursos. O objetivo suportar algoritmos de escalonamento
dependentes da aplicao, os quais podem ser colecionados em uma biblioteca de
escalonadores e reusados em outras aplicaes. O RED-Linux inclui tambm uma
alterao no "kernel" para diminuir a latncia das interrupes. Alm disto, ele
incorpora solues do RT-Linux para temporizadores de alta resoluo e o mecanismo
para emulao de interrupes.
O escalonador implementado no RED-Linux dividido em dois componentes: o
Alocador e o Disparador. O Disparador implementa o mecanismo de escalonamento
bsico, enquanto o Alocador implementa a poltica que gerencia o tempo do
processador e os recursos do sistema com o propsito de atender aos requisitos
temporais das tarefas da aplicao. A poltica de escalonamento (Alocador) pode ser
modificada sem alterar os mecanismos de escalonamento de baixo nvel (Disparador).
O Disparador implementado como um mdulo do "kernel". Ele responsvel por
escalonar tarefas de tempo real que foram registradas com o Alocador. Tarefas
convencionais so escalonadas pelo escalonador original do Linux quando nenhuma
tarefa de tempo real estiver pronta para executar ou durante o tempo reservado para
tarefas convencionais pela poltica em uso. O Disparador utiliza um mecanismo de

escalonamento bastante flexvel, o qual pode ser usado para emular o comportamento
dos algoritmos de escalonamento tempo real mais conhecidos, bastando para isto
configurar de maneira apropriada os parmetros que governam o escalonamento de cada
tarefa. O artigo [WaL99] descreve este mecanismo.
O Alocador utilizado para definir os parmetros de escalonamento de cada nova
tarefa tempo real. Na maioria das aplicaes ele pode executar fora do "kernel", como
tarefa da aplicao ou um servidor auxiliar. Executando fora do "kernel" ele pode ser
mais facilmente substituido pelo desenvolvedor da aplicao, se isto for necessrio. O
RED-Linux inclui uma API para que o Alocador possa interagir com o Disparador.
Tarefas de tempo real inicialmente registram-se com o Alocador que, por sua vez,
informa os seus parmetros para o Disparador. O Alocador executa como a tarefa tempo
real de mais alta prioridade e faz o mapeamento da poltica de escalonamento como
selecionada pela aplicao para o mecanismo disponvel no "kernel" do RED-Linux.
O RED-Linux est sendo desenvolvido basicamente na Universidade da California
em Irvine, e encontra-se ainda em um estgio inicial. Detalhes sobre o RED-Linux em
geral ou sobre o mecanismo de escalonamento proposto em particular podem ser
encontrados em [WaL99].
KU Real Time Linux
O KURT-Linux (http://hegel.ittc.ukans.edu/projects/kurt/), ou "Kansas University
Real Time Linux Project" um sistema operacional de tempo real que permite o
escalonamento explcito e relativamente preciso no tempo de qualquer evento, inclusive
a execuo de tarefas com restries de tempo real.
KURT-Linux uma modificao do "kernel" convencional, onde destaca-se o
aumento na preciso da marcao da passagem do tempo real e, como consequncia, na
maior preciso de qualquer ao associada com a passagem do tempo. Uma descrio
do mecanismo usado pode ser encontrada em [SPH98]. Uma importante constatao foi
que o escalonamento explcito de cada evento do sistema usando uma resoluo de
microsegundos gerou uma carga adicional muito pequena ao sistema. Vrias tcnicas
foram usadas em conjunto para obter maior preciso de relgio.
Mdulos de tempo real pertencentes a aplicao so incorporados ao "kernel". O
escalonamento feito atravs de uma lista que informa qual rotina presente em um
mdulo de tempo real deve executar quando. Toda rotina de tempo real executa a partir
da hora marcada e suspende a si prpria usando uma chamada de sistema apropriada.
Desta forma, a preciso do relgio transferida para o comportamento das tarefas. O
sistema operacional supe que os mdulos de tempo real so bem comportados e no
vo exceder o tempo de processador previamente alocado. Esta semntica para tempo
real est descrita em [HSP98]. Embora este tipo de escalonamento seja menos flexvel
do que o baseado em prioridades, ele ainda suficiente para um grande conjunto de
aplicaes. Os autores do KURT-Linux atestam que nunca foi o objetivo do projeto
suportar todos os algoritmos de escalonamento tempo real presentes na literatura.
Uma extenso ao modelo original permite que uma tarefa programada como um lao
infinito (como um servidor, por exemplo) execute em determinados momentos
previamente reservados. Por exemplo, execute 100 microsegundos dentro de cada
milisegundo. Solues de escalonamento baseadas na utilizao do processador podem
ser implementadas atravs deste mecanismo.
Segundo os autores do KURT-Linux, possvel integrar as solues do KURT-
Linux com as do RT-Linux e que foram feitas experincias com sucesso neste sentido.
Desta forma, seria possvel combinar a melhor marcao de tempo e disparo de tarefas
do KURT-Linux com a baixa interferncia experimentada pelas tarefas de tempo real no
RT-Linux.
3.6 Concluso
Este captulo procurou discutir aspectos de sistemas operacionais cujo propsito

suportar aplicaes de tempo real. Alm dos aspectos temporais, obviamente
importantes neste contexto, foram discutidos aspectos funcionais importantes, como
tarefas e "threads", a comunicao entre elas, instalao de tratadores de dispositivos e
interrupes e a disponibilidade de temporizadores.
O texto procurou mostrar as limitaes dos sistemas operacionais de propsito geral,
no que diz respeito a atender requisitos temporais. As mtricas usualmente empregadas
para avaliar um SOTR e as dificuldades associadas com a medio foram apresentadas.
A seo 3.4 apresentou uma classificao dos suportes de tempo real, com respeito
ao determinismo temporal e a complexidade dos servios oferecidos. Finalmente, foram
descritos alguns sistemas existentes, com especial ateno ao padro Posix e as
propostas de uma verso do Linux para tempo real.
A rea de sistemas operacionais de tempo real muito dinmica. Novos sistemas ou
novas verses dos sistemas existentes so apresentadas a todo momento. O anexo 2
contm uma lista no exaustiva de solues disponveis na Internet, com as mais
variadas caractersticas e preos.
A mensagem central que este captulo procura transmitir que o comportamento
temporal da aplicao tempo real depende tanto da aplicao em si quanto do sistema
operacional. Desta forma, a seleo do SOTR a ser usado depende fundamentalmente
dos requisitos temporais da aplicao em questo. No existe um SOTR melhor ou pior
para todas as aplicaes. A diversidade de aplicaes tempo real existente gera uma
equivalente diversidade de sistemas operacionais de tempo real.
Captulo 4
O Modelo de Programao Sncrona

para os Sistemas de Tempo Real
4.1 Introduo
Os Sistemas de Tempo Real so sistemas que reagem, gerando respostas,

estmulos de entrada vindos de seus ambientes. Estas caractersticas os colocam como
Sistemas Reativos especiais que esto submetidos a restries temporais em suas
reaes. Neste tipo de sistemas, devem se garantir no somente a correo lgica
(correctness) mas tambm a correo temporal (timeliness).
O modelo de programao sncrona parte do principio que o ambiente no interfere
com o sistema (ou o programa) durante os processamentos das reaes. Na recepo do
evento de entrada, aps um eventual clculo, a resposta considerada emitida
simultaneamente entrada, o que caracteriza uma reao como instantnea. O modelo
dito sncrono porque as sadas do sistema podem ser vistas como sincronizadas com as
suas entradas. A principal conseqncia desta hiptese a Hiptese Sncrona uma
simplificao conceptual que facilita a modelagem e a anlise formal das propriedades
do sistema.
A hiptese sncrona, que forma a base conceitual deste estilo de programao, no
sentido da reao instantnea, parte do pressuposto que existe uma mquina
suficientemente rpida para executar o processamento correspondente reao em
tempos no significativos. O entendimento desta hiptese, em um sentido mais prtico,
que a durao do processamento referente a reao, se comparado aos tempos
relacionados com o ambiente externo, desprezvel. O ambiente externo no evolui
durante esse processamento. A hiptese sncrona tambm define que os eventos
ocorridos no sistema sejam percebidos instantaneamente em diferentes partes do
sistema.
O modelo de programao sncrono natural do ponto de vista do programador por
facilitar a construo e a compreenso de programas e por lhe permitir a verificao
destes. Ao separar a lgica do comportamento de um sistema das caractersticas de sua
implementao, esse estilo de programao facilita a programao do mesmo.
Uma das caractersticas mais importantes encontrada nos modelos sncronos a
rejeio do no determinismo. Um sistema visto como determinista se a mesma
106 4. O Modelo de Programao Sncrona para os Sistemas de Tempo Real
seqncia de entradas produz sempre a mesma seqncia de sadas e no determinista

em caso contrrio. desejvel e quase sempre mandatrio que os sistemas reativos se
comportem de forma determinista, com as suas sadas dependendo unicamente das
entradas vindas do ambiente e de exigncias temporais; o comportamento esperado no
controle de um avio ou de outro veculo, por exemplo ilustram esta necessidade. Alm
do mais o estudo do comportamento de sistemas no deterministas mais complexo
que o de sistemas deterministas por apresentar situaes de erro que podem no ser
reproduzveis e por tratar com grande nmero de estados. Consequentemente
aconselhvel tratar sistemas intrinsecamente deterministas como os sistemas reativos
por modelos e linguagens deterministas e reservar abordagens no deterministas as
aplicaes que o necessitam como o caso de aplicaes nas quais no h como
garantir comportamentos repetitivos nem garantir tempos de resposta; Internet um
exemplo claro deste comportamento.
As linguagens sncronas que apresentam caractersticas de concorrncia e de
determinismo e permitem ter o controle dos tempos de respostas so bem adaptadas
para a programao dos Sistemas Reativos e dos Sistemas de Tempo Real. Ferramentas
automticas que possibilitam a verificao da correo lgica e temporal desses
sistemas so associadas estas linguagens. A hiptese de sincronismo permite ainda
que programas escritos numa linguagem sncrona sejam compilados em autmatos
eficientes e depois facilmente implementados em linguagens de programao clssicas.
Os Sistemas Reativos e os Sistemas de Tempo Real incluem em doses diferentes
segundo as aplicaes, atividades de manuseio de dados e atividades de controle.
Quando as atividades de manuseio de dados so importantes e complexas enquanto as
de controle so reduzidas como em aplicaes de processamento de sinal, as tcnicas de
especificao e de programao mais apropriadas seguem um estilo orientado a fluxo
de dados como nas linguagens sncronas declarativas Lustre [HCR91] e Signal
[LLG91]. Nestas linguagens, a reao gera sadas a partir da avaliao de um conjunto
de equaes que as definem em funo das entradas atuais e das entradas previas
(armazenadas).
Quando predominam as atividades de controle e que o manuseio de dados simples,
como o caso em aplicaes de controle de processos, sistemas embutidos, superviso
de sistemas, protocolos de comunicao, interfaces homem-mquina, drivers de
perifricos, entre outras, mais apropriada adotar um estilo orientado ao fluxo de
controle como nas linguagens sncronas imperativas como Esterel [BoS91] ou nos
autmatos hierrquicos como Statecharts [Har87]. Nestas linguagens, cada reao
corresponde a passagem de uma situao em termos de controle uma nova situao.
Grandes aplicaes podem ter partes mais orientadas ao manuseio de dados e outras
ao controle; no momento atual, no existe ainda unificao entre os dois estilos ao nvel
de linguagem de programao, apesar de existir atividades de pesquisa nesta rea. Neste
livro, adotaremos a linguagem Esterel como ferramenta para a programao de
aplicaes tempo real dentro do modelo de programao sncrona, por ela ser
imperativa, ter uma sintaxe e semntica de fcil aprendizagem e por ter disponvel um
ambiente automtico de especificao, validao e implementao.
4.2 Princpios Bsicos do Modelo de Programao da Linguagem Esterel 107
4.2 Princpios Bsicos do Modelo de Programao da

Linguagem Esterel
A linguagem Esterel uma linguagem sncrona desenvolvida a partir de 1982

conjuntamente por dois laboratrios franceses do INRIA e da ENSMP. A necessidade
de atender simultaneamente concorrncia e determinismo a base do modelo de
programao sncrono da linguagem Esterel. Os princpios bsicos deste modelo so os
seguintes:
Reatividade: O modelo reativo uma vez que se aplica a sistemas que entram
em ao reagindo presena de estmulos vindos do ambiente em instantes
discretos. Cada reao, portanto, est associada a um instante preciso; o
conjunto destes instantes caracteriza a vida do sistema reativo.
Sincronismo: As reaes sendo instantneas, entradas e sadas se apresentam

sincronizadas a base da hiptese sncrona. As reaes so atmicas, o
modelo sncrono no permite uma nova ativao do sistema enquanto o
mesmo estiver reagindo ao estmulo atual. Portanto, no h concorrncia
entre as reaes, eliminando assim uma fonte de no determinismo que
corresponderia ao entrelaamento (interleaving) de execues concorrentes.
Difuso instantnea: A comunicao entre componentes sempre realizada

por um mecanismo de difuso instantnea (broadcasting). Um sinal
emitido visto no mesmo instante da sua emisso por todos seus receptores.
A difuso limitada aos instantes de reao: um sinal emitido num instante
visto como presente em todos os receptores neste mesmo instante; pode haver
entretanto varias emisses e recepes de sinal em seqncia num mesmo
instante.
Determinismo: Contrariamente as abordagens assncronas, onde a

concorrncia leva ao no determinismo, o modelo faz conviver concorrncia e
determinismo. O modelo sncrono determinista, o que tem como resultado a
simplificao das programaes reativas e a capacidade de reproduzir seus
comportamentos, simplificando testes e verificaes destas.
Na abordagem sncrona, o tempo considerado como uma entidade multiforme

sendo visto como um evento externo entre outros, de caractersticas diversas do tempo
fsico; a noo de tempo fsico na verdade substituda pela noo de ordem e de
simultaneidade entre eventos. Essa viso de tempo multiforme e a no ocorrncia de
interleaving facilitam em muito o entendimento e a anlise dos sistemas de tempo
real.
Tcnicas de compilao geram a partir destes modelos sncronos geralmente
descritos na forma de linguagens autmatos de estado finito deterministas, nos quais
o paralelismo e a comunicao expressos no formalismo inicial desaparecem; em

decorrncia disto, estes autmatos apresentam um grau elevado de eficincia e
previsibilidade temporal. A estas caractersticas, so adicionados a simplicidade do
autmato resultante em termos do nmero de estados e o uso de tcnicas de verificao
ou de prova que so facilitadas. Estes autmatos so tambm facilmente implementados
em qualquer linguagem clssica (C, Java, etc.) ou mesmo, em lgica de circuitos
seqncias booleanos.
4.3 O Estilo de Programao da Linguagem Esterel
4.3.1 Programando num estilo imperativo
Vamos a seguir a partir de um pequeno exemplo mostrar a facilidade de

programao sncrona, usando o estilo imperativo da linguagem Esterel e introduzir
algumas das construes de base que o caracterizam.
Considera a especificao informal:
Emite uma sada O, to logo que as duas entradas A e B tenham ocorrido.
Reinicialize este comportamento a cada vez que ocorrer uma entrada R.
O comportamento descrito acima pode ser representado por vrios formalismos
entre estes, por um autmato. Na figura 4.1, apresentado o autmato [Ber99] que
representa a especificao anterior com 4 estados, 8 transies; as entradas e sadas
? B.~ R.! O
?A.~R.! O
?R ?R
?B.~R.! O
? A.~R.! O
Figura 4.1: A utm ato para a especificao A BRO

4.3 O Estilo de Programao da Linguagem Esterel 109
aparecem vrias vezes (3 vezes para A, B e O e 8 vezes para R) neste autmato,

tornando a representao complexa o que permite concluir na inadequao de realizar
uma especificao direta na forma de um autmato. Alm do mais, se o nmero de
entradas cresce, aumenta consequentemente a complexidade na representao por causa
da exploso exponencial do autmato.
A linguagem imperativa sncrona Esterel permite ao usurio escrever de forma
simples e natural, sem repetio a especificao anterior no mdulo ABRO:
module ABRO:
input A, B, R;
output O;
loop
[await A || await B];
emit O
each R
end module
Note que na especificao acima, diferente do autmato, ocorrem uma s vez as

entradas e sada A, B, R e O. O aumento do nmero de entradas tambm facilmente
absorvido por este estilo de programao e o mdulo ABCRO conteria apenas esta
modificao:
loop
[await A || await B || await C];
emit O
each R
O princpio de base de um bom estilo de programao consiste em escrever cada

parte da especificao apenas uma vez, evitando repeties que dificultam o
entendimento e a manuteno do programa e podem ser eventuais fontes de erro. As
construes da linguagem Esterel so particularmente bem adaptadas para ajudar o
usurio a gerar programas para sistemas reativos que seguem este estilo de
programao.
O cdigo anterior contm algumas construes bsicas da linguagem Esterel:
O atraso: a construo temporal await significa a espera por um evento.

Quando iniciada, corresponde a uma pausa at o evento ocorrer, instante no
qual conclui a operao: await A espera o sinal A e termina quando este
ocorre.
A emisso de sinal: A emisso instantnea de sinal realizada pela construo

"emit ...", No exemplo acima emit O corresponde a emisso instantnea do
sinal O, to logo a ltima entrada A ou B seja recebida. No pode ocorrer mais

de um emit por instante (a regra correspondente ser vista mais tarde).
Seqncia: p;q transfere imediatamente o controle a q, quando p termina.
Concorrncia: O operador de paralelismo || define as construes separadas

pelo operador em paralelismo sncrono. A menos da interveno de algum
mecanismo de preempo ou de exceo, a construo termina quando todos
seus ramos terminaram. Neste exemplo, await A || await B termina
instantaneamente desde que as duas componentes concluam com as duas
entradas A e B sendo recebidas.
aborto ou preempo: Na construo loop p each R, o corpo p

imediatamente inicializado e executa repetidamente at o instante de
ocorrncia de R no qual p abortado e imediatamente reinicializado; esta
construo dita de aborto ou preempo forte pois o evento R prioritrio
sobre o corpo em execuo. No exemplo do mdulo ABRO se A, B e R
ocorrem simultaneamente, O no ser emitido.
O estado de um sinal envolvido numa reao presente ou ausente. O ambiente
fornece o estado dos sinais de entrada, e a execuo da instruo emit transforma o
estado dos outros sinais de ausente para presente.
A comunicao em Esterel realizada por difuso instantnea. Na entrada, a difuso
instantnea implcita para as instrues concorrentes. A difuso instantnea vale para
todos os sinais e permite que processos interessados num sinal emitido (emit O)
esperem simplesmente o mesmo atravs de uma instruo await por exemplo, sem ter
que revelar suas existncias ao mdulo emissor e independentemente do nmero de
processos receptores.
Aps esta breve introduo ao estilo de programao da linguagem Esterel, vamos
apresentar as principais construes que caracterizam este estilo, descrevendo
declaraes e comportamentos no contexto de pequenos exemplos ilustrativos. Uma
apresentao mais detalhada da sintaxe e semntica da linguagem Esterel pode ser
encontrada no Anexo C.
4.3.2 Declarao de interface
Seja a especificao de um medidor de velocidade descrito informalmente por

Contar o nmero de centmetros por segundo e difundi-lo a cada segundo como sendo
o valor de um sinal Velocidade.
Os sinais de entrada do mdulo medidor de velocidade so gerados a cada
centmetro e a cada segundo e so representados por Centmetro e Segundo que
definem cada um, uma unidade de tempo independente, caracterizando desta forma que
o tempo multiforme no modelo sncrono. Para simplificar o exemplo, supe-se que

esses dois sinais no podem ser simultneos (hiptese plausvel devido ao ambiente de
execuo); a relao de exclusividade de um sinal se representa por # numa declarao
relation. A difuso do valor da velocidade ser feita por um sinal com valor,
Velocidade, que a cada instante alm do seu estado contm um valor com tipo integer.
O cdigo do mdulo medidor de velocidade em Esterel se escreve como:
module Medidor-Velocidade:
input Centmetro, Segundo;
relation Centmetro # Segundo;
output Velocidade : integer;
loop
var Distancia := 0 : integer in
abort
every Centmetro do
Distancia := Distancia + 1
end every
when Segundo do
emit Velocidade (Distancia)
end abort
end var
end loop
end module
O estilo de programao adotado em Esterel prioriza o controle de atividades pelo

uso da preempo. Dentro da malha infinita loop ... end, a construo abort ...
when ... do ... end abort interrompe seu corpo quando o sinal Segundo ocorre e
executa a clasula de timeout que segue o do que permite emitir o sinal Velocidade
que contm o ultimo valor Distancia. Dentro do corpo do abort uma malha every ...
end every permite incrementar a varivel Distancia a cada sinal de entrada
Centmetro; esta malha every difere da malha loop anteriormente apresentada por
depender da ocorrncia de um sinal (neste exemplo Centmetro) para iniciar o seu
corpo. Considerando a transmisso do controle no programa e as operaes
suficientemente rpidas para serem vistas como instantneas dentro da hiptese de
sincronismo, a velocidade emitida exatamente quando ocorre o tick indicando o
segundo.
Um sinal com valor (como Velocidade neste exemplo) tem um nico estado e um
nico valor a cada reao; contrariamente ao estado, o valor deste permanece igual ao
da reao anterior at sofrer mudana. O ambiente determina o valor para os sinais de
entrada e as instrues emit para os sinais de sada. A expresso ?S permite acessar
o valor corrente de um sinal S. O estado e o valor de um sinal podem ser difundidos
instantaneamente.
A construo relation ... permite representar condies supostamente garantidas
pelo ambiente entre os sinais do tipo input (e tambm do tipo return). Os dois
tipos de relao so de incompatibilidade ou excluso entre os sinais (#) como o
caso neste exemplo e de sincronizao entre sinais (=>). As relaes so teis para
evitar a programao de situaes de menor importncia e reduzir em conseqncia o
tamanho do autmato gerado, facilitando a sua verificao.
Em algumas situaes onde apenas necessrio a leitura de um valor a qualquer
momento, sem a necessidade de gerar tambm um evento de entrada, pode se utilizar o
sinal de entrada sensor que tem apenas o valor mas sem a presena da informao de
estado. Assim como o sinal com valor, definido anteriormente, o sensor tem o seu valor
lido pelo operador ?.
4.3.3 Declarao de variveis
Uma varivel um objeto ao qual podem ser atribudos valores. Uma varivel
local uma thread que corresponde ao corpo p de um mdulo (no exemplo anterior a
varivel Distancia incrementada a cada sinal de entrada Centmetro dentro da malha
every ... end every do corpo do abort). O valor da varivel pode ser fornecido por
uma instruo de atribuio instantnea ou passado numa chamada de um procedimento
externo instantneo ou ainda passado pela instruo exec que permite a execuo de
tarefas externas de clculo que tomam tempo (esta instruo ser vista futuramente).
Contrariamente ao sinal, uma varivel pode tomar vrios valores sucessivos no mesmo
instante.
4.3.4 Os diferentes tipos de preempo
Foi percebida nos exemplos anteriores a importncia para o estilo de programao

Esterel, da construo de preempo que permite matar o seu corpo quando um evento
ocorre ou um prazo se esgota. Foi apresentado at o momento um tipo de preempo
chamado forte que expressado pelas construes abort p when S e loop p each
S. Entretanto interessante poder fornecer ao usurio outras opes com semnticas
diferentes.
O comportamento da construo de preempo forte abort p when S o
seguinte:
no comeo da execuo, p imediatamente inicializado, independentemente

da presena ou ausncia de sinal S;
se p termina antes da ocorrncia de S, ento a instruo abort termina neste
mesmo instante;
se S ocorre antes do trmino de p, ento a instruo abort termina
imediatamente e p no recebe mais o controle.
Comportamentos diferentes podem ser necessrios para disponibilizar ao usurio. A

possibilidade de terminao da instruo abort desde o primeiro instante mesmo sem
p ter iniciado, permitida pela construo abort p when immediate S que introduz
a palavra chave immediate.
Para permitir que o corpo p receba ainda o controle no instante da preempo, para
uma ltima atividade, utiliza-se uma construo de preempo fraca: weak abort p
when S. O comportamento de preempo fraca tambm possvel atravs da
construo weak abort p when immediate S. Para o exemplo do mdulo ABRO
citado anteriormente, a utilizao da construo weak abort no lugar de loop ...
each torna possvel programar, se desejado, a emisso do sinal de sada O mesmo no
caso de uma situao de simultaneidade entre os sinais A, B, R. Da mesma forma, o uso
de weak abort no mdulo Medidor-Velocidade permite no caso de ser autorizada a
ocorrncia simultnea dos sinais Centmetro e Segundo (a relao de exclusividade #
seria retirada do exemplo anterior), de levar em conta o ltimo incremento da varivel
Distancia antes que a velocidade seja emitida; a utilizao da preempo forte abort
neste caso levaria a ignorar o ltimo centmetro na instruo every Centmetro por
ter sido abortada pela ocorrncia de Segundo.
A construo em Esterel every S do p end encontrada no mdulo Medidor-
Velocidade uma abreviao de:
await S;
loop
abort [p; halt] when S
end loop
e permite realizar tambm uma preempo forte de seu corpo e a seguir ser atrasado
(halt uma primitiva que significa espera para sempre). Esta construo tem ainda
uma forma imediata every immediate S do p end que permite levar em conta o sinal
desde o primeiro instante. A soluo do problema da simultaneidade de Centmetro e
Segundo no mdulo Medidor-Velocidade pode ser tambm resolvido usando um
abort forte e um every immediate; neste caso o centmetro no ser contado
durante o segundo que esta acabando ms ser levado em conta no inicio do prximo
segundo.
Apesar de ter discutido essas construes apenas em termos de sinal, expresses de
sinais que so na verdade expresses booleanas formadas com operadores "not",
"and", e "or" aplicadas sobre o estado de vrios sinais podem ser utilizadas nas
construes temporais abort, every.
A linguagem Esterel fornece ainda um outro tipo de preempo mais brando que
tem um efeito de suspenso (do tipo ^Z do Unix em contraposio com o tipo ^C mais
duro da construo abort): suspend p when <S ou expresso-sinal>. Quando a
construo suspend inicia, o corpo p imediatamente iniciado. A cada instante, se o
sinal S esta presente ou a expresso de sinal for true, o corpo p se suspende e
congelado no estado no qual se encontrava no momento da suspenso; em caso

contrario, o corpo p executado neste instante. Como nas outras construes de
preempo, necessrio usar a palavra chave immediate na construo suspend p
when immediate <S ou expresso-sinal> para poder testar a eventual presena do
sinal S ou a expresso de sinal no instante inicial.
4.3.5 Mecanismo de exceo
O mecanismo de exceo da linguagem Esterel implementado pela construo

trap T in p end trap que permite programar um ponto de sada para o corpo p. O
corpo p imediatamente executado quando a construo trap inicia. A sua execuo
continuar at o trmino de p ou at a execuo de uma construo exit T introduzida
no corpo p. O trmino do corpo p leva ao trmino da construo trap. A sada por
um exit leva o trap a terminar imediatamente, abortando p por preempo fraca,
do tipo weak abort.
No caso da existncia de um tratador de exceo, o controle imediatamente
transferido para o mesmo, aps a execuo do exit. A ativao do tratamento da
exceo realizado pela construo handle, permitindo o inicio imediato de q aps o
corpo p ter sido abortado pelo exit do trap:
trap T in
p
handle T do
q
end trap
4.3.6 Testes de presena
Alm de manusear sinais a partir de construes de preempo, possvel realizar

testes de presena de sinais com a construo present S else p end present. Este
teste permite decidir entre vrias ramificaes de programa, em funo do valor
instantneo do sinal S. Se o sinal S est presente, a construo present termina a
seguir, caso contrrio a ramificao else imediatamente iniciada; a clasula then
omitida mas poderia ser usada no lugar de else se o teste fosse sobre a ausncia de
sinal (not S).
Para aumentar o poder de expresso, expresses de sinais ei e construes
condicionais mltiplas (case) podem ser utilizadas em testes de presena:
present
case e 1 do p 1
case e 2 do p 2
case e 3 do p 3
else q
end present
4.3.7 Mdulo
O mdulo a unidade bsica para construir programas Esterel. Ele tem um nome,
uma declarao de interface e um corpo que executvel.
module <nome> :
<declarao de interface>
<corpo>
end module
O estilo de programao Esterel permite construir um mdulo com nomes padro

para os sinais de entrada e sada. O mdulo pode utilizar submdulos que so mdulos
instanciados pela construo executvel run e cujas entradas e sadas podem ser
renomeadas explicitamente usando o smbolo /. O comportamento do submdulo o
mesmo do mdulo, substituindo os nomes padro ( direita de /) pelos nomes reais
dos sinais (situados esquerda de /). Em nenhum caso permitido recursividade
sobre a instanciao.
Uma forma alternativa de programar o mdulo ABCRO a partir do uso do mdulo
ABRO como mdulo genrico apresentada a seguir como exemplo:
m odule A B C R O :
inpu t A , B , C , R ;
outp ut O ;
signal A B in
run A B R O [sign al A B / O ]
||
run A B R O [sign al A B / A , C / B ]
end sign al
end m odu le
O submdulo ABRO [signal AB/O] se comporta como "loop [await A || await B];
emit AB each R"; o submdulo ABRO [signal AB/A, C/B] como "loop [await AB ||
await C]; emit O each R"; a difuso instantnea do sinal AB nos dois submdulos
paralelos torna o comportamento do mdulo ABCRO equivalente ao comportamento j
descrito anteriormente "loop [awaitA || await B || await C]; emit O each R". Constata-
se ainda que o modelo de programao sncrona fornece como resultado adicional
interessante, a reinicializao simultnea dos dois submdulos pelo sinal R.
A declarao de interface do mdulo define os objetos que este importa ou exporta:
objetos de dados (tipos, constantes, funes, procedimentos, tarefas) declarados de
forma abstrata em Esterel e implementados externamente e objetos de interface reativa:
os sinais e sensores. Todos os dados so globais ao programa. Cada dado usado num
mdulo, deve ser declarado nele.
4.3.8 O conceito de tempo no modelo de programao
No modelo de programao sncrono que suporta a linguagem Esterel, a noo de

tempo fsico no existe; o tempo fsico visto como um sinal entre outros. Qualquer
sinal pode ser considerado para definir uma unidade de tempo independente. O tempo
dito multiforme, i.e. qualquer sinal repetido pode ser considerado como definindo sua
prpria medida de tempo. O estilo de programao Esterel requer o reconhecimento de
todas as unidades de tempo da aplicao e o entendimento de como estas se relacionam
entre si. Para representar esta noo, poderia se imaginar uma representao grfica na
forma de vrios eixos de tempo com unidades diferentes correspondentes aos diversos
sinais repetidos. No mdulo Medidor-Velocidade, as unidades de tempo so
Centmetro e Segundo com eixos de tempo prprios; neste caso simples, a relao
entre os mesmos permite que se calcule a velocidade.
4.4 Um exemplo ilustrativo do estilo de programao
O estilo de programao ilustrado a seguir por um pequeno exemplo que descreve

o treinamento de um corredor e cuja especificao :
Cada manh, o corredor faz um nmero fixo de voltas num estdio. A cada volta,
ele corre devagar durante 100 metros, depois ele pula a cada passo durante 15
segundos e termina a volta correndo rpido.
Num primeiro tempo, a partir da especificao informal anterior, determina-se os
sinais que correspondero as unidades de tempo. Os sinais de entrada so Manha,
Volta, Metro, Passo e Segundo. Os sinais de sada so Correr-Devagar, Pular e
Correr-Rpido. Relaes entre sinais so estabelecidas: Manha e Segundo so
sincronizados bem como Volta e Metro. Os sinais Correr-Devagar e Correr-Rpido
4.4 Um exemplo ilustrativo do estilo de programao 117
sero emitidos de forma contnua; o sinal de sada Pular ser emitido em reao ao
sinal de entrada Passo. Desta forma fica definida a interface do mdulo Corredor cujo
o cdigo ser apresentado a seguir. As relaes de sincronizao entre sinais so
expressas no programa pelo smbolo =>.
O corpo do programa uma traduo natural da especificao informal seguindo o
estilo de programao apresentado anteriormente cujo o princpio fundamental consiste
em controlar as atividades a partir das construes de preempo. O uso de preempes
aninhadas uma forma simples e natural para expressar prioridades entre estas. Uma
linha de conduta para uma boa programao consiste a partir de uma primeira leitura da
especificao, em construir inicialmente a estrutura de preempes aninhadas, usando a
indentao das construes de preempo para visualizar o aninhamento e depois, a
partir de uma releitura da especificao, em introduzir as outras construes no corpo
do programa. O cdigo em Esterel do mdulo Corredor o seguinte:
module Corredor
constant Nmero-Voltas: integer;
input M anha, Volta, M etro, Passo, Segundo;
relation M anha => Segundo,
Volta => M etro;
output Correr-Devagar, Pular, Correr-Rpido;
every M anha do
abort
abort
abort
sustain Correr-Devagar
when 100 M etro;
abort
every Passo do
emit Pular
end every
when 15 Segundo;
sustain Correr-Rpido
when Volta
when Nmero-Voltas Volta
end every
end module
Para emitir um sinal de forma continua (caso de Correr-Devagar e Correr-

Rpido), utiliza-se a construo sustain S; a construo fica ativa para sempre e
emite S a cada instante.
Destaca-se ainda que poderia ser utilizado tambm a construo loop ... each ...
em algumas situaes como por exemplo em loop ... each Volta no lugar de abort
... when Volta.
Nota-se que se a volta for inferior a 100 metros, o corredor apenas correr devagar e
se esta for mais curta que 100 metros mais 15 segundos, o corredor nunca correra
rapidamente; tambm no necessrio que cada volta seja dimensionada de forma
igual.
Ao acrescentamos especificao anterior do treinamento do corredor o seguinte:

Durante a fase na qual o corredor pula, o corao dele monitorado e em caso de
alguma anomalia ser constatada, o corredor parar e retornar ao vestirio.
O novo cdigo que leva em conta esta especificao adicional toma a seguinte
forma:
every Manha do
trap Anomalia in
abort
abort
abort
sustain Correr-Devagar
when 100 Metro;
abort
every Passo do
emit Pular
end every
||
<Monitorar-Corao>
when 15 Segundo;
sustain Correr-Rapido
when Volta
when Nmero-Voltas Volta
handle Anomalia do
<Voltar-Vestirio>
end trap
end every
A atividade <Monitorar-Corao> no descrita aqui mas dever

obrigatoriamente conter uma construo de levantamento de exceo do tipo exit
Anomalia quando esta for constatada; a atividade de tratamento de exceo <Voltar-
Vestirio> tambm no objeto da nossa descrio.
4.5 A assncronia na linguagem Esterel: a execuo de

tarefas externas
Procedimentos externos chamados pela construo "call" so considerados como

instantneos. Entretanto, possvel controlar ainda a execuo de tarefas externas que
levam tempo usando o mecanismo "exec". Essas tarefas se comportam como
procedimentos a serem executados de forma assncrona com o programa Esterel que
ter apenas uma viso lgica destas, se interessando apenas pelo inicio ou fim das
mesmas ou ainda, pela suspenso ou preempo desta tarefas atravs de construes
4.5 A assncronia na linguagem Esterel: a execuo de tarefas externas 119
Esterel. A forma de assincronismo assim introduzida restrita para permitir a

sincronizao com a tarefa apenas quando do trmino da mesma. Estas tarefas no so
limitadas ao seu sentido computacional mas podem ser tambm atividades de um objeto
real de natureza fsica.
A construo "exec Task (<parmetros-referncia>) (<parmetros-valores>)
return R" que permite a execuo de uma tarefa externa. Nesta construo, R um
sinal de retorno que se restringe a um nico "exec". Como qualquer sinal de entrada no
programa Esterel, cada R deve ser declarado na interface de sinal do mdulo, utilizando
a palavra chave "return" no lugar de "input". No inicio da construo "exec", o
ambiente sinalizado instantaneamente para que a tarefa inicie; o programa Esterel
continue a reagir aos sinais de entrada, exceto na "thread" que disparou o "exec" que
deve esperar o trmino da tarefa correspondente. Na recepo do retorno R, so
atualizados instantaneamente os argumentos de referncia em todo o programa Esterel,
com os valores retornados e a construo "exec" termina instantaneamente. Uma
operao "exec" pode ser suspensa ("suspend") ou abortada ("abort", "weak abort" ou
"trap") durante sua execuo e, em qualquer destas situaes, a tarefa externa receber
a sinalizao correspondente.
No caso da preempo fraca:
weak abort
exec TASK (X) (...) return R;
when I
se R ocorre antes ou simultaneamente com I, X atualizado e a construo "weak

abort" termina; se I ocorre antes de R, a execuo de TASK e consequentemente da
tarefa externa abortada e X no ser atualizado.
No caso da preempo forte:
abort
exec TASK (X) (...) return R;
when I
se R ocorre antes de I, X atualizado e a construo "abort" termina; se I ocorre antes

de R, a execuo de TASK e consequentemente da tarefa externa abortada e X no
ser atualizado; se R e I ocorre simultaneamente, a construo "abort" termina e X no
atualizado porque, apesar da tarefa ter sido concluda, o corpo do "abort" no recebe
o controle.
Se for necessrio saber se a tarefa externa terminou num dado instante, o teste
"present R then ... else ... end present" quando usado na clasula "do" do "when ..."
fornece esta informao.

No caso da suspenso:
su sp en d
e x e c T A S K ( X ) ( .. .) r e t u r n R ;
w h en S
se S ocorrer aps o instante inicial, a construo "exec" suspensa e um sinal de

suspenso especifico para cada implementao de tarefa enviado ao ambiente. A
terminao de "exec" pode ocorrer somente quando a construo ativa; se R e S
ocorrem simultaneamente, R no provocar o fim de "exec" e sua ocorrncia ser
perdida. possvel tambm neste caso, introduzir um teste de presena de um sinal de
retorno.
Quando for necessrio o controle de vrias tarefas simultaneamente, utiliza-se:
exec
case T 1 (...) (...) return R 1 do p 1
...
case T n (...) (...) return R n do p n
end exec
Quando um "exec" mltiplo inicia, todas as tarefas so disparadas simultaneamente;

quando pelo menos um sinal de retorno ocorre, a construo "exec" termina
instantaneamente, abortando as outras tarefas, atualizando apenas o argumento
referncia da tarefa que terminou; em caso de preempo ou de suspenso todas as
tarefas so abortadas simultaneamente.
Numa construo "exec" embutida numa malha:
loop
exec TA SK (X ) (...) return R ;
each I
se I ocorre antes da finalizao da tarefa, o programa Esterel sinaliza ao ambiente o

aborto da instncia corrente da tarefa e nova instncia desta iniciada. Nunca pode
haver duas instncias de uma tarefa disparadas por um mesmo "exec" que possam ser
ativas no mesmo instante a no ser em situaes onde a construo "exec" abortada
e reinicializada, instantaneamente.
4.6 O Ambiente de Ferramentas Esterel 121
4.6 O Ambiente de Ferramentas Esterel
A linguagem de programao Esterel para sistemas reativos vem sendo

desenvolvida desde 1982 por equipes do INRIA e da Ecole des Mines de Sophia-
Antipolis (France) e se encontra atualmente na sua verso 5 . Seu compilador
(atualmente V5.21) esta sendo disponibilizado gratuitamente no site http://www-
sop.inria.fr/meije/esterel/ para arquiteturas Solaris, Linux, AIX, OSF1 e Windows NT.
Esta verso do compilador usa uma tcnica de compilao baseada em Diagramas
de Deciso Binrios (BDD) e permite gerar uma implementao de software de um
programa reativo na forma de uma mquina de estados finita (FSM) ou uma
implementao de hardware na forma de circuitos, obtidos a partir de sistemas de
equaes booleanos. O cdigo gerado (por exemplo em C) pode ser embutido como um
ncleo reativo num programa maior que trata da interface do ncleo e processa os
dados da aplicao. Da mesma forma, nas implementaes de hardware, a lista de
gates gerada pode ser embutida em circuitos maiores. Alm deste compilador, existe
um conjunto de ferramentas disponveis no mesmo site para desenvolver e para
verificar programas em Esterel.
Uma das grandes vantagens do modelo usado em Esterel de favorecer uma
abordagem do tipo o que voc prova o que voc execute (WYPIWYE What You
Prove Is What You Execute) [Ber89]. Este aspecto determinante para que o modelo
sncrono se diferencie de grande parte das outras abordagens que, para o
desenvolvimento de programas, necessitam de um processo de traduo para passar da
especificao validada ao programa implementado. Nesta traduo, so introduzidos
detalhes de implementao que, geralmente, so fonte de erros ou de modificaes no
comportamento j verificado.
No que se refere a validao em linguagens sncronas, as principais propriedades a
serem verificadas para os sistemas de tempo real so: vivacidade (liveness) que
pode ser entendida como algo til dever acontecer em algum momento; e
segurana (safety) que corresponde a algo ruim nunca dever acontecer ou algo
til dever acontecer antes de algum tempo no caso dos sistemas de tempo real.
A verificao consiste em comparar um programa com as especificaes desejadas
de algum aspecto ou da totalidade das mesmas. A verificao das propriedades citadas
se faz sobre a estrutura de controle do programa, os dados no influem diretamente.
Duas abordagens de verificao podem ser diferenciadas, conforme as especificaes se
apresentem no mesmo formalismo que o programa (por exemplo, autmato) ou em
formalismos diferentes (por exemplo, autmato para o programa e lgica temporal para
as especificaes). No caso da primeira abordagem, pode se utilizar duas tcnicas
diferentes: a de verificao por equivalncia e a de verificao por observadores.
A tcnica de verificao por equivalncia usa a noo de bisimulao fraca que foi
definida por Park e usado por Milner [Arn94]. A bisimulao uma relao binaria
entre estados de dois sistemas de transies (no caso similares aos autmatos) que
define a equivalncia entre estes. A verificao da equivalncia consiste em verificar a

existncia desta relao de bisimulao. O primeiro passo consiste em distinguir os
sinais relevantes para o aspecto da especificao que se pretende verificar, dos
irrelevantes que passam a ser considerados como eventos internos. O segundo passo
consiste em reduzir na sua forma mnima o autmato na forma obtida anteriormente, do
ponto de vista da bisimulao fraca. Este autmato reduzido contm poucos estados e
transies, podendo ser facilmente verificado as propriedades por simples leitura ou a
sua equivalncia com um autmato das especificaes.
A tcnica de verificao por observadores consiste em construir um observador O
que um outro programa reativo que expressa a propriedade a ser verificada e a coloc-
lo em paralelismo sncrono com o programa P a verificar e com outro programa reativo
E que representa o ambiente e gera seqncias de entrada para os dois anteriores. Como
o papel do observador O de ver o comportamento do programa P, ele tem ainda como
entrada, as sadas do programa P. Tcnicas de analise de alcanabilidade para
autmatos permitem verificar o programa, detectando eventuais diferenas entre o
comportamento do programa e aquele descrito pelo observador. Qualquer linguagem
sncrona pode ser usada para programar o observador O e o ambiente E.
A verificao pela abordagem da lgica temporal consiste em verificar se formulas
de lgica temporal que representam as propriedades desejadas so satisfeitas ou no
pelo programa. Uma das formas de construir um verificador neste caso consiste em
construir tambm um observador com as propriedades expressas em lgica temporal e
compilado como programa Esterel. Existem na literatura, outras formas de expressar as
formulas de lgica temporal que resultaram em varias ferramentas de verificao
baseadas nesta tcnica.
As ferramentas includas no ambiente de desenvolvimento Esterel permitem os trs
tipos de verificao descritas anteriormente.
O ambiente de desenvolvimento e verificao Esterel, Xeve disponibilizado em
http://www-sop.inria.fr/meije/verification/Xeve/ um ambiente com interface grfica
que permite a anlise e a verificao de programas Esterel baseado na representao
em mquinas de estados finitos. As ferramentas de Xeve so:
Hurricane (disponvel para Solaris e Linux) que um verificador de
modelos (model checking) sobre os programas Esterel, baseados em
frmulas de lgica temporal. As frmulas de lgica temporal so
transformadas em observadores Esterel usando um tradutor tl2strl. Esta
ferramenta gera um novo programa Esterel obtido a partir do programa
principal e das frmulas e onde, as entradas so as do programa principal e
as sadas so as do programa principal e as obtidas das frmulas. A
ferramenta verifica o estado dos sinais de sada e o resultado obtido indica
para cada sada se a mesma pode ser emitida ou no.
fc2symbmin que analisa as mquinas de estado finitos geradas pelo
compilador Esterel e descritas no formato FC2 formato definido pela
equipe de pesquisa deste projeto para facilitar a interface com outros

software de verificao . Esta anlise inclui:
a minimizao de FSMs (mquinas de estados finitos) obtida a
partir da noo de bisimulao dos autmatos reativos obtidos do
programa Esterel,
o diagnstico atravs de observadores que so programas
inicializados em paralelo com o programa principal, testando
seus sinais, interagindo com ele e gerando sinais de falha ou
sucesso; esses observadores podem ainda gerar sinais para
simular o ambiente Esterel,
o produto sncrono de FSMs para implementar o operador
paralelo sncrona de Esterel,
a ocultao de sinais para reduzir o tamanho da FSM e a
complexidade da anlise, e
a verificao de equivalncia que determina se dois autmatos
podem se comportar da mesma forma ou no tendo o mesmo
ambiente.
Atg disponvel em http://www-sop.inria.fr/meije/verification/index.html
um editor grfico de autmato que permite a visualizao da mquina de
estado finitos minimizada.
Xes que um simulador grfico habitualmente distribudo com o
compilador para lhe servir de depurador (debugger) e que permite
executar seqncias de execuo como por exemplo as extradas do
diagnostico de verificao de modelo (model checking).
As figuras 4.2 a 4.4 apresentam algumas das telas do ambiente Xeve.
Figura 4.2 - Tela Principal do Ambiente XEVE

Figura 4.3 - Tela de Ajuda do Ambiente XEVE
Figura 4.4 - Tela de Resultados do Ambiente XEVE

4.7 Implementaes de programas em Esterel
Um programa em Esterel pode ser implementado de duas formas diferentes: por

software usando um autmato ou por hardware usando circuitos booleanos seqenciais.
Neste livro, apresentaremos somente a primeira forma de implementao; o leitor que
tiver interesse na segunda forma de implementao, dever recorrer as seguintes
referencias bsicas [Ber92], [STB96].
Implementao usando um autmato

Uma das caractersticas mais interessante do modelo sncrono e da linguagem
Esterel a capacidade de produzir um autmato (ou mquina de estados finitos),
construdo pelo compilador a partir das regras da sua semntica de execuo que cada
evento de entrada, associa uma transio vindo de um estado.
O autmato resultante da compilao determinista: o paralelismo e as
comunicaes de sinal em cdigo Esterel desaparecem e so seqencializados dentro de
cada transio interna, produzindo um cdigo seqencial. Este tipo de compilao em
autmatos oferece vantagens do ponto de vista da eficincia e em relao
previsibilidade, to necessria em sistemas de tempo real.
A principal vantagem reside na eficincia na execuo. Os sinais locais usados para
comunicao interna entre construes desaparecem no autmato, como os ns no-
terminais intermedirios desaparecem durante a gerao de parser numa compilao;
os sinais locais podem em conseqncia ser considerados como tendo verdadeiro atraso
zero em tempo de execuo. Alm do mais, como no h mais nenhum paralelismo,
no h custo adicional em tempo resultando do gerenciamento em tempo de execuo
de tarefas ou da comunicao e sincronizao de tarefas em tempo de execuo, em
contraposio com o que ocorre com o uso de outras linguagens concorrentes que no
suportam o modelo sncrono e que necessitam de usar um suporte para gerenciamento e
comunicao de tarefas, com o custo adicional e a no-previsibilidade que este
proporciona.
Como vantagem adicional desta compilao em autmato, destaca-se a
previsibilidade do tempo de transio mxima de um autmato, de especial relevncia
quando se trata de Sistemas de Tempo Real.
Entretanto a desvantagem de um autmato esta associada ao seu tamanho.
Aplicaes que resultam em autmatos relativamente pequenos como em protocolos,
interface homem-mquina, controle de processos simples so facilmente manuseveis,
o que no o caso em algumas aplicaes mais complexas na qual a exploso de
estados pode se tornar relevante.
No ambiente de desenvolvimento para a linguagem Esterel, o autmato produzido
num formato de sada intermedirio, chamado OC que comum linguagem Lustre j
citada e que pode ser traduzido numa linguagem alvo de uso geral tal como C, Ada,
Java.
4.8 Discusso sobre o modelo e a linguagem 127
4.8 Discusso sobre o modelo e a linguagem
A abordagem adotada para tratar a reatividade nos modelos sncronos e em

particular em Esterel se baseia na hiptese de sincronismo que determina a
instantaneidade da reao. A cada reao, o sinal vindo do ambiente ou de um
componente se encontra presente em todos os componentes paralelos. Esta abordagem
pode levar a situaes indesejveis nas quais um sinal pode ser alterado devido ao teste
sobre o mesmo sinal, resultando num problema de causalidade e consequentemente em
programas incorretos. A seguir so apresentados alguns exemplos de situaes que
geram programas incorretos e que necessitam da definio de uma semntica formal de
execuo para resolve-los.
Causalidade:
A expressividade da linguagem sncrona Esterel possibilita a construo de
programas no-causais.
A capacidade de comunicao atravs de sinais difundidos instantaneamente, pode
levar alguns programas a desrespeitar a causalidade. Por exemplo, o programa que
segue:
present S else emit S end
corresponde a testar a ausncia de um sinal S; se o mesmo se fizer ausente, o sinal

emitido e ento presente; se estiver presente, o sinal no emitido e consequentemente
ausente. Este programa apresenta uma incoerncia com o principio de comunicao
com difuso e deve ser absolutamente rejeitado em tempo de compilao. O circuito
lgico equivalente a este programa S = not S mostra facilmente o absurdo deste.
present S then emit S end
Da mesma forma, o programa no determinista, pois S presente se e somente se

S for emitido, o que no determina seu estado. O circuito lgico equivalente a este
programa S = S tambm no faz sentido.
O programa seguinte:
present S 1 else emit S 2 end

||
present S 2 else em it S 1 end
expressa as seguintes situaes: S1 ausente e S2 presente; S2 ausente e S1 presente. Este

programa fere o determinismo do modelo sncrono porque essas duas situaes no
podem ocorrer simultaneamente e, portanto, tambm deve ser rejeitado.
Podem ainda existir situaes nas quais apesar de ser construdo a partir de
componentes paralelos sem problemas de causalidade, o sistema total pode apresentar
incoerncias do ponto de vista da causalidade. Em [BoS96] apresentado o seguinte
exemplo desta situao. Sejam dois programas p1 e p2 respectivamente que apresentam
o mesmo comportamento (U emitido e T emitido se S presente):
present S then em it T end; em it U
em it U ; p resen t S th en em it T en d
o sistema total que consiste em colocar cada um destes programas em paralelo com um
terceiro programa p3 cujo cdigo :
p re se n t U th e n e m it S e n d
apresenta uma soluo correta para o caso p2 || p3 e uma no-causalidade para p1 || p3.
4.9 Concluso 129
Malhas instantneas:
Uma outra situao indesejvel que pode levar a uma situao sem soluo o caso
das malhas instantneas cujo corpo termina no instante onde executado pela primeira
vez; por exemplo na instruo:
loop x := x+1 end
Sinais com valores:

Algumas situaes envolvendo sinais com valores geram incoerncias no programa.
Por exemplo a instruo
em it S (?S + 1)
indica a emisso de um sinal S cujo o valor fornecido por ?S + 1 que corresponde ao

valor corrente de S acrescido de 1; o efeito obtido equivalente a uma realimentao
positiva e inaceitvel num programa Esterel.
Todas essas situaes paradoxais devem ser evitadas pelo programador ou
detectadas e rejeitadas a partir de uma analise esttica dos programas pelos
compiladores da linguagem Esterel . Uma forma fcil consiste em proibir a auto-
dependncia esttica dos sinais, da mesma forma que se exige que circuitos lgicos
sejam acclicos; mas esta forma se apresenta como restritiva para algumas situaes
raras nas quais pode se desejar programas com dependncias cclicas como no caso do
mecanismo de arbitro de barramento simtrico numa rede local, conforme descrito em
[Ber 99].
4.9 Concluso
Este captulo foi escrita a partir da bibliografia seguinte: [Ber89], [BeB91],

[GLM94], [BoS96] na apresentao e discusso da abordagem sncrona e [BoS91],
[BeG92], [Ber98], [Ber99] na apresentao da linguagem sncrona Esterel.
A abordagem sncrona apresentada neste captulo adota o modelo sncrono que,
basicamente, assume reaes instantneas a eventos externos. Esta hiptese de reaes
instantneas pode ser entendida como qualquer tempo de resposta menor que o tempo
mnimo entre eventos vindos do ambiente. Muito aplicaes de tempo real sustentam
esta hiptese como verdadeira.
A utilizao de uma linguagem sncrona, neste livro Esterel, leva implementaes
eficientes dos sistemas de tempo real baseadas em autmatos ou em circuitos

booleanos. Essas implementaes so facilmente validadas segundo o principio o que
voc prova o que voc execute descrito anteriormente.
Sistemas embutidos, protocolos de comunicao, drivers para perifricos,
sistemas de superviso e controle, e interfaces homem-mquina so aplicaes ou
partes de aplicaes mais complexas para as quais o uso da abordagem sncrona
particularmente adaptada. No capitulo 5, a partir de um exemplo simples ser
apresentada uma metodologia de programao baseada na abordagem sncrona e
seguindo o estilo de programao da linguagem Esterel.
Captulo 5
Aplicao das Abordagens Assncrona e

Sncrona
O objetivo deste captulo mostrar, atravs de exemplos mais significativos, como

as tcnicas apresentadas ao longo deste livro podem ser aplicadas na prtica. A seo
5.1 trata de uma aplicao do tipo "veculo com navegao autnoma", a qual ser
tratada segundo a abordagem assncrona, isto , utilizando a anlise de
escalonabilidade, um sistema operacional de tempo real e uma linguagem de
programao como C ou C++. A seo 5.2 apresenta uma aplicao do tipo "sistema de
controle", a qual em funo das suas caractersticas, ser tratada segundo a abordagem
sncrona, utilizando a linguagem Esterel. A seo 5.3 contm uma discusso sobre as
duas abordagens e elementos para a comparao e a melhor utilizao destas.
importante observar que a limitao de espao impossibilita uma descrio
completa de tais aplicaes. Entretanto, mesmo com a descrio simplificada
apresentada aqui pretende-se permitir ao leitor uma melhor compreenso de como as
tcnicas apresentadas neste livro podem ser usadas em aplicaes reais.
5.1 Aplicao com Abordagem Assncrona
Esta seo descreve um sistema com requisitos de tempo real, o qual ser utilizado
para exemplificar a aplicao das tcnicas apresentadas nos captulos 2 e 3 deste livro.
O sistema descrito consiste de um veculo com navegao autnoma (AGV
"Automatically Guided Vehicle") bastante simplificado. O objetivo no descrever o
projeto completo de tal aplicao (tarefa para vrios livros do tamanho deste), mas sim
ilustrar aquilo que foi discutido. A literatura sobre o tema vasta. Por exemplo, em
[POS97] e [BCH95] que inspiraram o problema a ser tratado a seguir, so descritas
solues completas para um veculo submarino e um veculo para realizar inspees em
depsitos de lixo txico, respectivamente.
5.1.1 Descrio do Problema
Um veculo com navegao autnoma deve ser capaz de planejar e executar a tarefa
especificada. Veculos com navegao autnoma so usados, por exemplo, para
132 5. Aplicao das Abordagens Assncrona e Sncrona
transporte de material no cho da fbrica, para a inspeo em reas de risco ou

depsitos de material txico. Eles podem ser usados como trator para puxar algo, no
transporte de material ou ainda como base mvel para um equipamento. Aps a
determinao do plano a ser seguido, sua execuo iniciada. Um sistema de sensores
usado para dirigir o veculo. Os componentes bsicos de um AGV incluem:
Partes mecnicas e sistema de propulso;
Sistemas eletrnicos;
Sistema sensorial, com sensores internos e externos;
Mdulo de planejamento e navegao;
Representao interna do mundo em volta do veculo.
O AGV considerado ser usado para o transporte de material. Ele tipicamente
desloca-se at o local onde dever pegar o material a ser transportado (navegao),
posiciona-se de forma a realizar a carga do material (atracagem), coloca o material em
seu compartimento de carga (carga), manobra para sair do local de carregamento
(desatracagem), desloca-se at o local destino da carga (navegao), manobra para
entrar no local de descarga (atracagem) e finalmente coloca no material transportado no
seu destino (descarga). possvel observar que existem 3 fases distintas na operao do
AGV, as quais resultam em 3 modos de operao independentes:
Carregamento e descarregamento de material;
Planejamento da rota e navegao;
Manobra para atracar e desatracar de algum tipo de estacionamento.
Com respeito ao modo de operao "planejamento da rota e navegao", possvel
dividir o trabalho a ser feito em 3 nveis [RNS93]:
Nvel de planejamento;
Nvel de navegao;
Nvel de pilotagem.
Neste livro vamos considerar exclusivamente o nvel de navegao. A navegao
parte do plano original desenvolvido pelo nvel de planejamento e, considerando as
condies locais informadas pelos sensores, dirige o veculo. Diferentes tipos de
sensores podem ser usados, tais como bssula, medidor de inclinao, contadores de
pulsos nas rodas, cameras de vdeo, sensores de proximidade, sensores de contato, etc.
A navegao pode ainda ser auxiliada por emissores de infra-vermelho ou rdio-
freqncia colocados ao longo da fbrica.
Desvios da rota inicialmente traada podem ser necessrios em funo de
obstculos e para evitar colises. Quanto maior o nmero de objetos mveis no cho da
fbrica mais complexa torna-se a navegao. No caso da rota original tornar-se
invivel, em funo de um obstculo que no pode ser contornado, uma nova etapa de
planejamento torna-se necessria. O objetivo da navegao determinar a direo e
velocidade desejada para o veculo, a qual passada para o nvel de pilotagem,
responsvel pelas operaes de controle elementares. A pilotagem utiliza laos de
5.1 Aplicao com Abordagem Assncrona 133
controle para garantir a correta implementao das decises de direo e velocidade

recebidas do nvel de navegao.
No projeto em questo a navegao utiliza uma combinao de trs informaes:
monitorao do movimento das rodas, observao de pontos de referncia no ambiente
e conhecimento prvio de um mapa bsico do ambiente. O movimento das rodas
medido e marcado sobre o mapa do ambiente, o qual foi carregado previamente. A
estimativa da posio do veculo a partir do movimento das rodas torna-se mais
imprecisa na medida que a distncia percorrida aumenta. O erro retorna para zero
quando a observao de pontos de referncia no ambiente permite determinar com
exatido a posio do veculo. Alm disto, obstculos podem ser observados e, neste
caso, o mapa do ambiente atualizado. A partir da posio, velocidade e direo atuais
do veculo, e do plano a ser seguido, so definidas a nova direo e velocidade a serem
implementadas. A figura 5.1 apresenta em forma de diagrama de fluxo de dados as
funes do nvel de navegao.
Reconhece
Monitora Estima
alarme
rodas posio
Computa
posio
Obtm Reconhece
Define
imagem referncia velocidade
e direo
Identifica Atualiza
mapa
obstculo
Mapa
Figura 5.1 - Diagrama do nvel de navegao.
A fsica do veculo impe restries temporais para a navegao, para que esta seja
capaz de evitar colises e realizar as manobras com segurana. A definio de
velocidade e direo tem o perodo definido pela fsica do veculo, sua velocidade
mxima, caratersticas do terreno, etc. Neste caso os engenheiros de controle definiram
100ms como perodo mximo. A estimativa da posio a partir da monitorao das
rodas deve ser feita a cada 100 ms. O reconhecimento de referncias no necessita ser
to freqente, at porque o algoritmo usado complexo. Uma tentativa de
reconhecimento de referncias a cada 1300 milisegundos considerado satisfatrio. Por
outro lado, a identificao de obstculos deve ser feita a cada 500 ms. Esta freqncia
permite que o veculo, mesmo em velocidade mxima, desvie de um obstculo que
surge repentinamente, por exemplo um outro veculo. Alm das funes normais, um
auto-diagnstico deve ser executado no prazo de 20 ms sempre que um sinal de
comando for recebido, por exemplo, de uma estao de superviso.
No caso do AGV descrito, os perodos de funes que no foram definidos

explicitamente pela especificao podem ser facilmente deduzidos. Como obstculos
so identificados a partir das imagens, a obteno de imagens tambm deve ser feita a
cada 500ms. Como a atualizao do mapa acontece em funo da identificao de
obstculos, ela tambm dever ser executada a cada 500ms.
5.1.2 Definio das Tarefas
Uma vez especificado o comportamento temporal desejado conforme descrio

anterior, o projetista de software define as tarefas e os tempos associados a partir da
especificao, conforme a funo de cada uma. O fato de duas tarefas trocarem
mensagens ou acessarem estruturas de dados compartilhadas podem criar situaes de
precedncia ou excluso mtua. Finalmente, a codificao das tarefas e o processador
escolhido vo definir os tempos mximos de execuo de cada tarefa. Em resumo,
temos tipicamente que:
Perodos e "deadlines" so definidos pelos algoritmos de controle
empregados;
Relaes de precedncia e excluso mtua so definidos pelo projeto
do software;
Tempo mximo de execuo definido pela programao das tarefas
e escolha do processador.
Neste livro, adota-se valores arbitrrios para os tempos de execuo das tarefas.
Entretanto, estes tempos assim como as demais caractersticas das tarefas, foram em
parte baseadas em uma descrio semelhante encontrada em [But97].
A partir de um estudo cuidadoso da especificao possvel perceber que todas as
funes so peridicas com deadline igual ao perodo, com exceo do tratamento de
sinais de alarme, os quais podem acontecer a qualquer instante. Sero empregadas 7
tarefas de software para implementar o nvel de navegao do AGV. suposto que elas
devem executar no mesmo processador.
COMPUTA_POSIO (C_P)
Tarefa peridica que l os sensores acoplados s rodas do veculo e estima a posio
atual do veculo, em funo da posio anterior e do comportamento das rodas, com
perodo de 100ms e tempo mximo de execuo de 20ms. Se alguma referncia tiver
sido reconhecida desde a ltima execuo desta tarefa, ento esta informao tambm
utilizada para computar a posio atual do veculo.
L_IMAGEM (L_I)
Tarefa peridica que l a imagem gerada por uma cmara CCD, trata a imagem e
armazena em uma estrutura de dados. Perodo de 500ms e tempo mximo de execuo
de 20ms. A imagem gerada colocada em uma estrutura de dados do tipo "buffer
duplo", de forma a no criar situaes de bloqueio para as tarefas que consomem esta
informao.
ATUALIZA_MAPA (A_M)
Tarefa que usa a imagem gerada pela tarefa L_IMAGEM e procura identificar
obstculos. Em caso positivo, o mapa do ambiente mantido pelo veculo atualizado.
Perodo de 500ms e tempo mximo de execuo de 100ms. Existe uma relao de
precedncia direta entre L_IMAGEM e ATUALIZA_MAPA.
RECONHECE_REFERNCIA (R_R)
Tarefa que usa a imagem mais recentemente gerada pela tarefa L_IMAGEM e
procura reconhecer referncias. Em caso positivo, armazena a informao em estrutura
de dados a ser consumida pela tarefa COMPUTA_POSIO, sem entretanto
estabelecer uma relao de precedncia. Perodo de 1300ms e tempo mximo de
execuo de 200ms.
DEFINE_VELOCIDADE_DIREO (D_V_D)
Tarefa que usa a posio atual computada e a verso mais recente do mapa do
ambiente para definir a velocidade e direo que o veculo deve assumir. Estas
informaes so passadas para o nvel de pilotagem, responsvel pela sua
implementao. Esta tarefa possui perodo de 100ms e tempo mximo de execuo de
30ms. Existe uma relao de precedncia entre a tarefa COMPUTA_POSIO e a
tarefa DEFINE_VELOCIDADE_DIREO.
EXECUTA_DIAGNSTICO (E_D)
Tarefa aperidica disparada por um sinal de rdio, ela executa um autodiagnstico
sobre o sistema, sendo capaz de parar o veculo de maneira controlada se uma situao
de emergncia for detectada. Possui um deadline de 20 ms e suposto que o intervalo
mnimo entre ativaes de 2 segundos. O tempo mximo de execuo desta tarefa 1
ms.
RELATA ( R )
Tarefa que informa a estao de superviso sobre sua posio, velocidade e direo,
a partir dados obtidos pelos sensores. Esta tarefa no crtica ("soft"), pois no afeta o
deslocamento e o comportamento do veculo.
Existe ainda uma relao de excluso mtua entre as tarefas
RECONHECE_REFERNCIA e COMPUTA_POSIO, no momento que esta ltima
acessa as informaes sobre referncias identificadas. O tempo mximo de execuo da
seo crtica neste caso de 1ms. Tambm existe uma relao de excluso mtua entre
as tarefas ATUALIZA_MAPA e DEFINE_VELOCIDADE_DIREO em funo do
mapa do mundo. O tempo mximo de bloqueio neste caso de 3 ms.
Uma vez definidas as tarefas e suas caractersticas temporais, necessrio avaliar a
escalonabilidade do sistema, o que ser feito na prxima seo.
5.1.3 Modelo de Tarefas
A tabela 5.1 resume a definio das tarefas, como descrito na seo anterior. Antes
de proceder anlise de escalonabilidade, necessrio adaptar este conjunto de tarefas
no sentido de refletir tambm os custos do sistema ("overhead") e outros aspectos
relativos implementao.
. Tarefa Tipo P (ms) D (ms) C (ms) Predecessor Bloqueio (ms)

C_P Peridica 100 100 20 1 (c/R_R)
L_I Peridica 500 500 20
A_M Peridica 500 500 100 L_I 3 (c/D_V_D)
R_R Peridica 1300 1300 200 1 (c/C_P)
D_V_D Peridica 100 100 30 C_P 3 (c/A_M)
E_D Espordica 2000 20 1
R Soft
Tabela 5.1 - Definio das tarefas, verso inicial
O tempo de execuo de alguns elementos do sistema operacional so computados

juntos com o tempo de execuo das tarefas. Por exemplo, o tempo de computao das
chamadas de sistema e o tempo necessrio para carregar o contexto da tarefa j esto
considerados nos tempos de execuo das tarefas.
O temporizador em hardware ("timer") do sistema gera interrupes
periodicamente. Estas interrupes so usadas para marcar a passagem do tempo e,
entre outras coisas, liberar as tarefas sempre no incio do respectivo perodo. Entretanto,
a execuo peridica do tratador de interrupes do "timer" representa uma
interferncia sobre as demais tarefas. Logo, o tratador de interrupes do "timer" entra
no clculo de escalonabilidade como uma tarefa peridica com perodo igual ao do
"timer" e tempo de execuo igual ao tempo de execuo deste tratador de interrupes.
So supostos os valores Ptimer=10ms e Ctimer=0.1ms para a tarefa "timer" que
representa este tratador.
Tambm necessrio ampliar o modelo de tarefas inicial no sentido de incluir
outros efeitos causados pelo suporte de execuo. suposto que a implementao
emprega um sistema operacional de tempo real cujo "kernel" permanece quase a
totalidade do tempo com as interrupes habilitadas. Entretanto, algumas sees crticas
do "kernel" desabilitam as interrupes por breves instantes. A maior seo de cdigo
do "kernel" que executa com interrupes desabilitadas o faz durante Bk = 0.1 ms.
Caso uma interrupo do "timer" acontea enquanto o "kernel" est com

interrupes desabilitadas, ela somente ser tratada com um atraso (latncia) de Bk.
Suponha que esta interrupo do "timer" sinalize o incio do perodo de uma tarefa.
Neste caso, a liberao da tarefa somente vai acontecer Bk unidades de tempo aps o
incio de seu perodo. Este atraso caracteriza claramente um "release jitter". Todas as
tarefas que no possuem predecessores sofrem um "release jitter" com durao mxima
de Bk unidades de tempo, inclusive o prprio tratador do "timer".
Outrossim, as tarefas que possuem predecessores no so liberadas por passagem de

tempo mas sim pela sinalizao da concluso de sua tarefa predecessora. Desta forma,
podemos considerar que a tarefa em questo possui um "release jitter" igual ao tempo
mximo de resposta da sua tarefa predecessora. Observe que a tarefa predecessora
ativada pela passagem do tempo, e inclui no seu tempo mximo de resposta a latncia
de interrupo do sistema. A tarefa sucessora herda o "release jitter" da tarefa
predecessora como parte do seu tempo mximo de resposta.
No caso do bloqueio por excluso mtua, importante observar que apenas ocorre
bloqueio quando a tarefa de prioridade mais alta deve esperar a tarefa de prioridade
mais baixa. Quando a tarefa de prioridade mais baixa tem que esperar, no ocorre
bloqueio mas uma simples interferncia. Assim, cada excluso mtua gera apenas uma
situao de bloqueio e no duas, como aparece na tabela 5.1. Por exemplo, a tabela 5.1
mostra bloqueio entre entre as tarefas R_R e C_P, e vice-versa. Na verdade somente
existir bloqueio da tarefa mais prioritria pela menos prioritria.
A tarefa espordica E_D assumida como peridica a nvel de teste de
escalonabilidade, como permitido pelas equaes [9] e [10] do captulo 2. Para executar
a tarefa R podemos a princpio empregar qualquer tipo de servidor (PS ou DS, por
exemplo). Mas a nvel de teste ambos os servidores podem ser tratados como uma
tarefa peridica. Se assumirmos que no sero pedidos dois relatrios em um intervalo
de 10 segundos, ento podemos tratar a tarefa R tambm como espordica.
As tarefas E_D e R so ativadas por sinais de rdio e compartilham a mesma rotina
que trata interrupes deste tipo. O tempo de execuo deste tratador de interrupes
de Bm = 0.1 ms. Nesta aplicao o tratador de interrupes deste tipo tem o seu cdigo
acrescido ao da tarefa aperidica espordica E_D, pois a tarefa mais prioritria que as
demais da aplicao. Desta forma, ele aparece como interferncia para as demais
tarefas, com exceo da tarefa que representa o "timer". Este tratador no interfere com
o "timer" porque o vetor de interrupo menos prioritrio que o do "timer".
Entretanto, quando este tratador executa em funo da tarefa R, ele aparece como uma
situao de bloqueio para a tarefa E_D.
Ser usada a poltica Deadline Monotnico (DM) neste sistema, pois algumas
tarefas apresentam "deadlines" relativos menores que os seus respectivos perodos. Nas
atividades a atribuio de prioridades obedece a orientao das relaes de precedncia,
isto , tarefas predecessores possuem prioridade mais alta. A tabela 5.2 resume a
definio das tarefas, aps terem sido considerados todos os fatores discutidos acima.
As tarefas aparecem na tabela 5.2 em ordem crescente de deadline, o que significa que
as tarefas com prioridade mais alta aparecem antes na tabela.
Tarefa Tipo P (ms) D (ms) C (ms) J (ms) Predecessor Bloqueio (ms)

timer peridica 10 10 0,1 Bk
C_P peridica 100 100 20 Bk 1 (B R_R ))
L_I peridica 500 500 20 Bk
A_M peridica 500 500 100 R L_I L_I
R_R peridica 1300 1300 200 Bk
D_V_D peridica 100 100 30 R C_P C_P 3 (B A_M )
E_D espordica 2000 20 1 Bk Bm
R servidora 10000 80 5 Bk
Tabela 5.2: Definio das Tarefas, Verso Final
5.1.4 Teste de Escalonabilidade
Para verificar a escalonabilidade do conjunto usaremos o teste baseado em tempos

de resposta apresentado em [TBW94], onde tarefas experimentam tambm atrasos em
suas liberaes. Este teste constitudo pelas equaes [9] e [10] do captulo 2, as quais
so reproduzidas abaixo, e pela verificao da condio:
i : 1 i n, Ri Di .
Wi + J j
Wi = Ci +
Pj j
C [9 ]
j hp(i)
R i = Wi + J i . [10]
Vamos a seguir calcular o tempo mximo de resposta de cada uma das tarefas da
aplicao, como descritas no modelo de tarefas final. importante destacar que o
modelo de tarefas final inclui no somente as tarefas da aplicao, mas tambm tarefas
que representam os custos associados com o suporte de execuo.
Clculo do tempo de resposta do "timer"
Wtimer = Ctimer = 0,1
Rtiner = Wtimer + Bk = 0,2 ms
Clculo do tempo de resposta da tarefa E_D
WE _ D + Bk
WE _ D = C E _ D + B M + Ctimer = 1,2
Ptimer
RE _ D = WE _ D + Bk = 1,3 ms
Clculo do tempo de resposta da tarefa R
W + Bk W + Bk
WR = CR + R Ctimer + R CE _ D = 6,1
Ptimer PE _ D
RR = WR + Bk = 6,2 ms
Clculo do tempo de resposta da tarefa C_P
WC _ P + Bk WC _ P + Bk
WC _ P = CC _ P + BR _ R + Ctimer + CE _ D +
Ptimer PE _ D
WC _ P + Bk
+ CR = 27,3
PR
RC _ P = WC _ P + Bk = 27 ,4 ms
Clculo do tempo de resposta da tarefa D_V_D
WD_V _ D + Bk WD_V _D + Bk
WD_V _ D = CD_V _ D + BA_ M + Ctimer + CE _ D +
Ptimer PE _ D
WD_V _ D + Bk
+ CR = 39,6
PR
RD _V _ D = WD _V _ D + RC _ P = 67 ms
Clculo do tempo de resposta da tarefa L_I
WL _ I + Bk WL _ I + Bk WL _ I + Bk
WL _ I = CL _ I + Ctimer + CE _ D + CR +
Ptimer PE _ D PR
WL _ I + Bk WL _ I + RC _ P
+ CC _ P + CD_V_D = 123,3
PC _ P PD_V _ D
RL _ I = WL _ I + Bk = 127,4 ms
Clculo do tempo de resposta da tarefa A_M
WA_ M + Bk WA_ M + Bk WA_ M + Bk

WA_ M = CA_ M + Ctimer + CE _ D + CR +
Ptimer PE _ D PR
WA_ M + Bk WA_ M + RC_ P
+ CC_ P + CD_V_D = 258,6
PC_ P PD_V _ D
R A _ M = WA _ M + RL _ I = 386,0 ms
Clculo do tempo de resposta da tarefa R_R
WR_ R + Bk WR_ R + Bk WR_ R + Bk

WR_R = CR_ R + Ctimer + CE _ D + CR +
Ptimer PE _ D PR
WR_ R + Bk WR_ R + RC_ P WR_ R + Bk
+ CC_ P + CD_V_D + CL_ I +
PC_ P PD_V _ D PL_ I
WR_ R + RL_ I
+ CA_ M = 1228,3
PA_ M
RR _ R = WR _ R + Bk = 1228,4 ms
Como todas as tarefas apresentam tempo mximo de resposta menor do que o

respectivo deadline (por exemplo, a tarefa R_R tem um tempo mximo de resposta de
1228.4 milisegundos, enquanto o seu deadline de 1300ms), conclui-se que o sistema
escalonvel.
Na prxima seo, sero discutidos aspectos da implementao desta aplicao e
entre outras coisas ser, a ttulo de ilustrao, definido como suporte deste projeto o
RT-Linux. Como na abordagem assncrona necessrio que se considere aspectos de
implementao nas anlises, todos os tempos referentes ao "kernel" devem sempre ser
considerados tomando como base o suporte escolhido. Os tempos referentes aos
tratadores e bloqueios do "kernel" (Bm, Ctimer e Bk) foram super estimados quando
assumidos nas nossas anlises como sendo da ordem de 0.1ms. As medidas de latncia
de interrupo apresentadas em [YoB99] para a verso 2 do RT-Linux so da ordem de
microsegundos. Este pessimismo exagerado d uma boa margem de segurana que,
uma vez o conjunto de tarefas passe pelos testes de escalonabilidade, estas tarefas
quando implementadas tero suas restries temporais respeitadas em tempo de
execuo.
5.1.5 Programao Usando RT-Linux
Uma aplicao de tempo real tipicamente um programa concorrente. Logo, todas

as tcnicas de programao e mtodos de depurao usados na programao
concorrente podem ser usados aqui. Em particular, o ambiente de programao
escolhido define como a soluo ser expressa em termos sintticos. Ambiente de
programao neste contexto significa a linguagem de programao e o sistema
operacional escolhido. O tema "linguagens de programao" no ser abordado neste
livro, embora seja um tpico importante (um levantamento neste sentido pode ser
encontrado em [Coo96]). Apesar de diversas propostas a nvel acadmico, aplicaes

de tempo real so ainda programadas principalmente com C e C++. Linguagens de
programao especialmente projetadas para tempo real procuram embutir na prpria
sintaxe da linguagem as construes relacionadas com tempo e concorrncia, mas isto
no acontece com C e C++. Estas so linguagens a princpio para programao
seqencial e qualquer capacidade alm desta obtida atravs de chamadas de rotinas de
uma biblioteca ou do sistema operacional.
Com o propsito de ilustrar o tipo de servio encontrado na prtica, assim como a
sintaxe tpica, esta seo descreve parcialmente a API ("Application Programming
Interface") do Real-Time Linux verso 2, como descrita em [YoB99] e disponvel,
assim como o prprio sistema operacional, na pgina http://www.rtlinux.org. O RT-
Linux est em rpida evoluo e, provavelmente, quando este livro for publicado, novas
verses j estaro disponveis. A verso 2 do RT-Linux, implementada para
processadores x86 genricos, apresenta uma latncia de interrupo mxima de 15
microsegundos. Uma tarefa peridica inicia sua execuo com um desvio mximo de
25 microsegundos do instante planejado (se no existir outra tarefa liberada com
prioridade maior). So valores que permitem o emprego do RT-Linux em uma ampla
variedade de aplicaes.
O conjunto de rotinas do RT-Linux suficiente para implementar uma aplicao de
tempo real composta por vrias tarefas. Este sistema operacional foi projetado a partir
da premissa que tarefas de tempo real executam sobre o "microkernel" com
funcionalidade mnima e excelente comportamento temporal, ao passo que tarefas sem
restrio temporal executam como tarefas Linux convencionais. Desta forma, qualquer
acesso a disco, tela ou rede local deve ser feito por tarefas convencionais. A
comunicao entre estes dois tipos de tarefas pode ser feita atravs do RT-FIFO ou
atravs de memria compartilhada.
Abaixo est o exemplo de uma tarefa peridica simples, usando a API do RT-Linux
verso 1. Neste exemplo foram utilizadas as seguintes chamadas de sistema:
int rt_get_time ( void );
Retorna a hora em "ticks".
int rt_task_init ( RT_TASK *task, void (*fn)(int data), int data,
int stack_size, int priority );
Inicializa mas no escalona uma tarefa.
int rt_task_make_periodic ( RT_TASK *task, RTIME start_time,
RTIME period );
Transforma a "thread" em peridica.
int rt_task_wait ( void );
Libera o processador at a prxima ativao da tarefa.
5.2 Aplicao com Abordagem Sncrona 143
#define STACK_SIZE 3000

RT_TASK my_task;
/* Cdigo da tarefa de tempo real, um lao infinito */

void codigo_da_tarefa( unsigned int x) {
/* Variveis locais desta tarefa */
. . .
while ( 1 ) {
/* Faz o que esta tarefa tem que fazer */
. . .
/* Espera at o prximo perodo */
rt_task_wait();
}
}
/* Mdulo de inicializao da aplicao */

int init_module( void ){
RTIME now = rt_get_time();
/* Inicializa a tarefa */
rtl_task_init( &my_task, codigo_da_tarefa, arg, STACK_SIZE, 1 );
/* Executa a cada 50 ms, aproximadamente 450 na unidade usada */

rtl_task_make_periodic(&mytask, now, 450);
return 0;
}
Um exemplo completo usando RT-Linux pode ser encontrado em [Wur99], onde

uma aplicao de controle descrita. Uma interface grfica de usurio usando X-
Windows comunica-se com tarefas de tempo real atravs de RT-FIFO, as quais
controlam uma varivel fsica atravs de um algoritmo de controle simples.
5.2 Aplicao com Abordagem Sncrona
O objetivo deste exemplo de ilustrar uma metodologia e um estilo de programao

para a abordagem sncrona. A aplicao escolhida simples o suficiente para o leitor
no precisar de conhecimentos adicionais e poder focalizar apenas os aspectos
associados a sua programao. A aplicao consiste de um sistema de controle de
processo, inspirado no exemplo apresentado em [ AnP93] e cuja descrio segue. O
sistema a controlar consiste de um reservatrio de gua do qual pretende-se controlar
o nvel para que ele fique sempre entre um mnimo e um mximo. Uma bomba quando
ligada tende a esvaziar o reservatrio e uma vlvula permite enche-lo quando aberta. A
informao de nvel fornecida por dois sensores indicando os limites inferior e
superior para a gua contida no reservatrio (respectivamente nvel mnimo e nvel
mximo). A figura 5.2 mostra um diagrama esquemtico da aplicao de regulao de
nvel de um reservatrio.
V lv u la Bomba
N v e l_ M a x i
N v e l_ M in i
Figura 5.2: Esquema da Regulao de Nvel de um Reservatrio

O sistema de controle ser estudado e construdo num primeiro tempo para o
comportamento normal do sistema a controlar e a seguir para uma situao de falha
neste. Inicialmente, tratado o caso do funcionamento normal do sistema a controlar. O
problema decomposto em duas partes, uma correspondente a atividade da vlvula
para regular o nvel do reservatrio e outra a atividade de consumo de gua pela bomba.
Essas duas atividades so independentes e ocorrem em paralelo. A partir desta viso do
problema, possvel construir o programa do sistema de controle do reservatrio como
sendo o resultado da composio de dois mdulos atuando em paralelo, um responsvel
pela regulao de nvel a partir da ao da vlvula (REGNIVEL) e outro pelo consumo
de gua pela bomba (CONSUMO). A arquitetura do sistema de controle apresentada
na figura 5.3.
In ic _ R e g F im _ R e g R E S E R V A T O R IO
V lv u l a
R E G N V E L A b ra _ V a lv
F e c h a _ V a lv
N iv _ m i n
N iv _ m a x
Bom ba
CONSUMO L ig a _ B o m b a
D e s li g a _ B o m b a
In ic _ C o n s u m o F im _ C o n s u m o
6 LV W H P D G H & R Q WU R OH $ P E LH Q WH
Figura 5.3: Arquitetura do Sistema de Controle

O mdulo REGNIVEL visa manter o nvel do reservatrio entre o mnimo e o

mximo indicado pelos sensores de nvel (sinais Niv_min e Niv_max), abrindo e
fechando a vlvula de regulao do reservatrio a partir da emisso dos sinais
Abra_Valv e Fecha_Valv. O mecanismo de regulao ativado por um comando
externo de inicio (sinal Inic_Reg) e atua at ocorrer o comando de fim (sinal
Fim_Reg). Para efeito de simplificao do problema, assumido que no inicio, o
reservatrio se encontra com um nvel intermedirio entre o mnimo e o mximo. O
cdigo em Esterel do mdulo apresentado a seguir:
m o d u le R E G N IV E L :
in p u t In ic_ R eg , F im _R eg, N iv _m in , N iv_ m ax ;
ou tp u t A b ra _V a lv , F ech a_ V alv;
aw a it In ic_R eg;
em it F ech a _V a lv ;
ab ort
loo p
aw a it N iv _m in ;
em it A b ra _V alv ;
aw a it N iv _m a x;
em it F ech a _V a lv ;
en d loo p
w h en F im _R eg
en d m o d u le
Deve se notar que a programao do mdulo REGNIVEL segue o estilo de

programao Esterel descrito no captulo 4. Aps a inicializao do processo de
regulao a partir do sinal Inic_Reg, o corpo do programa descrevendo a regulao de
nvel pela vlvula est embutido numa construo do tipo preempo forte que termina
com a chegada do sinal Fim_Reg.
O mdulo CONSUMO gera os comandos de liga e desliga da bomba de gua

(sinais Liga_Bomba, Desliga_Bomba), a partir de comandos externos de inicio e fim
de consumo (sinais Inic_Consumo, Fim_Consumo). O cdigo deste mdulo em
Esterel :
module CONSUMO :
input Inic_Consumo, Fim_Consumo;
output Liga_Bomba, Desliga_Bomba;
loop
await Inic_Consumo;
emit Liga_Bomba;
await Fim_Consumo;
emit Desliga_Bomba
endloop
endmodule
O programa em Esterel do sistema de controle do Reservatrio em situao de

funcionamento normal do sistema a controlar o mdulo RESERVATORIO,
resultado da composio paralela dos dois mdulos anteriores:
m odu le R E SE R V A T O R IO :
in pu t In ic_R eg, Fim _R eg, In ic_C on su m o, Fim _C on sum o;
ou tp ut A b ra_V alv, F ech a_V alv, L iga_B om ba, D esliga_B om b a;
signal N iv_m in, N iv_m ax in

run C O N SU M O
||
run R E G N IV EL
en d signal
en d m odu le
No caso de considerar tambm as situaes anormais do sistema a controlar, o

sistema necessita alm do mdulo de controle, um mdulo de deteco de falha e um de
tratamento desta. Uma situao anormal clssica neste exemplo do reservatrio
corresponde ao funcionamento da bomba "a vazio"; necessrio detectar ento quando
o nvel do reservatrio muito baixo para poder parar o funcionamento da bomba,
evitando danifica-la. Para descrever o comportamento do sistema, torna-se necessrio
introduzir um mdulo encarregado de detectar falha (no caso o nvel de gua
insuficiente) e um mdulo de recuperao da falha. Esses mdulos so respectivamente
os mdulos MONITORA_CONSUMO e REPARO.
Para ter a garantia que existe realmente uma falha no sistema, o mecanismo de
deteco do mdulo MONITORA_CONSUMO atuar somente se o sinal Niv_min
estiver presente em trs ocorrncias seguidas de um sinal de relgio Rel, confirmando
desta forma a existncia da falha. A ocorrncia desta falha gera uma exceo que
interrompe imediatamente o bloco do mecanismo de deteco e passa o controle para o
bloco de tratamento de exceo. A construo Esterel "trap T ... exit T ... handle T ..."
perfeitamente adequada para implementar o mecanismo de levantamento de exceo
("trap T ... exit T") e o tratamento desta ("handle T"); o mdulo de deteco de falha
MONITORA_CONSUMO esta construdo a partir dela. O corpo da construo trap
contm o mecanismo de deteco de falha adotado que quando acionado, desvia para o
tratador de exceo desta handle. O mdulo MONITORA_CONSUMO tem o cdigo
mostrado na prxima pgina.
O tratamento da exceo levantada no mdulo MONITORA_CONSUMO
realizado atravs do mdulo REPARO que se encarrega do reparo da situao anormal
correspondente ao nvel insuficiente do reservatrio. A especificao do sistema define
que este reparo deve ser realizado num tempo inferior a 10 minutos, seno um alarme
para um nvel mais alto de superviso dever ser enviado para assinalar a
impossibilidade de reparo.
m odule M O N ITO R A _C O N SU M O :
input R el, N iv_m in, C onsum o_em _C urso
var contador_tem po: integer in
contador_tem po := 0;
loop
trap M O N ITO R in
loop
present N iv_m in then
contador_tem po := contador_tem po + 1;
present C onsum o_em _C urso then
if contador_tem po >= 3 then
exit M O N ITO R
end if
end present
else
contador_tem po := 0
end present
each R el
handle M O NIT O R do
% tratam ento da situao detectada de insuficincia do nvel de gua
% pela execuo do m dulo R E PA R O
end trap
end loop
end var
end m odule
O reparo realizado por uma tarefa assncrona Reparo_Nivel_Insuficiente ( ) ( )

do mdulo REPARO que iniciar logo aps a exceo MONITOR do mdulo
MONITORA_CONSUMO ter sido levantada. A execuo desta tarefa assncrona
externa (no descrita aqui) realizada utilizando a primitiva exec de Esterel. No
mesmo tempo que inicia esta tarefa, o mdulo REPARO envia o sinal
Bomba_em_Reparo a todos os outros mdulos, segundo o mecanismo de difuso
instantnea de Esterel, para impedi-los de atuar enquanto a situao de reparo estiver
mantida. A finalizao da tarefa assncrona de reparo Reparo_Nivel_Insuficiente ( ) ( )
pode ser feita de forma normal se a durao de reparo for inferior a 10 minutos,
emitindo um sinal de Reparo_Bomba_Concluido que permitir abortar a execuo
concorrente, autorizando novamente a atuao dos outros mdulos. Se o tempo de
reparo ultrapassar o tempo fixado de 10 minutos, um "time-out" detectado, ativando a
emisso de um sinal de alarme Alarme_Bomba no nvel superior de superviso e
aguardando que este lhe permita retomar a execuo no futuro atravs de um sinal
Bomba-Autorizada vindo do nvel de superviso. O cdigo do mdulo REPARO
apresentado a seguir:
module REPARO :
input MINUTE, Bomba-Autorizada;
output Bomba_em_Reparo, Alarme_Bomba, Reparo_Bomba_Concluido;
task Reparo_Nivel_Insuficiente ( ) ( );
[
abort
exec Reparo_Nivel_Insuficiente ( ) ( )
when 10 MINUTE do
emit Alarme_Bomba;
await Bomba-Autorizada
end abort;
emit Reparo_Bomba_Concluido
]
||
abort
sustain Bomba_em_Reparo
when Reparo_Bomba_Concluido
endmodule
Deve se notar que o mdulo REPARO composto de dois blocos em paralelo, um

deles responsvel pela execuo do reparo da bomba e o outro pela informao aos
outros mdulos (via difuso instantnea) da situao de reparo desta, enquanto durar. A
informao de concluso do reparo no primeiro bloco (sinal
Reparo_Bomba_Concluido) imediatamente difundida ao segundo que deixa de
emitir para os outros mdulos o sinal Bomba_em_Reparo.
Para levar em conta, no programa em Esterel do sistema de controle do
Reservatrio, o comportamento faltoso e sua recuperao descritos anteriormente
necessrio substituir no mdulo RESERVATORIO o mdulo CONSUMO por um
mdulo CONSUMO_SEGURO. Neste mdulo, a indicao de ativao e desativao
do sistema feita respectivamente a partir dos sinais Inic e Fim. No mdulo
CONSUMO_SEGURO, aps a ativao do sistema (sinal Inic), emitido o sinal de
inicio da regulao (sinal Inic_Reg) que ser interrompida quando o sinal de
desativao do sistema ocorrer (sinal Fim). Entre essas duas ocorrncias (ativao e
desativao), o mdulo MONITORA_CONSUMO atuar em paralelo com o bloco
que descreve o consumo de gua e emite comandos para ligar e desligar a bomba. O
cdigo do mdulo CONSUMO_SEGURO apresentado a seguir:
module CONSUMO_SEGURO :
input Inic, Fim, Inic_Consumo, Fim_Consumo, Rel, Niv_min, MINUTE, Bomba-Autorizada;
output Liga_Bomba, Desliga_Bomba, Alarme_Bomba, Inic_Reg, Fim_Reg;
task Reparo_Nivel_Insuficiente ( ) ( );
signal Bomba_em_Reparo, Consumo_em_Curso, Reparo_Bomba_Concluido in

await Inic;
emit Inic_Reg;
abort
loop
await Inic_Consumo;
emit Liga_Bomba;
abort
sustain Consumo_em_Curso
when Fim_Consumo;
emit Desliga_Bomba
end loop
||
run MONITORA_CONSUMO
when Fim
end signal
end module
Mdulo REGNVEL
REL
Inic_Reg Fim_Reg
CONSUMO_SEGURO
MONITORA_CONSUMO Niv_min
handle Consumo_em Curso
Inic
Fim
MINUTE
REPARO Bomba_em_Reparo
Tarefa
externa
exec Reparo_Bomba_Concludo
Alarme_Bomba
Nvel
Superior
Bomba_Autorizada
Inic_Consumo Fim_Consumo
Figura 5.4: Representao do Mdulo CONSUMO_SEGURO

A figura 5.4 apresenta o mdulo CONSUMO_SEGURO com seus mdulos

internos MONITORA_CONSUMO e REPARO e suas interfaces com o mdulo
REGNIVEL, com o nvel superior de Superviso e com o ambiente (ou sistema a
controlar).
No exemplo anterior, foi apresentado um sistema simples no qual a modelagem do
comportamento no apresentava muitas alternativas. Entretanto, dependendo da
complexidade do problema, podem existir vrias possibilidades de modelar o
comportamento deste. A seguir, so apresentadas e discutidas algumas abordagens
possveis para a modelagem de sistemas mais complexos como por exemplo sistemas
de comando de uma clula de manufatura composta de vrios equipamentos (robs,
maquinas, esteiras, sensores, etc.). Exemplos de tais aplicaes podem ser encontrados
em [Cos 89], [Bud94], [CER92] e servem de base para a apresentao das diversas
abordagens de modelagem:
Abordagem 1: Decomposio por componente fsico

Esta abordagem consiste em associar um mdulo Esterel a cada componente
fsico do problema (p.ex. um mdulo para cada rob) e em aproveitar o
conceito de paralelismo da linguagem Esterel. Cada mdulo constitudo por
um conjunto de atividades geralmente realizadas em seqncia (p.ex. o
comportamento de um rob pode ser visto como a realizao de uma atividade
somente aps a concluso de outra). Todos estes mdulos so colocados em
paralelo e a troca de sinais entre eles permitem que eles cooperam entre si.
Abordagem 2: Decomposio funcional

A abordagem anterior esta baseada numa viso totalmente paralela da
aplicao, com alguns pontos de sincronizao. Entretanto, esta viso do
problema no leva em conta na modelagem a existncia de tarefas da aplicao
que se executam seqencialmente. A segunda abordagem consiste em
programar a aplicao a partir de uma decomposio funcional desta. A idia
bsica desta abordagem consiste em considerar que algumas tarefas s podem
ser realizadas aps o trmino de outras; a modelagem da aplicao e sua
conseqente programao leva em conta este fato e s permite o inicio da
execuo das varias tarefas quando necessrio, evitando a espera de eventos
que no tem nenhuma probabilidade de ocorrer.
Abordagem 3: Decomposio por recursos compartilhados

Esta abordagem segue a decomposio funcional como na abordagem anterior,
entretanto ela leva em conta a existncia de recursos comuns e decompe a
aplicao em funo destes. Cada uma das funcionalidades que utilizam um
mesmo recurso corresponde a um mdulo; todos esses mdulos so colocados
em paralelo.
Essas trs abordagens foram comparadas nos trabalhos citados anteriormente do

ponto de vista da complexidade do autmato resultante (i.e. nmero de estados e de
5.3 Consideraes sobre as abordagens usadas 151
transies). Os resultados obtidos mostram diferenas grandes (da ordem de 10 a 20

vezes) entre o nmero de estados e de transies dos autmatos resultantes da
abordagem 1 e das abordagens 2 e 3, apesar de descrever as mesmas funcionalidades. A
arquitetura adotada na abordagem 1 a causa deste aumento no nmero de estados,
pois por causa do paralelismo, os mdulos esperam um grande nmero de sinais
(eventos) de entrada; como parte deles so impossveis de serem recebidos antes de
outros terem sido emitidos, a abordagem 1 cria um grande nmero de estados nunca
atingidos e ento desnecessrios. Por outro lado, as abordagens 2 e 3 implicam em uma
implementao centralizada enquanto a abordagem 1 permite tambm adotar uma
implementao distribuda, com programas separados para cada mdulo-equipamento.
Estas consideraes devem ser levadas em conta quando da programao de sistemas
complexos e fazem parte da metodologia a ser adotada para programar aplicaes
segundo a abordagem sncrona.
5.3 Consideraes sobre as abordagens usadas
Os exemplos apresentados neste captulo mostram que as abordagens assncrona e

sncrona apresentam caractersticas muito diferentes e consequentemente existem
campos de aplicao para as quais cada uma delas mais apropriada. Esta seo
procura destacar estas diferenas, assim como indicar critrios utilizados para
selecionar uma ou outra abordagem frente a uma dada aplicao. Essas abordagens, as
quais visam fornecer solues para o problema de tempo real, devem ser analisadas
tanto do ponto de vista da especificao e verificao quanto da implementao.
A abordagem assncrona considerada como orientada implementao e
consequentemente descreve o sistema da forma a mais completa possvel. Essa
descrio leva em conta a ocorrncia e a percepo de todos os eventos numa ordem
arbitrria mas no simultnea; o comportamento observado corresponde a todas as
combinaes de ocorrncia de eventos ("interleaving"). A abordagem sncrona
considerada como orientada ao comportamento da aplicao e a sua verificao. A
premissa bsica da abordagem sncrona a simultaneidade dos eventos de entrada e
sada, partindo da hiptese que no nvel de abstrao considerado, clculos e
comunicaes no levam tempo. A abordagem sncrona se situa num nvel de abstrao
dos aspectos de implementao tal que essa hiptese seja verdadeira.
Como conseqncia destes princpios e modelos diferentes nas duas abordagens,
leva-se em conta na especificao e no projeto segundo a abordagem assncrona,
caractersticas do suporte de software e de hardware das aplicaes, o que pode
dificultar requisitos de portabilidade. A abordagem sncrona mais distante das
questes de implementao, o que lhe d uma vantagem do ponto de vista da
portabilidade.
A descrio completa do comportamento e a introduo de consideraes de
implementao na abordagem assncrona torna complexa a anlise das propriedades do
sistema por causa do grande nmero de estados gerados e do possvel no determinismo

introduzido. A abordagem sncrona, se situando num nvel de abstrao maior, facilita
a especificao e a verificao das propriedades de sistemas de tempo real. Como
resultado, os sistemas construdos a partir da abordagem sncrona so muito mais
confiveis do que aqueles construdos segundo a abordagem assncrona. A abordagem
sncrona, entretanto por se situar num nvel de abstrao maior do que a abordagem
assncrona pode encontrar dificuldades em algumas situaes do ponto de vista da
implementao da qual est mais afastada, em particular em implementaes que
necessitam ser distribudas.
Na abordagem assncrona, a concorrncia e o tempo esto tratados de forma
explcita, tornando fundamental o estudo da previsibilidade dos sistemas de tempo real
e consequentemente a questo do escalonamento tempo real. As premissas da
abordagem sncrona permitem resolver a concorrncia sem o entrelaamento de tarefas,
no existindo a necessidade de escalonamento. Esta surge quando diferentes atividades
requerem o uso do mesmo recurso (processador, qualquer perifrico ou at mesmo as
estruturas de dados), o qual no pode ser usado simultaneamente pelas vrias
atividades. Na abordagem sncrona, como todas as atividades so instantneas, o
recurso no ocupado, e deixa de ser um problema. Alm do mais, na abordagem
sncrona, o tempo no aparece de maneira explcita.
Na abordagem sncrona, a nica preocupao do projetista da aplicao garantir a
resposta correta aos eventos do ambiente, no sentido lgico. A correo no sentido
temporal est automaticamente garantida pois, como a velocidade de processamento
considerada infinita, o tempo de resposta ser sempre zero. A abordagem assncrona
parte da programao concorrente clssica e procura tratar da questo tempo, alm das
questes de sincronizao entre tarefas. Para isto as polticas de escalonamento so
tornadas explcitas (algo que no acontece na programao concorrente clssica) e os
mecanismos de sincronizao (semforos por exemplo) so dotados de um
comportamento mais apropriado para a anlise de escalonabilidade. Interferncias,
precedncias e bloqueios so considerados no momento de determinar se os "deadlines"
da aplicao sero ou no cumpridos. Um sistema construdo segundo a abordagem
assncrona no precisa ser mais rpido que o ambiente a sua volta. Ele apenas precisa,
usando os recursos de forma inteligente, atender aos requisitos temporais ("deadlines")
expressos na especificao do sistema. Na abordagem sncrona esta anlise de
escalonabilidade usada na abordagem assncrona torna-se trivial e desnecessria, pois
os "deadlines" so muitas ordens de grandeza maiores do que o tempo que o
processador leva para executar as tarefas da aplicao.
O campo de aplicao da abordagem sncrona se limita a situaes de sistemas ou
partes de sistemas nas quais a velocidade do ambiente pode ser considerada como
menor que a do computador, atendendo as exigncias da hiptese de sincronismo.
Nestas situaes, a abordagem sncrona se impe pela sua simplicidade, facilidade de
especificao e potencialidade em verificar o sistema especificado. Esta abordagem no
necessita de um processo de traduo para passar da especificao validada ao
programa a ser executado; ela implementa diretamente a especificao, o que se
5.4 Concluso 153
configura numa grande vantagem por evitar a introduo de erros durante o processo de
traduo. Uma aplicao construda com a abordagem assncrona mais complexa e
mais difcil de verificar e consequentemente mais sujeita a falhas do que a mesma
aplicao na abordagem sncrona. Entretanto, quando o computador no consegue ser
muito mais rpido que o ambiente ou quando no possvel determinar com garantia a
relao de tempo entre o ambiente e o computador (p.ex. o caso da Internet), no
existe escolha e a abordagem assncrona deve ser utilizada. Geralmente nos sistemas
complexos, as duas abordagens podem se tornar necessrias; partes mais reativas do
sistema tais como interfaces homem-mquina, controladores, protocolos de
comunicao e "drivers" de perifricos podem ser tratadas pela abordagem sncrona,
enquanto as partes correspondendo aos clculos, ao manuseio e tratamento de dados e
comportamentos no-deterministas tem que fazer uso da abordagem assncrona.
5.4 Concluso
Este captulo apresentou duas aplicaes de tempo real. A aplicao "veculo com
navegao autnoma" foi implementada atravs da abordagem assncrona, com anlise
de escalonabilidade e emprego de um sistema operacional de tempo real. A aplicao
"sistema de controle" foi implementada atravs da abordagem sncrona, com o emprego
da linguagem Esterel. Finalmente, a seo 5.3 procurou fazer uma comparao entre as
duas abordagens.
Embora a limitao de espao permita apenas uma descrio superficial destas
aplicaes, elas permitem que o leitor tenha contato com o mtodo implcito na adoo
de cada uma das abordagens. A partir destes exemplos, fica mais fcil identificar
situaes onde uma e outra podem ser melhor aplicadas.
Captulo 6
Tendncias Atuais em Sistemas de

Tempo Real
Sistemas de Tempo Real so reconhecidos por possurem problemas bem definidos e

nicos. Um conjunto de tcnicas, mtodos, ferramentas e fundamentao terica
formam uma disciplina necessria na compreenso e na concepo de sistemas de
tempo real. Apesar da evoluo nos ltimos anos, em termos de conceitos e mtodos, os
meios mais convencionais continuam a ser usados na prtica. Alm do aspecto dessas
ferramentas usuais no tratarem com a correo temporal, um outro fato que se pode
considerar o relativo desconhecimento do que seria tempo real. A grande maioria dos
sistemas de tempo real projetada a partir de um entendimento errado que reduz tempo
real, a simplesmente uma questo de melhoria no desempenho.
A literatura de tempo real tem sido prdiga no definio de modelos, metodologias e
suportes que consideram restries temporais. Foi no intuito de melhorar o
conhecimento desta disciplina que nos propomos neste texto a apresentar duas
abordagens para a construo de STRs: a sncrona e a assncrona.
6.1 Abordagem Sncrona
A abordagem sncrona baseada na hiptese sncrona que, em seus princpios

bsicos, considera os processamentos e comunicaes instantneos. O tempo visto
com granularidade suficientemente grossa para que essas premissas sejam aceitas como
verdadeiras. A observao dos eventos nessa abordagem cronolgica.
A abordagem sncrona considerada como orientada ao comportamento de uma
aplicao e sua verificao. Por se situar num nvel de abstrao maior, os aspectos de
implementao so em grande parte desconsiderados, facilitando a especificao e a
anlise das propriedades de sistemas de tempo real. A abordagem sncrona forma uma
base conceitual bastante slida permitindo a definio de conjuntos de ferramentas
integradas prprias para o desenvolvimento de aplicaes de tempo real. Entretanto,
aplicaes complexas que envolvem programas de calculo, grande quantidade de dados
a manusear e distribuio so dificilmente tratveis por completo pela abordagem
sncrona. A abordagem sncrona bem adaptada para sistemas reativos ou partes
reativas de sistemas complexos que so dirigidos pelo ambiente e para os quais o
determinismo no comportamento fortemente desejvel.
156 6. Tendncias Atuais em Sistemas de Tempo Real
Os sistemas reativos para os quais o uso da abordagem sncrona uma soluo

recomendada se encontram nos seguintes campos de aplicao: controle de processo
tempo real, sistemas de manufatura, sistemas de transporte, sistemas embutidos,
sistemas autnomos, sistemas de superviso, protocolos de comunicao, "drivers" de
perifricos, interface homem-mquina, processamento de sinais, entre outros.
Geralmente, as linguagens sncronas no so suficientes para a programao
completa dos sistemas complexos. As partes no reativas tm que ser construdas
usando a abordagem assncrona. As linguagens assncronas devem fornecer mecanismos
para a interao entre as partes reativas e no reativas segundo um modo de
comunicao assncrona. Propostas de formalismos ou de metodologias que fazem uso
de modos de comunicao sncronos e assncronos em conjunto podem ser encontradas
em [SBS93] e [BCJ97].
A distribuio do cdigo em vrios computadores uma caracterstica
indispensvel dos sistemas complexos por uma ou mais das razes seguintes: aumento
da capacidade de clculo, melhoria de desempenho, tolerncia a falhas, localizao
geogrfica dos sensores e atuadores, entre outras. As dificuldades encontradas para
tratar a distribuio na abordagem sncrona provem da necessidade, imposta pela
hiptese de sincronismo, da existncia de um relgio global e, conseqentemente, de
um algoritmo (sncrono) de sincronizao de relgios. A distribuio de cdigo pode
ser feita de trs formas diferentes [CGP99]:
(i) Compilando separadamente cada parte do programa total, e alocando aos

computadores do sistema cada uma destas partes que devem se comunicar.
Apesar de ser uma soluo fcil, nem sempre a compilao em separado gera
programas seqenciais deterministas [Maf93];
(ii) Compilando o programa todo e gerando programas seqenciais para cada

computador, cada programa podendo se comunicar com os outros, segundo o
mtodo de grafo abstrato apresentado em [Maf93];
(iii) Compilando o programa num nico programa objeto e distribuindo-o

posteriormente em tantos programas quanto computadores que realizaro
apenas os clculos que lhes correspondem [CaK88] e [CPG99]. Esta
abordagem tem a vantagem de otimizar a compilao e de permitir a
verificao e depurao do programa antes de distribui-lo.
Maiores detalhes sobre o estado atual das pesquisas sobre distribuio de programas
sncronos podem ser encontradas em [CGP99], [BCL99] e [BeC99].
6.2 Abordagem Assncrona
A abordagem assncrona visa uma descrio a mais exata possvel de um sistema de

6.2 Abordagem Assncrona 157
tempo real e por isto considerada como orientada implementao. Vrios aspectos
referentes a uma aplicao so tratadas explicitamente a nvel de programao e
gerenciadas em tempo de execuo; o tempo e a concorrncia so exemplos deste
conhecimento explicito necessrio a um programador de aplicaes de tempo real nesta
abordagem. Como conseqncia, torna-se necessrio levar em conta j na especificao
e no decorrer do projeto, algumas caractersticas dos suportes de software e de
hardware. Por outro lado, na abordagem assncrona, a procura de uma descrio
completa do comportamento e a introduo de consideraes de implementao torna
complexa a anlise das propriedades do sistema de tempo real.
Num sentido mais clssico, dentro desta tica da abordagem assncrona, uma
fundamentao terica j bem definida para sistemas onde possvel uma
previsibilidade determinista. Uma coleo de algoritmos e tcnicas de analise existem
para problemas envolvendo escalonamentos com garantias em tempo de projeto,
caracterizando o que Stankovic chama de cincia da garantia de desempenho [Sta96].
Os sistemas, neste perspectiva de garantia em tempo de projeto, so de dimenses no
muito extensas, construdos para realizar um conjunto especfico de objetivos e
envolvendo, em termos de implementao, solues ditas proprietrias. Esto dentro
desta cincia da garantia do desempenho as abordagens que tratam com ambientes
dinmicos, ainda limitados, usando tcnicas para obter garantias dinmicas. Estas
abordagens envolvem testes de aceitao baseados em hipteses de pior caso dos
tempos de computao da carga presente no sistema. O estudo apresentado neste texto
de certa maneira cobriu estas tcnicas que formam esta cincia da garantia.
Como os sistemas se tornam cada vez maiores e mais complexos, interagindo com
ambientes tambm complexos e dinmicos e, portanto, no deterministas uma
expanso desta cincia da garantia necessria para captar as caractersticas destes
novos sistemas. As tcnicas existentes, mesmo as de abordagens assncronas que tratam
com garantias dinmicas, no so abrangentes o suficiente para que possam ser eficazes
diante destes novos sistemas.
A evoluo prevista para os prximos anos caracteriza sistemas como sendo
distribudos, de larga escala, oferecendo uma grande variedade de servios que trata
com vrias formas de dados e se apresentam constantemente mudando e evoluindo. Em
contraste, um desafio crescente colocado a comunidade de tempo real como construir
esses sistemas de propsito geral, abertos, que permitam conviver vrias aplicaes
independentes e de tempo real.
Uma perfeita anlise de escalonabilidade a priori impraticvel em um ambiente
destes. necessrio uma nova disciplina, com modelos e abordagens criados no sentido
de captar as complexidades desses novos ambientes que esto se caracterizando
envolvendo novas tecnologias e aplicaes. Esta nova disciplina para aplicaes de
tempo real vai exigir esforos de pesquisa na engenharia de software, em linguagens de
programao, em sistemas operacionais, na teoria de escalonamento e na comunicao.
Sistemas Abertos
A meta principal nesta tendncia o desenvolvimento de arquiteturas, suportes de

middlewares e componentes com interfaces pblicas e bem definidas, que possam ser
desenvolvidos de forma independente, para posteriormente serem combinados e usados
na construo de sistemas complexos. Esta estratgia conduz obteno, alm de
grande flexibilidade, de vantagens como melhor portabilidade, interoperabilidade e
facilidades na evoluo dos sistemas. Estas interfaces favorecem tambm o uso de
componentes/softwares de prateleira (off-the-shelf).
As tecnologias abertas para sistemas distribudos de tempo real so recentes. O RT
CORBA [OMG98] e o ANSAware/RT [Li95] so exemplos destes esforos de
organizaes padronizadoras na definio de padres para componentes de
middleware que suportem aplicaes distribudas de tempo real. E, mesmo para a
automao industrial e sistemas embutidos em geral, esto previstos certos requisitos
para as prximas geraes que envolvem padres abertos [Sta96]: os controladores
(computadores especializados) devem apresentar arquitetura modular que suporte
mudanas em tempos mnimos sem comprometer os requisitos de desempenho de uma
planta industrial; devem suportar facilmente a adio de funcionalidade ou a alterao
no comportamento da aplicao e, tambm, no depender de fabricante ou tecnologias
proprietrias.
A adequao de padres abertos para o desenvolvimento de aplicaes de tempo
real sempre foi vista com uma certa desconfiana por projetistas da rea. A necessidade
de previsibilidade no atendimento das restries temporais, historicamente tem
contribudo para solues proprietrias, especficas para suas aplicaes alvo. Algumas
das dificuldades de uma arquitetura aberta para aplicaes de tempo real em sistemas
distribudos de larga escala incluem:
Caractersticas de hardware desconhecidas at o tempo de execuo

(velocidades de processadores, caches, barramentos , memria variam de
mquina para mquina).
Ambientes onde convivem diferentes aplicaes onde suas necessidades de

recursos e seus requisitos temporais so desconhecidos at o tempo de
execuo.
Linguagens
At recentemente, muito pouco tinha sido feito em termos de linguagens de

programao para sistemas de tempo real. Na prtica corrente, no uso de abordagens
assncronas em muitas aplicaes, as partes crticas das aplicaes eram (ou ainda so)
implementadas em cdigos de mquina ou "Assembly". Isto forava um conhecimento
prvio sobre a arquitetura dos processadores usados no sistema. As implicaes so

muitas no uso desta prtica: os cdigos produzidos no so portveis, e a prpria
modificao ou evoluo do sistema fica comprometida. Todos esses fatores apontam
para a necessidade do uso de linguagens de programao de alto nvel com construes
explcitas que facilitem a descrio do comportamento temporal de uma aplicao de
tempo real.
Em quase todos os modelos de escalonamento citados no captulo 2, assumido o
pior caso nos tempos de computao dos cdigos das tarefas. Os cdigos gerados na
compilao destas linguagens de alto nvel devem ter, portanto, bem determinados os
valores de seus piores tempos de computao. Para a obteno destes tempos
necessrio evitar a utilizao de certas construes de linguagens convencionais e certas
prticas correntes de programao. O uso de estruturas dinmicas deve tambm ser
limitado.
So necessrias ferramentas para preverem o pior caso e o tempo de computao
mdio destes cdigos. A estimao do pior caso pode ser obtida por anlises ou por
medidas. Algumas ferramentas existentes, baseada em anlises do cdigo, so
prottipos acadmicos [Gus94], [Har94]. A dificuldade de mtodos baseados em anlise
a necessidade de um modelo que capte todas as caractersticas da arquitetura do
computador (cache, pipeline, etc). O problema de tcnicas baseadas em medidas
est na dificuldade de se conseguir o pior caso de tempo de computao a partir de um
certo nmero de ativaes sob o qual submetido o cdigo de uma tarefa.
As linguagens de programao em geral so fracas no sentido de suportarem a
implementao das abordagens de escalonamento de tempo real. A falta de
expressividade fica evidente quando o objetivo a generalizao de requisitos
temporais e de estratgias de implementao. improvvel que uma nica linguagem
seja abrangente o suficiente para acomodar todos os requisitos temporais das
abordagens existentes e mais os novos que certamente devero surgir nos prximos
anos. So necessrias novas estruturas de linguagens mais flexveis que permitam a
especializao diante dos diferentes tipos de aplicaes de tempo real. A Reflexo
Computacional, atravs dos protocolos Meta-Objeto ([Mae87], [TaT92]), e a
Programao Orientada a Aspectos [Kic97] so exemplos de novas tcnicas e
mecanismos de programao que so incentivadas porque trazem esta flexibilidade
necessria na programao em tempo real. Ambas tcnicas enfatizam a separao das
funcionalidades de uma aplicao de seu gerenciamento.
Recentemente, o grande sucesso da linguagem Java no contexto da Internet e mesmo
fora dela, atraiu a ateno das pessoas que desenvolvem software de tempo real. Na sua
forma original Java no apropriada para tempo real devido s diversas fontes de no
determinismo presentes. O exemplo clssico o seu coletor de lixo, o qual pode
executar a qualquer momento e ocupar o processador por um tempo no desprezvel,
sempre que o suporte ficar sem memria para instanciar novos objetos. Existem dois
fortes consrcios definindo uma verso de Java para tempo real (Real-Time Java,
[Ort99]). Embora neste momento no esteja claro qual ser o consrcio vencedor, o fato
das maiores empresas de computao do mundo participarem deles um sinal de que
Java poder ser usada no futuro tambm para sistemas de tempo real.
Sistemas Operacionais
O mercado de sistemas operacionais de tempo real est passando por uma fase de
rpidas mudanas. A teoria de escalonamento de tempo real, ignorada at alguns anos
atrs, comea a ser incorporada aos sistemas operacionais. Desta forma, pode-se esperar
para os prximos anos suportes de execuo cada vez mais previsveis. Ao mesmo
tempo, Posix firmou-se como a interface padro nesta rea. Embora o prprio Posix
seja grande e por vezes ambguo, ele estabelece um padro para as chamadas de sistema
a serem oferecidas para aplicaes de tempo real.
Variaes do Linux para tempo real esto surgindo com fora neste mercado. Como
o captulo 3 mostrou, muitos grupos de pesquisa em todo o mundo esto trabalhando no
sentido de criar verses do Linux apropriadas para aplicaes de tempo real. Enquanto
alguns trabalhos nesta rea buscam uma previsibilidade rigorosa para atender sistemas
crticos, outros procuram melhorar o desempenho do escalonamento para melhor
suportar aplicaes com requisitos temporais brandos. No possvel ignorar que a
disponibilidade de um sistema operacional Unix completo, com fonte aberto e adaptado
para tempo real, vai causar um grande impacto no mercado. Por exemplo, no momento
em que este livro escrito, anunciado que o QNX ser fornecido sem custo para
aplicaes no comerciais (http://get.qnx.com).
Com respeito aos sistemas distribudos, ainda existe um longo caminho a ser
percorrido. Embora RT-CORBA padronize interfaces e crie uma estrutura conceitual
baseada em objetos, sua implementao depende dos servios de escalonamento e
comunicao tempo real fornecidos pelo sistema operacional e protocolos de
comunicao subjacentes. A medida que a qualidade destes servios aumentar,
implementaes do RT-CORBA tambm apresentaro melhor qualidade com respeito a
previsibilidade temporal.
Apesar de todos estes esforos, a verdade que o mercado de sistemas operacionais
de tempo real continuar segmentado ainda por muitos anos. Com aplicaes to
diversas quanto uma teleconferncia e o controle de um motor eltrico apresentando
restries temporais, obviamente existe espao para um grande conjunto de solues.
Estas incluem desde sistemas operacionais completos, adaptados para fornecer
escalonamento do tipo melhor esforo, at ncleos totalmente previsveis, capazes de
garantir "deadlines" em aplicaes crticas.
Escalonamento de Tempo Real
A evoluo prevista com novos ambientes de larga escala e novas aplicaes

preconiza o surgimento de novas abordagens com algoritmos e testes de escalonamento
que possam tratar com estruturas complexas de tarefas e de recursos, definindo escalas
que atendam granularidades variveis de restries temporais [Sta96]. As tcnicas de
escalonamento devem ser robustas ou ainda, flexveis e adaptativas quando necessrio.
Existe uma necessidade de testes e algoritmos mais robustos. Na chamada cincia
da garantia testes e algoritmos, definidos segundo certas premissas, so vlidos para
determinados modelos de tarefas. Quando aplicados em um sistema, a atuao de um
algoritmo tida como correta se todas as premissas assumidas no modelo so vlidas.
Se algumas dessas premissas no so verificadas e mesmo assim as propriedades do
algoritmo se mantm corretas, as restries de tempo real da aplicao so atendidas e o
algoritmo dito robusto. O uso de um algoritmo robusto reduz, significativamente, a
necessidade da caracterizao da aplicao e de seu ambiente de execuo nos esforos
de anlises e medidas para a validao do conjunto de tarefas que formam a sua carga
[Sta96]. A eficincia e a robustez podem ser concretizadas facilmente se o grau de
sucesso da validao no o objetivo maior. Testes de aceitao (ou testes de
escalonabilidade), por serem excessivamente pessimistas, apresentam um baixo grau de
sucesso nestes novos e complexos ambientes.
As abordagens de escalonamento adaptativo (adaptive scheduling) tm sido
propostas no sentido de se adotar modelos mais flexveis. Essas abordagens assumem
que as condies do sistema so monitoradas, e as decises do escalonamento so
baseadas nas condies observadas [LSL94]. Modelos e abordagens de escalonamento
adaptativos so empregados com objetivo de lidar com a incerteza na carga do sistema e
a obteno de uma degradao suave [CLL90], [GNM97], [MFO99], [TaT93].
Degradao suave em sistemas de tempo real, significa a manuteno das propriedades
de previsibilidade na sobrecarga.
De forma diversa s abordagens mais clssicas, algumas abordagens adaptativas no
necessitam o conhecimento a priori dos piores casos de tempo de computao das
tarefas. A determinao destes tempos das tarefas, necessrios em abordagens mais
clssicas, sempre um trabalho rduo.
Diversas tcnicas adaptativas tm sido propostas recentemente. Por exemplo, uma
tcnica de adaptao pode ser baseada no ajuste dos perodos de tarefas peridicas em
tempo de execuo. A adaptao dos perodos de tarefas pode ser usada em alguns
sistemas de controle realimentados ou tambm, atravs da mudana da freqncia de
apresentao de quadros, em uma aplicao de vdeo sob demanda [KuM97]. A
computao imprecisa [LSL94] uma outra tcnica que permite a combinao de
garantia determinista com degradao suave usada para o tratamento de
sobrecargas. Nessa tcnica, cada tarefa decomposta em duas partes: uma parte
obrigatria e uma parte opcional. A parte obrigatria de uma tarefa deve ser completada
antes do deadline da tarefa para produzir um resultado aproximado com uma qualidade
aceitvel. A parte opcional refina o resultado produzido pela parte obrigatria. Durante
uma sobrecarga, um nvel mnimo de operao do sistema pode ser garantido de
forma determinista, atravs da execuo apenas das partes obrigatrias.
Em [HaR95], foi proposto o conceito de deadline (m,k)-firm, definindo que uma
tarefa peridica deve ter pelo menos m "deadlines" atendidos em cada janela de k
ativaes. O limite superior tolerado de perdas de "deadlines" dado por k-m. Uma
falha dinmica assumida no sistema quando esse limite excedido. O DBP (Distance
Based Priority Assignment) a heurstica de escalonamento usada com essa tcnica no
sentido de minimizar o nmero de falhas dinmicas. Essa heurstica de escalonamento
atribui as mais altas prioridades para as tarefas que esto prximas de exceder o limite
superior especificado para as perdas de "deadlines". Outras tcnicas semelhantes
deadline (m,k)-firm foram introduzidas na literatura [KoS95], [CaB97] e [BeB97].
Todas se utilizam do descarte de certas ativaes de tarefas peridicas para aumentar a
escalonabilidade do sistema.
Comunicao
Se considerarmos os sistemas de tempo real distribudos, a comunicao

desempenha um papel importantssimo nos tempos de resposta que envolve uma
aplicao nestes sistemas. Os objetivos de protocolos de comunicao em sistemas de
tempo real so diferentes dos sistemas que no so de tempo real. Em sistemas mais
convencionais, no tempo real, o aumento do desempenho na forma de taxas de
transferncias o ponto chave. Por outro lado, na comunicao em sistemas de tempo
real o que se procura a obteno de altas probabilidades que uma mensagem ser
entregue dentro de um deadline especfico ou atendendo uma latncia mxima.
Em sistemas crticos (hard real-time systems) e, portanto na tica da cincia da
garantia, os protocolos de comunicao para tempo real devem apresentar um limite
mximo na latncia de uma mensagem durante uma comunicao. Em sistemas mais
brandos, tais como multimdia e videoconferncia, onde dados de diferentes naturezas
esto sendo transmitidos, evidente a necessidade da entrega de mensagens segundo
certas restries temporais. Ocasionais falhas em atender estas restries temporais
perfeitamente admissvel; porm, atrasos ou perdas de mensagens excessivos degradam
a qualidade do servio fornecido a nvel da aplicao.
So duas as abordagens usadas para tratar comunicaes em sistemas de tempo real.
A primeira baseada sobre a utilizao do conhecimento sobre a mxima latncia nas
transferncias de mensagens no sistema [ARS91]. As anlises e escalas produzidas para
o sistema consideram ento este pior tempo de comunicao. Na segunda abordagem as
mensagens esto sujeitas elas prprias a restries temporais ("deadlines", perodos,
etc) e escalonadores atuam, segundo polticas de tempo real, em filas de emisso
levando em conta estas restries [ZhB94].
Sistemas de larga escala com diferentes tipos de aplicaes, implicam na
necessidade do suporte a vrios tipos de comunicao, sujeitas a diferentes necessidades
de garantias e de restries de tempo. Novas tecnologias de comunicao esto surgindo
para suprir essas necessidades. Exemplo destas tecnologias so as redes baseadas no
protocolo IP, que inicialmente foram concebidas no sentido das tcnicas de melhor
esforo e que esto sendo estendidas para implementar diferentes Qualidades de Servio
(QoS). Redes ATM tambm suportam diferentes classes de servio. Alm de servios
de melhor esforo estas tecnologias oferecem classes de servios garantidos que, com
reservas de recursos, fornecem servios garantidos fim-a-fim com o controle rgido da
largura de banda e do retardo [SPG97]. Com base nestas tecnologias novos modelos de
comunicao de tempo real devero surgir, possibilitando a associao de parmetros
de QoS relacionados com tempo real a um canal de comunicao.
Metodologias
Atualmente, a complexidade dos sistemas computacionais exige cada vez mais o uso
de metodologias para especificar, analisar, projetar e implementar. Os sistemas de
tempo real em particular quando distribudos, apresentam caractersticas que se
encaixam nesta categoria. As metodologias de propsito geral, normalmente utilizadas
na comunidade acadmica e no setor industrial e de servios, tem apresentado
inconvenientes. As razes esto na inadequao da linguagem de modelagem que no
inclui o conjunto especifico de requisitos necessrios para representar os sistemas
tempo real e, as dificuldades de implementao que no facilitam a ligao entre os
conceitos usados numa modelagem de alto nvel de abstrao e os conceitos usados na
implementao. Metodologias para sistemas de tempo real e que ao mesmo tempo
acrescentam as potencialidades da orientao objeto tm sido propostas para remediar
este problema e diminuir as dificuldades na construo destes sistemas. Destacam-se
entre estas linguagens de modelagem e metodologias para tempo real a ROOM (Real-
Time Object-Oriented Modeling) [SGW94] e a UML-RT (Unified Modeling
Language for Real-Time) [SeR98]. Essas metodologias apresentam as seguintes
caractersticas: seguir o paradigma de orientao-objeto; permitir a modelagem e a
construo de software tempo real; fornecer modelos executveis em todos os nveis de
abstrao; permitir um processo de desenvolvimento incremental e iterativo; e facilitar a
documentao.
Neste mesmo contexto, tcnicas de descrio formal tem sido adotadas num nmero
crescente de aplicaes, devido aos benefcios significativos que o rigor de seus
formalismos traz para a produo de software de qualidade, sobretudo quando esta
qualidade se expressa em termos de consistncia, segurana e correo temporal.
Muitas pesquisas e desenvolvimentos de ferramentas vem sendo realizadas neste campo
nos ltimos anos. Esta rea muito ampla e promissora e sai do escopo deste livro; os
interessados podem procurar, na ampla bibliografia disponvel da rea, as referncias
[HeM96], [BCN95] e [Rus93] que destacamos por apresentarem uma viso geral das
tcnicas de descrio formal prprias para sistemas tempo real.
ANEXO A
Extenses em Esquemas de Prioridade

Dinmica
A.1 Testes para Escalonamentos com Prioridades

Dinmicas
A anlise de escalonabilidade do EDF baseada no conceito de utilizao, embora

corresponda a um teste exato, limitada na sua aplicao pela simplicidade do modelo
de tarefas de sua definio. Os testes que se seguem apresentam como finalidade a
extenso do uso do EDF para modelos mais complexos.
A.1.1 Deadline igual ao perodo
Quando considerados uma poltica baseada em deadlines e um conjunto de tarefas

peridicas com deadlines relativos iguais aos seus respectivos perodos, qualquer
anlise em uma janela de tempo deve levar em conta a carga computacional
representada pelas ativaes dessas tarefas que devem ser executadas dentro dessa
janela. Ou seja, essa carga corresponde s ocorrncias de tarefas que apresentam
deadlines absolutos menores ou iguais ao limite superior desse intervalo de tempo. Por
exemplo, a necessidade de processador que uma tarefa Ti possui em um intervalo [t,t+l]
para que suas ativaes completem antes ou em t+l dado por l/PiCi.
Para um conjunto de n tarefas peridicas, as instncias liberadas e que completam
no intervalo [0, t] correspondem demanda de processador C(t) fornecido por:
n
t
C (t) = Ci.
P i t Pi
A escalonabilidade de um conjunto de tarefas executadas sob o EDF (poltica

dirigida a deadlines), garantida se e somente se, em qualquer intervalo [0, t], a
demanda de processador (C(t)) das instncias que devem se completar nesse intervalo
menor ou igual ao tempo disponvel t [JeS93]:
166 Anexo A Extenses em Esquemas de Prioridade Dinmica
t
t P C i. [A 1 ]
Pi t i
Para aplicar o teste [A1], a inspeo de valores de t pode ser limitada aos tempos de
liberao das tarefas dentro do hiperperodo H do conjunto de tarefas considerado1.
Mas isto ainda pode representar um grande nmero de valores de t a serem verificados.
O conceito de "busy period" pode ser til na determinao de um conjunto mais
reduzido de valores de t. Retomando ento um perodo ocupado como um intervalo de
tempo com execues contnuas de tarefas e considerando o instante crtico em t=0, o
pior caso de execuo de uma tarefa Ti ocorre no primeiro i-busy period que inicia na
origem (t=0) e termina com a execuo da instncia considerada. A idia que o
completion time de uma instncia de Ti com deadline d deva estar no fim do i-busy
period no qual se executaro instncias de outras tarefas que tenham deadlines menores
ou iguais a d.
O intervalo de tempo L que ocorre entre t=0 e o primeiro "idle time" do
processador, assumido como o maior "busy period" no sistema. O valor de L obtido
a partir de [Spu96]:
n
L( 0 ) = C i ,
i=1 [A2]
L ( m + 1 ) = W ( L ( m ) ) ,
onde W(t) corresponde a carga cumulativa no intervalo [0, t], ou seja a soma dos
tempos de computao de todas as instncias que chegaram antes do tempo t :
n
t
W (t ) = P Ci . [ A 3]
i=1 i
Quando L(m+1) = L(m) os clculos em [A2] esto terminados2.
Os valores de t que devem servir na inspeo de [A1] so dados ento por t ,

onde:
1
hiperperodo de um conjunto de tarefas peridicas corresponde ao mnimo mltiplo comum
dos perodos das tarefas do conjunto.
2
L(m) converge para L em um nmero finito de iteraes se [Spu96]:
n
Ci
1.
167
{
= dik dik = kTi dik min( L, H ), 1 i n, k 1 . } [ A4]
Um modelo mais realista onde ocorrem "jitters", determina que uma tarefa Ti seja
retida depois de sua chegada at um tempo mximo Ji para a sua liberao. As equaes
acima devem ser modificadas no sentido de expressar esses tempos. O efeito de "jitters"
no pior caso pode provocar em [0, t] a interferncia de instncias que em situaes
normais teriam suas liberaes fora desse intervalo. Com isto, a carga cumulativa W(t)
correspondente ao intervalo [0,t] (carga que ocorre em [0, t]) deve, no pior caso,
aumentar [Spu96]:
n
t + Ji
W (t ) = P Ci .
i=1 i
No mesmo sentido, a demanda de processador C(t) (carga com deadlines menor ou

igual a t, ou seja, concluda em [0,t]) passa a ser fornecida por:
t + Ji
C (t ) = P Ci .
Pi t + J i i
A equao [A1] modificada igualmente:
t + Ji
t Ci.
Pi t + J i Pi
Os valores de t continuam sendo definidos pelo conjunto de [A4].
A.1.2 Deadlines Arbitrrios
Ao considerarmos um conjunto de tarefas peridicas com deadlines relativos (Di)

arbitrrios e escalonadas segundo o EDF, o teste anterior deixa de ser suficiente. O
teste definido pelas condies [A1] e [A4] pode ser facilmente estendido para tratar
tarefas com deadlines arbitrrios [Spu96].
A carga de trabalho acumulada em [0, t] deve levar em considerao esses deadlines
arbitrrios. Considerando t - Di o instante de liberao da ltima instncia de Ti com
garantia de execuo em [0, t], a demanda de processador C(t) proposto por esse
conjunto de tarefas dada por :
t Di
C (t ) = 1 +
Di t
Ci . [ A 5]
Pi
Com isto uma condio necessria e suficiente para tarefas peridicas possuindo
deadlines arbitrrios e escalonadas pelo EDF, obtida atravs de:
t Di
t 1 +
Di t
Ci [A 6 ]
Pi
e {
= dik dik = kTi + Di , dik min( L, H), 1 i n, k 0 , } [ A7]
onde t assume valores de para a inspeo da condio do teste. A ocorrncia de

"jitter" no modelo redefine as equaes [A5] e [A6] [Spu96]:
t + J i Di
C (t ) = 1 + Ci [ A8]
Di t + J i Pi
t + Ji Di
t 1 +

Ci [A 9 ]
Di t + Ji Pi
ta r e fa A 2 10 6
ta r e fa B 2 10 8
ta r e fa C 8 20 16
T a b ela I: E x e m p lo d a fig u r a 2 .7 (ca p tu lo 2 )
Para ilustrar esse teste para modelos de tarefas com deadlines arbitrrios em
esquemas de prioridade dinmica, considere o conjunto de tarefas descrito na tabela I.
Usando a equao [A5] podemos determinar para essas tarefas a demanda de
processador C(t):
t 6 t 8 t 16
C (t ) = 1 + .2 + 1 + .2 + 1 + .8
10 10 20
Falta obtermos o valor t a ser usado no teste [A6]. Para isto, a carga cumulativa
(tarefas que chegam antes e em t) necessria:
169
t t t
W ( t ) = .2 + .2 + .8 .
10 10 20
Aplicando [A2] no sentido de determinar L (o maior "busy period") :
L(0) = C i = 12
L (1)
= W (L (0)
) = 16
L (2)
= W (L ( 1)
) = 16
Logo L=16, com isto obtemos o conjunto dos valores possveis de t [A7]:
{
= d ik d ik 1 6 }
Considerando as tarefas da tabela I e a figura 2.7 (captulo 2) verificamos que =
{6, 8, 16}. Com isto obtemos as seguintes demandas de processador: C(6) = 2, C(8) =
6 e C(16) = 16. Em todos esses valores de t verificado o teste [A6], ou seja, t C(t).
Logo o conjunto apresentado na tabela I e figura 2.7 escalonvel tambm em
esquemas de prioridade dinmica.
A.2 Compartilhamento de Recursos em Polticas de

Prioridade Dinmica
A tcnica chamada de Stack Resource Policy (SRP) foi introduzida em [Bak91] para
controlar em polticas de prioridade dinmica, o compartilhamento de recursos de uma
forma previsvel. Basicamente, esse mtodo estende os resultados do "Priority Ceiling
Protocol" para esquemas de prioridade dinmica. Ou seja, as inverses de prioridades
se limitam a um bloqueio por ativao da tarefa.
A.2.1 Poltica de Pilha (Stack Resource Policy)
O SRP similar ao IPCP na caracterstica de que uma tarefa bloqueada s no

instante em que tenta a preempo. Esse bloqueio antecipado diferente do PCP onde
uma tarefa s bloqueada quando tenta entrar em uma seo crtica reduz a
necessidade de trocas de contextos de tarefas, simplificando a implementao do
protocolo.
Em escalonamentos dirigidos por prioridades dinmicas, a prioridade pi de uma

tarefa Ti indica a sua urgncia em um determinado instante t. Quando usada a atribuio
EDF, a prioridade pi para refletir a urgncia de Ti no instante t, funo direta ou
assume o valor do deadline absoluto di desta tarefa. Alm da prioridade pi, quando
usado o SRP, a tarefa Ti deve apresentar um nvel de preempo i que um parmetro
esttico. Os nveis de preempo estabelecem regras para preempes de tarefas: uma
tarefa Tj s poder ser interrompida por uma tarefa Ti se (i > j) (pi > pj). A utilidade
dos nveis de preempo que, por serem estticos, esses parmetros permitem a
preveno de bloqueios em esquemas de prioridades dinmicas.
No escalonamento EDF, usando o SRP, os valores de so definidos na ordem
inversa dos deadlines relativos. Supondo as tarefas Ti e Tj ilustradas com dois casos de
chegada na figura A.1. tirado desta figura que i maior que j pois Di < Dj. No caso
(a) da figura, a tarefa Ti que chega em t2 consegue a preempo porque i>j (Di<Dj) e
pi>pj (di<dj). No caso (b) da figura A.1 a preempo no ocorre por que uma das duas
condies necessrias no se verifica: Ti que chega em t2 no possui prioridade maior
que Tj (di>dj).
Dj
Di
t1 t2 di dj
t
c a s o (a )
Dj
Di
t1 t2 dj di
t
c a s o (b )
F ig u ra A .1 : N v e is d e P re e m p o n o E D F
Cada recurso compartilhado possui um valor mximo de unidades de recurso para

alocao (max nr). O SRP tambm, a exemplo do PCP, atribui a cada recurso
compartilhado uma prioridade teto ( Rr ). A diferena que, neste caso, este
parmetro dinmico: o "ceiling" corrente de Rr tem o valor determinado a partir do
nmero de unidades de alocao disponveis no recurso Rr. Se nr representa o nmero
de unidades de Rr disponveis em um dado instante e, r,i corresponde as necessidades
de uma tarefa Ti em termos do recurso Rr ento o ceiling dado por:
R r ( n r ) = m ax [{0 } { i n r < r ,i }].

Na expresso acima, quando todas as unidades de Rr esto disponveis, o valor
171
corrente de "ceiling" de Rr mnimo ( Rr = 0). Se as unidades de alocao de Rr no

so suficientes para que algumas tarefas se executem, ento o valor do "ceiling"
assumir o mais alto nvel de preempo dentre estas tarefas ( Rr = j). O "ceiling" do
sistema () assumido como o mximo "ceiling" entre todos os m recursos
compartilhados no sistema:
= m ax ( R r )
r = 1, 2 , ... , m .
No SRP a regra que garante a no ocorrncia de mltiplas inverses de prioridade

determina que uma tarefa Ti no pode se executar at que os recursos necessrios para a
sua execuo estejam disponveis, ou seja, i > . De uma maneira geral, uma tarefa Ti
pode preemptar uma tarefa Tj em execuo quando: (i) for a tarefa mais prioritria
(pi>pj); (ii) o seu nvel de preempo for maior do que a tarefa se executando (i > j); e
por fim, (iii) se o seu nvel de preempo for superior ao "ceiling" do sistema (i > ).
Esse mtodo impe que, quando da ativao de uma tarefa Ti, fique disponvel as
informaes de suas necessidades em recursos (ou seja, os seus valores de r,i para cada
recurso Rr) de modo a se determinar previamente os valores de "ceiling" de cada
recurso Rr em diferentes situaes de alocao. Quando as condies (i), (ii) e (iii) so
verificadas, a tarefa Ti tem satisfeita as suas necessidades em recursos disponveis e
poder, portanto, iniciar sua execuo sem ser bloqueada por tarefas menos prioritrias.
Muito embora, os recursos s venham a ser alocados quando requisitados durante a
execuo de Ti.
A figura A.2 e suas tabelas apresentam uma aplicao do "Stack Resource Policy".
Os parmetros das tarefas T1, T2 e T3 e suas necessidades de recursos so descritos nas
tabelas (r,i). Os recursos R1, R2 e R3 so mostrados com suas mximas unidades para
alocao (max nr). Os "ceilings" so determinados em tabela a partir das unidades de
alocao disponveis nos recursos.
Uma escala obtida sob o SRP descrita na figura A.2. Em t=2, a tarefa menos
prioritria T3 comea a executar porque possui seu nvel de preempo maior que o
"ceiling" do sistema ( = 0). T3 entra na sua primeira seo crtica em t =3 e ocupa
uma unidade do recurso R3. Com isto o "ceiling" do sistema passa ao valor de 2,
porque T2 no consegue ter suas necessidades atendidas (3,2 = 2). Logo, em t = 4, T2
bloqueada pelo teste de preempo e no consegue executar. A tarefa T3 continua a sua
execuo e em t = 4 entra em sua seo crtica aninhada ocupando uma unidade de R2.
Com esta nova seo de T3, a execuo de T1 postergada em t=5 pela no
disponibilidade de suas necessidades no recurso R2 (2,1 = 3). Como conseqncia, o
"ceiling" do sistema cresce para 1. Quando T3 libera o recurso R2, o "ceiling" do
sistema torna se 2 o que permite que T1 interrompa T3. T1 executada completamente
porque seu nvel de preempo maior que o "ceiling" do sistema. Com a concluso de
T1, T3 reassume e quando libera o recurso R3 em t=15, o "ceiling" do sistema baixa para
= 0 e a tarefa T2 pode interromper T3.
Rr Max nr r,1 r,2 r,3 Rr (3) Rr (2) R r (1) R r (0)

R1 1 1 1 - - - 0 1
R2 3 3 - 1 0 1 1 1
R3 2 - 2 1 - 0 2 2
T1 T2 T3 Prioridades : p1 > p2 > p3

.... .... ....
pedido (R 1,1) pedido (R 3,2) pedido (R 3,1) Nveis de preempo : 1 > 2 > 3 (D 1 < D 2 < D 3)
libera (R 1) libera (R 3) pedido (R 2,1)
pedido (R 2,3) pedido (R 1,1) libera (R 2)
libera (R 2) libera (R 1) libera (R 3)
.... .... ....
Semforos : S1 - S2 - S3 -
T1
T2
T3
0 2 4 6 8 10 12 14 16 18 20 22

t
1
0 2 4 6 8 10 12 14 16 18 20 22
Figura A.2 : Exemplo de escala com o SRP
Extenses de Testes de Escalonabilidade Tomando como Base o SRP
O SRP foi concebido para ser usado com polticas de prioridades dinmicas como o
EDF. Em [Bak91], o teste de escalonabilidade do EDF (equao [3], captulo 2) foi
estendido considerando o SRP:
i
Cj Bi

j =1 Pj
+
Pi
1, i ,1 i n .
173
O somatrio da equao acima representa a utilizao de Ti e de todas as tarefas Tj

que possuam nvel de preempo maior que o seu (j >i). Esta condio considera o
instante crtico na origem o que implica nas tarefas ordenadas segundo valores
decrescentes de seus nveis de preempo, ou seja, no sentido crescente de seus
deadlines relativos. O termo Bi/Pi corresponde a utilizao perdida com bloqueio por
tarefa de nvel de preempo menor que i.
Quando assumido deadlines relativos menores que os correspondentes perodos no
modelo de tarefas, o teste proposto por Baker toma a seguinte forma:
i C Bi
+ 1, i,1 i n.
j
j =1 D j Di
Os testes acima, conseguidos a partir de extenses de [3] (captulo 2), dependem

apenas de parmetros estticos e portanto, podem ser verificados em tempo de projeto.
Outros testes mais precisos e gerais para polticas de prioridade dinmica,
apresentados neste Anexo, devem tambm ser modificado para expressar os bloqueios
que tarefas podem sofrer de tarefas menos prioritrias. o caso dos testes baseados em
demanda de processador [Spu96], onde tarefas com deadlines relativos arbitrrios e
sofrendo de release "jitters", quando compartilham recursos sob o SRP, podem ter suas
escalonabilidades verificadas a partir de:
t + J j Dj t + J i Di
t 1 +
C j + 1 +

Bi i, 1 i n
D j t + J j Pj Pi
onde t definido em (conjunto [A.7] indicado no item A.1.2.):
{
= d ik d ik = kTi + Di , d ik min ( L , H ), k 0 . }
No teste acima o somatrio determina a demanda de carga de tarefas de nvel de
prioridade maior ou igual a i, ou seja, tarefas que apresentem Dj - Jj Di - Ji. O termo
que envolve Bi corresponde ao pior caso de bloqueio imposto sobre Ti, durante o
intervalo t, por tarefas de menor nvel de preempo.
O mximo bloqueio Bi que uma tarefa Ti pode experimentar em uma ativao, deve
corresponder a durao da maior seo crtica entre as que podem bloquear Ti. A
exemplo do PCP, um bloqueio s pode ser caracterizado quando uma tarefa Tj menos
prioritria executando em uma seo crtica de durao Dj,r, guardada pelo semforo Sr,
tiver o seu nvel de preempo menor que o de Ti (i>j) e o recurso guardado
apresentar o "ceiling" mximo igual ou maior que i. O "ceiling" mximo de um
semforo assumido quando o nmero de unidades livres do recurso for nulo. O
bloqueio mximo dado ento por:

Bi = m ax D j , r
j ,r
( j )

< i R S r
(0)

i

A.3 Escalonamento de tarefas aperidicas com polticas de

prioridade dinmica
O escalonamento de tarefas aperidicas e peridicas pode tambm ser feito sob

atribuies dinmica de prioridades. As tarefas peridicas neste caso so escalonadas
usando o algoritmo "Earliest Deadline First" (EDF). A justificativa encontrada para a
extenso do EDF de modo a permitir esquemas hbridos de escalonamento
fundamentada nos maiores limites de escalonabilidade desta poltica se comparada com
as de prioridade fixa. Em [Spu96] a ttulo de exemplo apresentada uma carga
peridica com utilizao Up=0,6. Se a atribuio de prioridades feita pelo RM e o
servidor de prioridade fixa usado o SS, a mxima Utilizao do servidor dada por
US=0,1. Se o EDF usado a utilizao do processador vai para 100% e a mxima
utilizao do servidor acaba sendo de US=0,4.
A.3.1 Servidores de Prioridade Dinmica [SpB96]
Dentre as muitas abordagens introduzidas em [SpB96] para servidores de prioridade

dinmica ("Dynamic Priority Exchange", "Dynamic Sporadic Server", "Improved
Priority Exchange", etc.), uma grande parte extenso dos servidores de prioridade fixa
apresentados no item 2.8 (captulo 2). Neste item, no sentido de evitar textos
repetitivos, apresentado como uma ilustrao destes servidores o "Dynamic Sporadic
Server" (DSS); os leitores que quiserem um estudo mais exaustivo sobre o assunto
devem recorrer a [SpB96].
Servidor Espordico Dinmico
O "Dynamic Sporadic Server" (DSS) estende o algoritmo do SS para atuar com

polticas de prioridade dinmica mais precisamente, o EDF. Esta abordagem hbrida
abre espao para execues aperidicas em escalas ordenadas pelo EDF tambm
usando o conceito de servidor: uma tarefa servidora ento criada com capacidade CS e
perodo PS. A servidora DSS preserva a sua capacidade enquanto no ocorrem
requisies aperidicas. Como a sua homnima de prioridade fixa a capacidade
consumida no preenchida no incio do perodo da servidora DSS, mas no tempo de
preenchimento RT correspondente.
175
A prioridade e o preenchimento da capacidade da servidora DSS so determinados

pelas seguintes aes [SpB96, But97]:
Quando a servidora criada, a sua capacidade CS iniciada no seu mximo
valor.
O tempo de preenchimento e o deadline dS da tarefa servidora so
determinados quando temos CS > 0 e existe uma requisio aperidica
pendente. Se ta o instante de tempo em que se verificam estas condies,
ento RT = dS = ta + PS.
A quantidade de capacidade a ser preenchida em RT obtida quando a ltima
requisio aperidica completada ou a capacidade CS da servidora
totalmente consumida. Se no tempo tf ocorre uma dessas duas situaes, ento
a quantidade de capacidade a ser preenchida igual a capacidade consumida
em [ta, tf].
A limitao imposta pela servidora DSS sobre a utilizao da carga peridica do
sistema provado em [Spu96] como idntica a de uma tarefa peridica de perodo PS e
tempo de computao CS, ou seja: Up 1- US.
A figura A.3 ilustra um exemplo de uso da tcnica DSS que o mesmo utilizado
quando da apresentao do servidor SS de prioridade fixa (seo 2.8.1). O conjunto de
tarefas descrito na tabela da figura para ser escalonado segundo uma atribuio EDF
(dinmica). a tarefa servidora DSS tambm definida com capacidade CS=2,5 e
perodo PS = 10.
ta r e fa A -
ta r e fa s Ci Pi Di
ta r e fa B - ta r e fa p e r id ic a A 1 5 5
ta r e fa C - ta r e fa p e r id ic a B 6 14 14
ta r e fa s er vid o r a D S S 2 ,5 10 -
ta r e fa D -
ta r e fa a p e r id ic a C 1 - -
C D ta r e fa a p e r iod ic a D 1 - -
A B A A B A A
0 1 2 4 5 6 8 10 12 14 16 18 20 22 24
t
C D SS
3
2
1
0 2 4 6 8 10 12 14 16 18 20
F ig u ra A .3 : A lg o rt m o D yn a m ic S p o ra d ic S e r v e r
Em t = 0, a tarefa A, na sua primeira ativao apresentando deadline absoluto mais

prximo (dA,1= 5), assume o processador. Na seqncia, quando A conclui, a tarefa
peridica B com deadline em t = 14 passa a ser executada. Em t = 4,5, com a chegada
de uma requisio C a servidora DSS liberada com o deadline absoluto em t = 14,5

(dS =RT = ta + PS). No caso, ta coincide com o tempo de chegada da requisio C
porque CS > 0 em t = 4,5. Embora a capacidade da servidora seja suficiente, a tarefa B
no interrompida porque esta ltima possui o deadline mais prximo (dB,1=14). A
tarefa A, por sua vez, interrompe B em t = 5, durante sua segunda ativao (dA,2= 10).
Em seguida, no trmino de A, a tarefa B reassume concluindo em t=8. No instante t=8,
a servidora DSS comea a executar a tarefa C com o deadline absoluto em t=14,5. Em
t=8, chega tambm uma requisio D que executada em seguida pela tarefa servidora
com o mesmo deadline (RT=14,5). Isto ocorre porque, quando liberado, o servidor DSS
deve executar todas as requisies aperidicas pendentes enquanto a condio CS > 0
for mantida. Se compararmos a escala obtida na figura A.3 com a escala do servidor
espordico esttico, para o mesmo conjunto de tarefas (figura 2.17, captulo 2, seo
2.8.1), verificamos que o DSS apresenta um desempenho inferior ao seu similar
esttico. Em termos de resposta imediata o DSS tambm pior.
A figura A.4 mostra o mesmo conjunto de tarefas mas com a servidora DSS
projetada com capacidade CS=1. Neste caso, a tarefa aperidica C consome toda a
capacidade da servidora em sua execuo que inicia em t=8. A tarefa D ter a condio
de CS > 0 somente em t=14,5, portanto com um ta diferente de seu tempo de chegada.
Com isto o deadline da tarefa D passa a ser em t=24,5 e a sua execuo sob o EDF
ocorre em t=14,5, interrompendo a tarefa B na sua segunda ativao (dB,2=28). A tarefa
A, por sua vez, interrompe a requisio D em t=15 por apresentar deadline mais
prximo (dA,3= 20). A requisio D reassume e conclui em t=16,5. O DSS pode tratar
com tarefas aperidicas firmes e a anlise para a garantia dinmica no difere muito das
usadas em servidores de prioridade fixa.
t a r e fa A -
ta re fa s Ci Pi Di
t a r e fa B - t a r e fa p e r i d i c a A 1 5 5
t a r e fa p e r i d i c a B 6 14 14
t a r e fa C -
t a r e fa s e r v i d o r a D S S 1 10 -
t a r e fa D -
t a r e fa a p e r i d i c a C 1 - -
t a r e fa a p e r i o d i c a D 1 - -
C D
A B A A B A A
0 1 2 4 5 6 8 10 12 14 16 18 20 22 24 t
C DSS
0 2 4 5 6 8 10 12 14 16 18 20 22 24
F ig u r a A . 4 : D y n a m ic S p o r a d ic S e r v e r c o m c a p a c id a d e m e n o r
ANEXO B
Sistemas Operacionais de Tempo Real

na Internet
O mercado de sistemas operacionais de tempo real fragmentado. Uma

consequncia direta disto a grande quantidade de solues disponveis. Este anexo
contm uma lista com cerca de 100 sistemas. Alm do nome de cada sistema aparece na
lista o nome do fornecedor e o endereo na Internet. importante observar que esta
lista inclui sistemas operacionais dos mais variados tipos, sendo que alguns no seriam
considerados realmente de tempo real em um teste mais rigoroso. Entretanto, em todos
eles, o fornecedor sugere o seu uso em aplicaes de tempo real de algum tipo. Como o
contedo da Internet dinmico, esta lista deve ser considerada como um ponto de
partida para uma pesquisa sobre o assunto, e no a palavra final. Certamente no
momento que este texto estiver sendo lido, a lista j estar desatualizada.
Listas similares podem ser encontradas em vrios endereos da Internet. Em
particular, a lista no "The IEEE Computer Society Technical Comite on Real-Time
Systems Home Page", em http://www.cs.bu.edu/pub/ieee-rts/, aponta para os principais
SOTR existentes.
Um excelente levantamento dos SOTR disponveis pode ser encontrado na revista
eletrnica "Dedicated Systems Magazine" (ex-"Real Time magazine", ela mudou de
nome no incio de 2000). O endereo da revista
http://www.realtime-info.com/encyc/market/rtos/rtos_home.htm
e uma lista com mais de 100 SOTR aparece em
http://www.realtime-info.com/encyc/market/rtos/rtos.htm.
Aqui est a lista de Sistemas Operacionais de Tempo Real:
C/OS-II fornecido por White Horse Design

http://www.uCOS-II.com
ITRON fornecido por TRON Association - ITRON Technical Committee
http://tron.um.u-tokyo.ac.jp/TRON/ITRON
AIX fornecido por IBM
http://www.austin.ibm.com/software/OS/index.html
AMX fornecido por KADAK Products Ltd
http://www.kadak.com/html/kdkp1010.htm
178 Anexo B Sistemas de Tempo Real na Internet
Ariel fornecido por Microware Systems Corporation

http://www.microware.com/ProductsServices/Technologies/ariel.html
ARTOS fornecido por Locamation
http://www.locamation.com/index.html
ASP6x fornecido por DNA Enterprises, Inc.
http://www.dnaent.com/c6x/press2.htm
Brainstorm Object eXecutive fornecido por Brainstorm Engineering Company
http://www.braineng.com/docs/boxhead.html
Byte-BOS fornecido por Byte-BOS Integrated Systems
http://www.bytebos.com/bytebos.htm
C Executive fornecido por JMI Software Systems Inc.
http://www.jmi.com/cexec.html
Chimera fornecido por The Robotics Institute Carnegie Mellon University
http://www.cs.cmu.edu/afs/cs.cmu.edu/project/chimera/www/home.html
ChorusOS fornecido por Sun Microsystems
http://www.sun.com/chorusos/
CMX fornecido por CMX Company
http://www.cmx.com/rtos.htm#rtx
CORTEX fornecido por Australian Real Time Embedded Systems (ARTESYS)
http://www.artesys.com.au
CREEM fornecido por GOOFEE Systems
http://www.goofee.com/creem.htm
CRTX fornecido por StarCom
http://www.n2.net/starcom/index.html
DDC-I Ada Compiler Systems (DACS) fornecido por DDC-I, Inc.
http://www.ddci.com/
Diamond fornecido por 3L
http://www.threel.co.uk
eCos fornecido por Cygnus Solutions
http://www.cygnus.com/ecos/
Elate(RTM) fornecido por Tao
http://www.tao-group.com
Embedded DOS 6-XL fornecido por General Software, Inc.
http://www.gensw.com/PAGES/EMBEDDED/EDOS6XL.HTM
EOS fornecido por Etnoteam S.p.A.
http://www.etnoteam.it/eos/eos.html
ERCOS EK fornecido por ETAS GmbH & Co.KG
http://www.etas.de/produkte/embedded_control/ercostext.htm
EspresS-VM fornecido por Mantha Software, Inc.
http://www.manthasoft.com
EUROS fornecido por Dr. Kaneff Engineering Consultants
http://www.directories.mfi.com/embedded/siemens/kaneff.htm
Fusion OS fornecido por Pacific Softworks
http:///www.pacificsw.com
179
Granada fornecido por Ingenieursbureau B-ware

http://www.b-ware.nl
Hard Hat Linux fornecido por MontaVista Software Inc
http://www.mvista.com
Harmony Real-Time Operating System fornecido por Institute for Information
Technology, National Research Council of Canada
http://wwwsel.iit.nrc.ca/projects/harmony/
Helios fornecido por Perihelion Distributed Software
http://www.perihelion.co.uk/helios/
HP-RT fornecido por Hewlett-Packard
http://www.hp.com/go/hprt
Hyperkernel fornecido por Nematron Corporation
http://www.hyperkernel.com/
icWorkshop fornecido por Integrated Chipware
http://www.chipware.com
Inferno fornecido por Lucent Technologies
http://www.lucent.com/inferno
INTEGRITY fornecido por Green Hills Software, Inc.
http://www.ghs.com/html/integrity.html
INtime (real-time Windows NT), iRMX fornecido por Radisys Corp.
http://www.radisys.com/products/intime/index.html
IRIX fornecido por Silicon Graphics, Inc.
http://www.sgi.com/real-time/products.html#irix
iRMX III fornecido por RadiSys Corporation
http://www.radisys.com/products/irmx/irmx.html
ITS OS fornecido por In Time Systems Corporation
http://www.intimesys.com
Jbed fornecido por esmertec ag
http://www.esmertec.com
JOS fornecido por JARP
http://www2.siol.net/ext/jarp
Joshua fornecido por David Moore
http://www.moore160.freeserve.co.uk
LP-RTWin Toolkit fornecido por LP Elektronik GmbH
http://www.lp-elektronik.com/products/evxwin.htm
LP-VxWin fornecido por LP Elektronik GmbH
http://www.lp-elektronik.com/products/etoolkit.htm
LynxOS fornecido por Lynx Real-Time Systems
http://www.lynx.com/products/lynxos.html
MC/OS runtime environment fornecido por Mercury Computer Systems, Inc.
http://www.mc.com/Data_sheets/mcos-html/mcos.html
MotorWorks fornecido por Wind River Systems Inc.
http://www.wrs.com
MTEX fornecido por Telenetworks
http://www.telenetworks.com/
Nucleus PLUS fornecido por Accelerated Technology Inc.

http://www.atinucleus.com/plus.htm
OS-9 fornecido por Microware Systems Corp.
http://www.microware.com/ProductsServices/Technologies/os-91.html
OS/Open fornecido por IBM Microelectronics North American Regional Sales
Office
http://www.chips.ibm.com/products/embedded/tools/osopen.html
OSE fornecido por Enea OSE Systems
http://www.enea.com
OSEK/VDX fornecido por University of KarlsruheInstitute of Industrial Information
Systems
http://www-iiit.etec.uni-karlsruhe.de/~osek
PDOS fornecido por Eyring Corporation Systems Software Division
http://www.eyring.com/pdos/
PERC - Portable Executive for Reliable Control fornecido por NewMonics Inc.
http://www.newmonics.com/WebRoot/perc.info.html
pF/x fornecido por Forth, Inc.
http://www.forth.com/Content/Products/cFData.htm
PowerMAX OS fornecido por Concurrent Computer Corporation
http://www.ccur.com/product_info/index.html#anchor913878
Precise/MQX fornecido por Precise Software Technologies Inc
http://www.psti.com/mqx.htm
PRIM-OS fornecido por SSE Czech und Matzner
http://www.sse.de/primos
pSOS, pSOSystem fornecido por Integrated Systems, Inc.
http://www.isi.com/
PXROS fornecido por HighTec EDV Systeme GmbH
http://www.hightec-rt.com
QNX fornecido por QNX SOFTWARE SYSTEMS EUROPE
http://www.qnx.com/products/os/qnxrtos.html
QNX/Neutrino fornecido por QNX Software Systems, Ltd.
http://www.qnx.com/products/os/neutrino.html
Real-time Extension (RTX) for Windows NT fornecido por VenturCom, Inc
http://www.vci.com/products/vci_products/vci_products.html
Real-Time Software fornecido por Encore Real Time Computing Inc.
http://www.encore.com
REAL/IX PX fornecido por Modular Computer Services, Inc.
http://www.modcomp.com/c+c/cover2.html
REALTIME CRAFT fornecido por TECSI
http://www.tecsi.com
Realtime ETS Kernel fornecido por Phar Lap Software, Inc.
http://www.pharlap.com/html/body/8pager.htm#ANCH3
RMOS fornecido por Siemens AG
http://www.ad.siemens.de/support/html_00/index.shtml
181
Roadrunner fornecido por Cornfed Systems, Inc.

http://www.cornfed.com
RT-Linux fornecido por New Mexico Tech
http://www.rtlinux.org
RT-mach fornecido por Carnegie Mellon University
http://www.cs.cmu.edu/~rtmach
RTEMS fornecido por OAR Corporation
http://www.rtems.com
RTKernel-C fornecido por On Time Informatik GmbH
http://www.on-time.com
RTMX O/S fornecido por RTMX Inc.
http://www.rtmx.com/
RTOS-UH/PEARL fornecido por Institut fuer Regelungstechnik, Universitaet
Hannover
http://www.irt.uni-hannover.de/rtos/rtos-gb.html
RTTarget-32 fornecido por On Time Informatik GmbH
http://www.on-time.com
RTX-51, RTX-251, RTX-166 fornecido por Keil Electronik GmbH
http://www.keil.com/products.htm
RTXC fornecido por Embedded System Products, Inc.
http://www.esphou.com
RTXDOS fornecido por Technosoftware AG
http://www.technosoftware.com
Rubus OS fornecido por Arcticus Systems AB
http://www.arcticus.se/rubus.htm
RxDOS fornecido por Api Software
http://www.rxdos.com
Smx fornecido por Micro Digital, Inc
http://www.smxinfo.com/smx/smx.htm
SORIX 386/486 fornecido por Siemens AG
http://www.siemens.de
SPOX fornecido por Spectron Microsystems, Inc.
http://www.spectron.com/products/spox/index.htm
SunOS, Solaris fornecido por Sun
http://www.spectron.com/products/spox/index.htm
Supertask! fornecido por U S Software
http://www.ussw.com
SwiftOS fornecido por Forth, Inc.
http://www.forth.com/Content/Products/SwiftX/SwiftX.htm
ThreadX - the high-performance real-time kernel fornecido por Express Logic, Inc.
http://www.expresslogic.com/products.html
Tics fornecido por Tics Realtime
http://www.concentric.net/~Tics/ticsinfo.htm
TNT Embedded Tool Suite fornecido por Phar Lap Software, Inc.
http://www.pharlap.com/html/tnt.html
Tornado/VxWorks fornecido por Wind River Systems Inc

http://www.wrs.com/products/html/tornado.html
TSX-32 fornecido por S&H Computer Systems, Inc
http://www.sandh.com/os.htm
velOSity fornecido por Green Hills Software, Inc.
http://www.ghs.com/html/velosity.html
Virtuoso fornecido por Eonic Systems
http://www.eonic.com
VRTX fornecido por Microtec Research
http://www.microtec.com/products/vrtx.html
Windows CE fornecido por Microsoft Inc.
http://WWW.eu.microsoft.com/windowsce/embedded/default.asp
XOS/IA-32 fornecido por TMO NIIEM
http://www.nexiliscom.com/osintro.html
XTAL fornecido por Axe, Inc.
http://www.axe-inc.co.jp
ANEXO C
Sintaxe e Semntica da Linguagem

Esterel
C.1 Mdulos e submdulos
Os programas Esterel so estruturados a partir das suas unidades bsicas, os

mdulos. Um mdulo tem um nome, uma declarao de interface e um corpo que
executvel.
Module <nome> :
<declarao de interface>
<corpo>
end module
Um mdulo pode utilizar submdulos que so mdulos instanciados pela construo
run; no pode haver recursividade sobre a instanciao.
C.2 Declarao de interface
A declarao de interface define os objetos que um mdulo importa ou exporta. Ela

contm objetos de dados declarados de forma abstrata em Esterel e implementados
externamente e objetos de interface reativa.
C.2.1 Dados
As declaraes de dados declaram os objetos que manipulam dados:
Tipos e operadores
Os cinco tipos primitivos de Esterel so: boolean, integer, float, double e string.
As operaes so as usuais: igualdade = e diferena < > para todos os tipos, and,
or e not para o tipo boolean e +, -, *, /, <, < =, >, >= para tipos integer, float,
double. O usurio pode definir seus prprios tipos declarando seus nomes; um tipo do
184 Anexo C Sintaxe e Semntica da Linguagem Esterel
usurio um objeto abstrato cuja definio ser dada somente na linguagem

hospedeira.
Constantes
possvel declarar constantes de qualquer tipo. Quando o tipo pr-definido, so
declarados em Esterel nome, tipo e valor; quando o tipo definido pelo usurio so
apenas declarados nome e tipo, sendo que o valor definido na linguagem hospedeira.
Funes
A declarao de funo contm a lista de tipos dos objetos que vai usar e o tipo do
objeto de retorno: function <nome> (<lista de tipo de argumentos>) : <tipo do
retorno>;.
Procedimentos
A declarao de um procedimento tem duas listas (opcionais) de argumentos de
tipos arbitrrios: lista de argumentos passados por referncia e modificveis pela
chamada (call), lista de argumentos passados por valores e no modificveis. A
declarao se apresenta na forma: procedure <nome> (<lista de tipo de argumento-
referncia>) (<lista de tipo de argumento-valor>);.
Procedimentos e funes so definidos na linguagem hospedeira e no apresentam
efeitos colaterais.
Tarefas
As tarefas so entidades de clculo externo mas que no podem ser consideradas
instantneas. Elas so sintaticamente similares aos procedimentos e so executadas pela
construo exec acoplada com o sinal return (ver a seguir)
C.2.2 Sinais e Sensores
Os sinais e sensores constituem a interface reativa do mdulo. Os sinais so

difundidos instantaneamente em todo o programa. O valor difundido de um sinal com
valor ou de um sensor nico a cada instante.
Declarao de sinais de interface

Os sinais de interface so de entrada input, de sada output, de entrada-sada
inputoutput e de terminao de tarefas externas return. Os sinais se dividem em
sinais puros (por exemplo input <nome-sinal>;) que tem apenas um estado de
presena (presente ou ausente) e sinais com valor que transportam tambm um
185
valor de tipo arbitrrio (por exemplo output <nome-sinal> := <valor inicial> : <tipo-
sinal>;).
Um sinal com valor no pode ser emitido pelo programa duas vezes no mesmo
instante e nem no mesmo instante que ele esta sendo recebido do ambiente. Ele
chamado de sinal com valor nico. Para se livrar desta restrio, utiliza-se a palavra
chave combine na declarao do sinal com valor; os sinais so chamado de sinais
com valor combinados. Operadores (and, or, +, *) e outras funes declarados pelo
usurio podem ser usados na combinao de sinais.
Existe apenas um sinal puro pr-definido tick que representa o relgio de ativao
do programa reativo mas no precisa declara-lo. Seu estado tem o valor presente a
cada instante.
Sensores
Os sensores so sinais de entrada com valor mas sem a presena da informao de
estado: sensor <nome-sensor> : <tipo-sensor>;. O valor do sensor acessado pelo
programa atravs da construo ?, quando necessrio
Relaes de entrada
A construo relation ... permite representar relaes de entrada que indicam
condies booleanas entre os sinais input e return; estas condies so
supostamente garantidas pelo ambiente. As relaes so de incompatibilidade ou
excluso entre os sinais (#) ou de sincronizao entre sinais (=>).
Declarao de sinal local

Sinais podem ainda ser declarados localmente pela declarao signal <lista de
sinais> in p end signal sem aparecer na interface do mdulo. A declarao dos sinais
locais feita da mesma forma que a dos sinais de interface e o escopo dos sinais locais
o corpo da construo p. Numa malha, um sinal local pode ser executado vrias vezes
no mesmo instante, criando a cada execuo uma nova copia.
C.2.3 Variveis
As variveis so objetos aos quais valores podem ser atribudos. A declarao das
variveis com seu nome, valor inicial e tipo feita numa construo de declarao de
varivel local var <lista de variveis> in p end var. O escopo da declarao de
varivel e o corpo da construo p. A modificao da varivel pode ser o resultado de
atribuies, chamadas de procedimentos e execues de tarefas externas (exec).
Contrariamente ao sinal, uma varivel pode tomar vrias valores sucessivos no mesmo
instante.
C.2.4 Expresses
As expresses possveis em Esterel so:
Expresses de dados
Elas combinam constantes, variveis, sensores e sinais com valores usando
operadores e chamadas de funo. A sua avaliao instantnea e envolve checagem de
tipos. "?S" indica o valor corrente do sensor ou do sinal com valor S.
Expresses de sinais
Elas so expresses booleanas ("not", "and", e "or") aplicadas sobre os estado de
sinais (ou do sinal "tick"). Elas so utilizados em testes de presena ou em expresses
de atraso.
Expresses de atraso
Elas so utilizadas em construes temporais tais como "await" ou "abort" para
expressar atrasos que comeam quando inicia a construo temporal que as contm.
Existem trs tipos possveis:
atrasos padres definidos por expresses de sinais e que nunca esgotam
instantaneamente;
atrasos imediatos definidos por "immediate [<expresso de sinais>]" e que
esgotam instantaneamente;
atrasos de contagem definidos por uma expresso de contagem inteira seguida
por uma expresso de sinais: ("<expresso-contagem> [<expresso-
sinais>]").
C.3 Construes do corpo
Todas as construes utilizveis no corpo do mdulo so descritas a seguir, a

exceo da declarao do sinal local j descrito anteriormente.
Construes bsicas de controle

As construes bsicas de controle so "nothing" que termina instantaneamente,
"pause" que para e termina no prximo instante , "halt" que para para sempre sem
nunca terminar.
187
Atribuio
A atribuio "X := e" com a varivel X e a expresso de dados e do mesmo tipo
instantnea.
Chamada de procedimento
A chamada de procedimento tem a forma "call P (X, Y) (e1, e2)" onde X, Y so
variveis e ei so expresses. A chamada instantnea.
Emisso de sinal
A emisso instantnea de sinal realizada por "emit S" ou "emit S(e)"
respectivamente no caso de um sinal puro ou de um sinal com valor resultante da
avaliao da expresso e. Para um sinal nico, somente um "emit" pode ser executado
neste instante; para um sinal combinado, o valor emitido combinado com os que so
emitidos por outros "emit" neste instante, usando a funo de combinao.
A emisso contnua de um sinal realizada pela construo "sustain S" ou "sustain

S(e)" que fica ativa para sempre e emite S ou S(e) a cada instante.
Seqncia
O operador de seqncia ";" permite que a construo q de "p; q" inicia
imediatamente aps a construo p ter terminada, a menos que p contenha algum "exit"
de um "trap".
Malha
A construo loop p end loop representa a malha simples infinita. O corpo p
sempre re-iniciado imediatamente aps seu trmino. Se construes trap fazem parte
do corpo p, os exit so propagados instantaneamente e a malha para. No permitido
que o corpo p de uma malha possa terminar instantaneamente quando iniciado.
A malha repetitiva executa seu corpo p um nmero finito de vezes. No permitido
que o corpo p termina instantaneamente. A construo repeat e times p end repeat
na qual e do tipo integer e avaliada somente uma vez no instante inicial. Se o
resultado da avaliao for zero ou negativo, o corpo no ser executado. A construo
repeat considerada como instantnea e no poder ser colocada numa malha loop
se no for precedido ou seguido por um atraso. Para garantir, neste caso, que o corpo
ser executado pelo menos uma vez, utiliza-se a construo positive repeat ... que
permite realizar o teste para repetio somente aps a primeira execuo do corpo.
Testes
O teste de presena binrio tem a seguinte forma geral present e then p else q end
present; uma das ramificaes then ou else pode ser omitida e neste caso a
omitida tem o significado de nothing. O teste de presena mltiplo utiliza a
construo case dentro do present da forma seguinte:
present
case e1 do p1
case e2 do p2
case e3 do p3
else q
end present
O teste condicional utiliza a construo if para testar expresses de dados

booleanas. O teste condicional binrio tem a seguinte forma if <condio> then p else
q end if. O teste condicional mltiplo no usa o case reservado para os teste de
presena de sinal mas pode ser realizado em seqncia usando a palavra chave elseif
da forma seguinte:
if <condio 1> then p1
elseif <condio 2> then p2
elseif <condio 3> then p3
else q
end if
Atraso
A construo temporal mais simples await S significa a espera por um atraso.
Quando a construo iniciada, ela entra em pausa at o atraso ser esgotado, instante
no qual ela termina.
A construo await immediate S termina instantaneamente se o sinal for
presente ou a expresso de sinal for verdadeira no instante inicial.
Pode se utilizar ainda a construo case dentro do await; o primeiro atraso que
se esgota fixa o comportamento seguinte; se dois deles se esgotam simultaneamente, a
prioridade com o primeiro da lista; a clusula else no permitida. A contagem do
nmero de sinais ou uma expresso de sinal pode tambm ser utilizada para expressar o
atraso.
A construo await completa utiliza uma clusula do para iniciar outra
construo quando o atraso esgota: await <expresso-atraso> do p end await.
Preempo
A construo abort p when <expresso-atraso> do q realiza uma preempo
189
forte do corpo p mas no entrega o controle a este no instante de preempo.

A construo weak abort p when <expresso-atraso> do q realiza uma
preempo fraca na qual o corpo p recebe o controle para um ltimo instante no
momento de preempo.
A clasula do permite executar uma construo q se o atraso esgotar,
imediatamente no caso de abort e aps o ltimo instante no caso de weak abort.
A introduo da palavra chave immediate nestas construes na forma ... when
immediate <expresso-atraso> ..., permite ao atraso de se esgotar imediatamente no
instante de inicio se a expresso de atraso for verificada neste; o corpo p da construo
no se executa no caso abort e se executa para um ltimo instante no caso weak
abort.
Uma lista de case pode tambm ser introduzida nestas construes de preempo.
Construes abort aninhadas so tambm possveis e estabelecem prioridades; por
exemplo J prioritrio sobre I se os dois ocorrem simultaneamente e q no ser
iniciado neste caso:
abort
abort p
when I do q
end abort
when J
A construo suspend p when <expresso-sinal> tem um efeito de suspenso

(do tipo ^Z do Unix). O corpo p imediatamente iniciado quando a construo
suspend inicia,. A cada instante, se a expresso de sinal for true, o corpo p se
suspende no seu estado atual e a construo suspend faz uma pausa neste instante; se
a expresso de sinal for false, o corpo p executado neste instante. Para realizar o
teste da expresso de sinal no primeiro instante necessrio utilizar suspend p when
immediate <expresso-sinal>.
Malha temporal
As malhas temporais so infinitas e o nico meio de termina-las atravs de uma
exceo (exit de um trap). Existem duas formas de declarar malhas temporais:
loop p each d onde d um atraso no imediato. O corpo p
inicializado ao instante inicial, e re-inicializado a cada vez que o atraso d
esgota; se p termina antes do esgotamento de d, o re-inicio de p dever
esperar at o atraso d se esgotar. Esta construo uma abreviao de:
loop
abort
p; halt
when d
end loop
every d do p end que difere do anterior pela espera inicial de d antes de

iniciar o corpo p. Esta construo abrevia:
await d;
loop
p
each d
Esta construo pode ser imediata every immediate d do p end e neste

caso, no instante inicial, p inicia imediatamente se o atraso d esgota
imediatamente.
Exceo e tratamento
O mecanismo de exceo implementado pela construo:
trap T in
p
handle T do
q
end trap
O corpo p inicia imediatamente quando a construo trap inicia. A sua execuo

continuar at o trmino de p ou a sada atravs da execuo da construo exit T
que leva o trap a terminar imediatamente, abortando p por preempo fraca. O
tratamento da exceo (quando houver) realizado pela construo handle, que
permite o inicio imediato de q aps corpo p ter sido abortado pelo exit do trap:
Quando se tem construes trap aninhadas, a mais externa tem a maior
prioridade. Vrias excees podem ser declaradas numa nica construo trap; todas
essas excees so concorrentes e tem o mesmo nvel de prioridade; no caso de vrias
excees ocorrer simultaneamente, seus tratadores de exceo sero executados em
paralelo.
As construes trap podem ter valores como os sinais. Inicializao de valor e
trap combinados so permitidos como no caso dos sinais. A passagem de um valor
ao tratador de exceo possvel e o resultado da expresso ??S que se encontra
somente neste tratador.
191
Paralelismo
O operador de paralelismo ll (que pode ter qualquer aridade) coloca as
construes que ele separa em paralelismo sncrono. Os sinais emitido por um dos
ramos ou por outra parte do programa so difundidos instantaneamente a todas os
ramos. Somente variveis para leitura podem ser compartilhadas em todos os ramos da
construo paralela.
Uma construo paralela, quando inicia, dispara instantaneamente uma thread por
ramo. Ela terminar quando todos os ramos tero terminado, esperando eventualmente
at o ltimo terminar. Se o exit de uma exceo trap ativada num ramo, ele
propagada em todos os outros ramos, levando a uma preempo fraca (weak abort)
de todos os ramos no mesmo tempo.
C.4 Instanciao de mdulo
A instanciao de um mdulo dentro de outro mdulo possvel a partir da

construo executvel run <nome-mdulo>.A instanciao recursiva de submdulos
proibida.
Como todos os dados so globais em Esterel, as declaraes de dados de um
submdulo instanciado so exportados no mdulo pai e vice-versa. As declaraes de
interface de sinais e de relaes devem ser descartadas; as interface de sinais de um
submdulo instanciado deve existir no mdulo pai com o mesmo tipo.
A renomeao de objeto de interface possvel em tempo de instanciao de
mdulo conforme definido na construo run <nome-mdulo> [ X / Y; ...] que
permite a renomeao de Y por X, desde que os tipos e operadores de tipos coincidam
("match"). O objeto renomeando X pode ser uma constante ou um operador ou um
identificador; o objeto renomeado Y deve ser um identificador pertencente a interface
de sinal ou a dados de mdulo instanciado.
C.5 A execuo de tarefa externa
O controle da execuo de tarefas externas que levam tempo usa o mecanismo

"exec". Essas tarefas se comportam como procedimentos a serem executados
assincronamente. O programa Esterel se interessa apenas pelo inicio e pelo fim delas ou
pela suspenso ou preempo das mesmas por outras construes Esterel.
A execuo de uma tarefa realizada por:
"exec Task (<parmetros-referncia>) (<parmetros-valores>)

return R"
na qual R o sinal de retorno. Quando deseja-se, simultaneamente, controlar vrias

tarefas, utiliza-se:
exec
case T1 (...) (...) return R1 do p1
...
case Tn (...) (...) return Rn do pn
end exec
Bibliografia
[ABR91] N. Audsley, A. Burns, M. F. Richardson, A. J. Wellings. Hard Real-

Time Scheduling: The Deadlin- Monotonic Approach. Proceedings of
the 8th IEEE Workshop on Real-Time Operating Systems and
Software, pp. 133-137, May 1991.
[AnP93] C. Andr, M-A. Peraldi. Synchronous Approach to Industrial Process
Control, Technical Report No 93-10, Laboratoire I3S, Universit de
Nice, March 1993.
[ARS91] K. Arvind, K. Ramamritham, J. Stankovic, A Local Area Network
Architecture for Communication in Distributed Real-Time Systems.
The Journal of Real-Time Systems, 3, pp. 115 147, 1991.
[AuB90] N. Audsley, A. Burns, Real-Time System Scheduling, on First Year
Report Task B of the Esprit BRA Project 3092: Predictably
Dependable Computing Systems, Chapter 2, vol2. of 3, May 1990.
[Aud93] N. Audsley, Flexible Scheduling of Hard Real-Time Systems. PhD
Thesis, Department of Computer Science, University of York, UK,
1993.
[Bak91] T. P. Baker. Stack-Based Scheduling of Realtime Processes. The
Journal of Real-Time Systems, Vol. 3, pp. 67-90, 1991.
[BCH95] E. Byler, W. Chun, W. Hoff, D. Layne. Autonomous Hazardous
Waste Drum Inspection Vehicle, IEEE Robotics & Automation
Magazine, March 1995.
[BCJ97] F. Balarin, M.Chiodo, A. Jureska, H. Hsieh, A. L. Lavagno, C.
Passerone, A. Sangiovanni-Vincentelli, E. Sentovich, K. Suzuki e B.
Tabbara. Hardware-Software Co-Design of Embedded Systems: The
Polis Appoach, Livro a ser publicado por Kluwer Academic Press,
1997.
[BCL99] A. Benveniste, B. Caillaud, P. Le Guernic. Compositionality in
dataflow synchronous languages: specification & distributed code
generation, in Journal Information and Computation, 1999.
[BCN95] G.Bucci, M. Campanai, P. Nesi. Tools for Specifying Real-Time
Systems, Journal of Real-Time Systems, pp. 173-198, 1995.
[BeB91] A Benveniste, G. Berry, The Synchronous Approach to Reactive and
Real-Time Systems, Proceedings of the IEEE, vol 79 (9), pp1270-
1282, sept. 1991.
194 Bibliografia
[BeB97] G. Bernat, A. Burns, Combining (n m)-Hard Deadlines and Dual

Priority Scheduling, In Proceedings. of the 18th IEEE Real-Time
Systems Symp. , December 1997.
[BeC99] A. Benveniste, P. Caspi. Distributing synchronous programs on a
loosely synchronous, distributed architecture, Rapport de Recherche
Irisa, No1289, Dcembre 1999.
[BeG92] G. Berry, G. Gonthier, The Esterel Synchronous Programming
Language: Design, Semantics, Implementation, Science of Computer
Programming vol. 19, n2, pp 87-152, 1992.
[Ber89] G. Berry, Real-Time Programming: Special Purpose or General
Purpose Languages, In Information Processing 89, pp11-17, Ed.
Elsevier Science Publishers, 1989.
[Ber92] G. Berry. Esterel on Hardware, on Philosophical Transactions Royal
Society of London A, vol 339, pp. 87-104, 1992.
[Ber98] G. Berry, The Foundations of Esterel, In Proof, Language and
Interaction: Essays in Honour of Robin Milner, G.Plotkin, C. Stirling
and M.Tofte (editors), Ed. MIT Press, 1998.
[Ber99] G. Berry, The Esterel v5 Language Primer, Esterel Reference
Manual. 1999.
[BNT93] A. Burns, M. Nicholson, K.W.Tindell, N. Zhang. Allocation and
Scheduling Hard Real-Time Tasks on a point-to-point Distributed
System. Proceedings of the Workshop on Parallel and Distributed
Real-Time Systems, pp. 11-20, Dana Point, CA, 1993.
[BoS91] F. Boussinot, R. de Simone, The Esterel Language: Another Look at
Real-Time Programming, Proceedings of the IEEE, vol. 79, pp 1293-
1304, sept. 1991.
[BoS96] F. Boussinot, R. de Simone, The SL Synchronous Language, IEEE
Transactions Software Engineering, vol. 22 (4), pp256-266, april
1996.
[Bud94] R. Budde. Esterel Applied to the Case Study Production Cell, in FZI
Publication (chap. 4) intitled Case Study Production Cell: A
Comparative Study in Formal Software Development",
Forschungszentrum Informatik Karlsruhe, 1994.
[But97] G.C. Buttazzo, Hard Real-Time Computing Systems: Predictable
Scheduling Algorithms and Applications, Ed. Kluwer Academics
Publishers, 1997.
[BuW97] A. Burns, A. Wellings, Real-Time Systems and Programming
Languages, Second edition. Addison-Wesley,1997.
195
[CaB97] M. Caccamo, G. Butazzo, Exploiting Skips in Periodic Tasks for

Enhancing Aperiodic Responsiveness, In Proc. of the 18th IEEE
RTSS, Dec. 1997.
[CaK88] D. Callahan, K. Kennedy. Compiling Programs for Distributed
Memory Multiprocessors, Journal Supercomputing, Vol. 2, pp. 151-
169, 1988.
[CER92] E. Coste-Manire, B. Espiau, E. Rutten. Task-level programming
combining object-oriented design and synchronous approach, in
IEEE International Conference on Robotics and Automation, pp.
2751-2756, Nice, May 1992.
[CGP99] P. Caspi, A. Girault, D. Pilaud. Automatic Distribution of Reactive
Systems for Asynchronous Networks of Processors, IEEE
Transactions on Software Engineering, vol. 25, No 3, pp. 416-427,
May/June 1999.
[CLL90] J.-Y. Chung, J. W. S. Liu, K. -J. Lin, Scheduling Periodic Jobs that
Allow Imprecise Results, IEEE Transactions on Computer, 39(9),
pp.1156-1174, 1990.
[Coo96] J. E. Cooling. Languages for the Programming of Real-Time
Embedded Systems - A Survey and Comparison, Microprocessors and
Microsystems, 20, pp. 67-77, 1996.
[Cos 89] E. Coste-Manire. Utilisation dsterel dans un contexte asynchrone:
una application robotique, Rapport de Recherche INRIA No 1139,
Dec 1989.
[CSR88] S. Cheng, J. A. Stankovic, K. Ramamrithan, Scheduling Algirithms
for Hard Real-Time Systems: A Brief Survey. In Hard Real-Time
Systems: Tutorial, Ed. J. A. Stankovic and K. Ramamrithan, pp. 150-
173, IEEE Computer Society Press, 1988.
[DEL91] DELTA-4, Real-Time Concepts, on Delta-4 Architecture Guide,
Cap.5, pp.102-124, 1991.
[DTB93] R. I. Davis, K. W. Tindell, A. Burns. Scheduling Slack Time in Fixed
Priority Pre-emptive Systems. Proceedings of the IEEE Real-Time
Systems Symposium, pp. 222-231, 1993.
[ENS99] J. Euler, M. do C. Noronha, D. M. da Silva, Estudo de Caso:
Desempenho do Sistema Operacional Linux para Aplicaes
Multimdia em Tempo Real, Anais do II Workshop de Tempo Real,
Salvador-BA, 25-28 de maio de 1999.
[FeC97] C. Fetzer, F. Cristian, Integrating External and Internal Clock
Synchronization, The Real-Time Systems Journal, pp.123-171, dez
1997.
196 Bibliografia
[Fid98] C. J. Fidge. Real-Time Schedulability Tests for Preemptive

Multitasking. Journal of Real-Time Systems Vol 14. pages 61-93,
1998.
[GaJ79] M. R. Garcey, D.S.Johnson. Computer and Intractability: a Guide to
the Theory of the NP-Completeness. W.H.Freeman and
Company,1979.
[Gal95] B. O. Gallmeister. POSIX.4 Programming for the Real World.
O'Reilly & Associates, ISBN 1-56592-074-0, 1995.
[GeR91] N. Gehani, K. Ramamritham. Real-Time Concurrent C: a Language
for Programming Dynamic Real-Time Systems, Journal of Real-Time
Systems, vol. 3, 1991.
[GLM94] T. Gautier, P. LeGuernic, O. Maffeis. For a New Real-Time
Methodology, Rapport de Recherche Inria, No2364, Octobre 1994.
[GNM97] M. Gergeleit, E. Nett, M. Mock, Supporting Adaptive Real-Time
Behavior in CORBA, Proceedings. of the First IEEE Workshop on
Middleware for Distributed Real-Time Systems and Services. San
Francisco, CA, Dec. 1997.
[Gus94] J. Gustafsson, Calculation of Execution Times in Object-Oriented
Real-Time Software A Study Focused on RealTimeTalk, PhD
Thesis, Royal Institute of Technology, Sucia, 1994.
[Har94] M. G. Harnon, et al. A Retargetable Technique for Predicting
Execution Time of Code Segments, The Journal of Real-Time
Systems, Vol. 7, pp 157-182, 1994.
[HaR95] M. Hamdaoui, P. Ramanathan, A Dynamic Priority Assignment
Technique for Streams com deadline (m,k)-firms, In IEEE
Transactions on Computer, April 1995.
[Har87] D. Harel. Statecharts: a Visual Approach to Complex Systems,
Science of Computer Programming, vol 8, pp231-274, 1987.
[HCR91] N. Halbwachs, P.Caspi, D. Pilaud. The Synchronous Dataflow
Programming Language Lustre, Another Look at Real Time
Programming, Proc. of the IEEE, vol. 79, sept. 1991.
[HeM96] C. Heitmeyer, D. Mandrioli (eds). Formal Methods for Real-Time
Computing, Ed. Wiley Trends in Software (5).
[HSP98] R. Hill, B. Srinivasan, S. Pather, D. Niehaus. Temporal Resolution
and Real-Time Extensions to Linux. Technical Report ITTC-FY98-
TR-11510-03, Information and Telecommunication Technology
Center, Electrical Engineering and Computer Science Department,
University of Kansas, 1998.
197
[JeS93] K. Jeffay, D. L. Stone. Accounting for Interrupt Handling Costs in

Dynamic Priority Task Systems.Proceedings of the IEEE Real-Time
Systems Symposium, pp. 212-221, December 1993.
[JLT85] E.Jensen, C. Locke, H. Tokuda. A Time-Driven Scheduling Model for
Real-Time Operating Systems, Proceedings of the 6th IEEE RTSS,
pp.112-122, Dec. 1985.
[JoP86] M. Joseph, P. Pandya. Finding Response Times in a Real-Time
System. BCS Computer Journal Vol 29, No 5, pp. 390-395, 1989.
[Jos91] M. Joseph. Problems, Promises and Performance: Some questions
for real-time system specification, on Proceedings of Rex Workshop
on Real-Time: Theory in Practice, Lecture Notes in Computer
Science N 600, June 1991, pp.315-324, Ed. Springer-Verlag.
[Kic97] G. Kiczales, et al. Aspect-Oriented Programming, Proceedings of the
ECOOP97, Spring-Verlag LNCS, No 1241, Finlndia, Junho de
1997.
[Kop92a] H. Kopetz, Sparse Time versus Dense Time in Distributed Real-Time
Systems, on Proceedings of 12th International Conference on
Distributed Computing Systems ICDCS'12, pp.460-467, June 1992,
Yokohama (Japan).
[Kop92b] H. Kopetz. Real-Time and Real-Time Systems, on Proceedings of
Advanced Course on Distributed Systems, July 1992, Estoril
(Portugal).
[Kop92c] H. Kopetz, Scheduling. on Proceedings of Advanced Course on
Distributed Systems, July 1992, Estoril (Portugal).
[Kop97] H. Kopetz. Real-Time Systems. Design Principles for Distributed
Embedded Applications. Kluwer Academic Publishers,1997.
[KoS95] G. Koren, D. Shasha, Skip-Over: Algorithms e Complexity for
Overloaded Systems that Allow Skips, In Proceedings of the 16th
IEEE RTSS, Pisa, Italy, December 1995.
[KSt86] E. Kligerman, A. Stoyenko. Real-Time Euclid: A Language for
Reliable Real-Time Systems. IEEE Transactions on Software
Engineering, 12(9), September 1986.
[KuM97] T. Kuo, A. K. Mok, Incremental Reconfiguration e Load Adjustment
in Adaptive Real-Time Systems, IEEE Trans. on Computers, Vol. 46,
No. 12, Dec. 1997.
[LeL90] G. Le Lann. Critical Issues for the Development of Distributed Real-
Time Computing Systems, Rapport de Recherche INRIA N 1274,
Aot 1990.
198 Bibliografia
[LeR92] J. P. Lehoczky, S. Ramos-Thuel. An Optimal Algorithm for

Scheduling Soft-Aperiodic Tasks in Fixed-Priority Preemptive
Systems. Proceedings of the IEEE Real-Time Systems Symposium,
pp. 110-123, 1992.
[LeW82] J. Y. T. Leung, J. Whitehead. On the Complexity of Fixed-Priority
Scheduling of Periodic, Real-Time Tasks. Performance Evaluation, 2
(4), pp. 237-250, december 1982.
[Li95] G. Li, An Overview of Real-Time ANSAware 1.0, Document APM.
1285.01, March 1995.
[LiL73] C. L. Liu, J.W.Layland. Scheduling Algorithms for
Multiprogramming in a Hard-Real-Time Environment. Journal of the
ACM, Vol. 20, No. 1, pp. 46-61, january 1973.
[LSL94] J. W. S. Liu, W. Shih, K.-J. Lin, R. Bettati, J.-Y. Chung. Imprecise
Computing. Proceedings of the IEEE, Vol. 82, No 1, pp. 83-94,
January 1994.
[LLG91] P. Le Guernic, M. Le Borgne, T. Gauthier, C. Le Maire,
Programming Real Time Applications with Signal, Another Look at
Real Time Programming, Proc. of the IEEE, vol. 79, sept. 1991.
[LSD89] J. P. Lehoczky, L. Sha, Y. Ding. The Rate Monotonic Scheduling
Algorithm: Exact Characterization and Avarage-Case Behavior.
Proceedings of the IEEE Real-Time Systems Symposium, pp.166-
171, Los Alamitos, CA, December 1989.
[LSS87] J. P. Lehoczky, L. Sha, J.K. Strosnider. Enhanced Aperiodic
Responsiveness in Hard Real-Time Environments. Proceedings of
IEEE Real-Time Systems Symposium, San Jose, CA, pp. 261-270,
1987.
[Mae87] P. Maes, Concepts and Experiments in Computational Reflection,
Proceedings of OOPSLA87, pp. 147-155, 1987.
[Maf93] O. Maffeis. Ordonnancements de Graphes de Flots Synchrones;
Application a la Mise en Oeuvre de Signal, Tese de Doutorado,
Universidade de Rennes I, France, Jan.1993.
[MFO99] C. Montez, J. Fraga, R. S. Oliveira, J-M. Farines, An Adaptive
Scheduling Approach in Real-Time CORBA, 2nd IEEE International
Symposium on Object-oriented Real-time Distributed Computing -
ISORC99, Saint-Malo, France, May 1999.
[Mil80] R. Milner, A Calculus of Communicating Systems, Lecture Notes in
Computer Science, vol 92, 1980, Ed. Springer-Verlag.
199
[Mot92] L. Motus, Time Concepts in Real-Time Software, on Proceedings of

International Workshop on Real-Time Programming WRTP'92, June
1992, Bruges (Belgium).
[OlF97] R. S. Oliveira, J. S. Fraga, Escalonamento de Tarefas com Relaes
Arbitrrias de Precedncia em Sistemas Tempo Real Distribudos,
16 Simpsio Brasileiro de Redes de Computadores, SBC, Rio de
Janeiro-RJ, 25-28 de maio de 1998.
[OMG98] OMG, Realtime CORBA - Joint Revised Submission, Object
Management Group (OMG), Document orbos/98-10-05, October
1998.
[Ort99] S. Ortiz Jr, The Battle Over Real-Time Java, IEEE Computer, Vol.
32, No. 6, pp. 13-15, june 1999.
[Pin95] M. Pinedo, Scheduling: Theory, Algorithms and Systems. Prentice-
Hall, 1995.
[POS97] A. Pascoal, P. Oliveira, C. Silvestre, A. Bjerrum, A. Ishoy, J.-P.
Pignon, G. Ayela, C. Petzelt. MARIUS: An Autonomous Underwater
Vehicle for Coastal Oceanography, IEEE Robotics & Automation
Magazine, december 1997.
[Raj91] R. Rajkumar. Synnchronization in Real-Time Systems: A Priority
Inheritance Approach. Kluwer Academic Publishers,1991.
[RaS94] K. Ramamrithan, J. A. Stankovic. Scheduling Algorithms and
Operating Systems Support for Real-Time Systems. Proceedings of
the IEEE, Vol. 82, No 1, pp. 55-67, January 1994.
[Ray91] M. Raynal, La Communication et le Temps dans les Rseaux et les
Systmes Rpartis, Cap.8 et 9, 1991, Ed. Eyrolles.
[RNS93] U. Rembold, B. O. Nnaji, A. Storr, Computer Integrated
Manufacturing and Engineering, Addison-Wesley Publishing
Company, ISBN 0-201-56541-2, 1993.
[Rus93] J. Rushby. Formal Methods and the Certification of Critical Systems,
Technical Report CSL-93-7, disponivel em http://www.csl.sri.com,
1993.
[SBS93] S. Ramesh, G. Berry, R.K. Shyamasundar. Communicating Reactive
Processes, in Proceedings of 20th ACM Conference on Principles of
Programming Languages, 1993.
[SeR98] B. Selic, J. Rumbaugh. Using UML for Modeling Complex Real-Time
Systems, artigo disponvel em http://www.rational.com, 1998.
[SGW94] B. Selic, G. Gullekson, P. Ward. Real-Time Object-Oriented
Modeling, Ed. Wiley Wiley Professional Computing.
200 Bibliografia
[SiG98] A. Silberschatz, P. B. Galvi, Operating System Concepts, Addison-

Wesley, 5th edition, ISBN 0-201-59113-8, 1998.
[SpB96] M. Spuri, G.C. Buttazzo. Scheduling Aperiodic Tasks in Dynamic
Priority Systems. Journal of Real-Time Systems Vol 10 No 2, 1996.
[SPG97] S. Shenker, C. Partridge, and R. Guerin, Specification of Guaranteed
Quality of Service. RFC 2212, IETF Specification, 1997.
[SPH98] B. Srinivasan, S. Pather, R. Hill, F. Ansari, D. Niehaus. A Firm Real-
Time System Implementation Using Commercial Off-The-Shelf
Hardware and Free Software. Proc. of the Real-Time Technology and
Applications Symposium, june 1998.
[Spu96] M. Spuri. Analysis of Deadline Scheduled Real-Time Systems,
Technical Report, INRIA, Frana No 2776, Janeiro 1996.
[SRL90] L. Sha, R. Rajkumar, J. P. Lehoczky. Priority Inheritance Protocols:
An approach to Real-Time Synchronization. IEEE Transactions on
Computers, Vol. 39, No. 9, pp. 1175-1185, september 1990.
[SSL89] B. Sprunt, L. Sha, J. Lehoczky. Aperiodic Task Scheduling for Hard-
Real-Time Systems. The Journal of Real-Time Systems, Vol. 1, pp.
27-60, 1989.
[Sta88] J. A. Stankovic, Misconceptions about real-time computing, IEEE
Computer, vol 21 (10), October 1988.
[Sta96] J. Stankovic et al. Strategic Directions in Real Time and Embedded
Systems, ACM Computing Surveys, Vol. 28, No 4, pp. 751-763,
December 1996.
[STB96] E. Sentovich, H. Toma, G. Berry. Latch Optimization in Circuits
Generated from High-level Descriptions, in Proceedings of
International Conference on Computer-Aided Design (ICCAD), 1996.
[StR88] J. A. Stankovic, K. Ramamrithan, (Editors) Tutorial on Hard Real-
Time Systems, 1988, IEEE Computer Society Press.
[StR90] J. A. Stankovic, K. Ramamrithan, What is predictability for Real-
Time Systems?, The Journal of Real Time Systems, vol.2, pp.247-254,
1990, Ed. Kluwer Academic Publications.
[TaT92] K. Takashio, M. Tokoro, DROL: An Object-Oriented Programming
Language for Distributed Real-Time Systems, Proceedings of
OOPSLA92, 1992.
[TaT93] K. Takashio, M. Tokoro, Time Polymorphic Invocation: A Real-Time
Communication Model for Distributed Systems, In Proceedings of the
IEEE WPDRTS93, 1993.
201
[TaW97] A. S. Tanenbaum, A. S. Woodhull, Sistemas Operacionais Projeto e

Implementao, Bookman, segunda edio, ISBN 85-7307-530-9,
1997.
[TBU98] M. Timmeman, B. V. Beneden, L. Uhres. RTOS Evaluation Kick Off
Real-Time Magazine, 1998-Q33, http://www.realtime-info.be,
(atualmente Dedicated Systems Magazine), 1998.
[TBW94] K. W. Tindell, A. Burns, A.J. Wellings. An Extendible Approach for
Analyzing Fixed Priority. Hard Real-Time Tasks. Journal of Real-
Time Systems 6(2). pages 133-151, 1994.
[TiC94] K. W. Tindell, J. Clark. Holistic Schedulability Analysis for
Distributed Hard Real-Time Systems. Microprocessors and
Microprogramming Vol. 40, 1994.
[Vah96] U. Vahalia, Unix Internals - The New Frontiers, Prentice-Hall, ISBN
0-13-101908-2, 1996.
[Vie99] J. E. Vieira. LINUX-SMART: Melhoria de Desempenho para
Aplicaes Real-Time Soft em Ambiente Linux. Dissertao de
mestrado. Instituto de Matemtica e Estatstica, Universidade de So
Paulo, Outubro de 1999.
[VRC97] P. Verssimo, L. Rodrigues, A. Casimiro, CesiumSpray: A Precise
and Accurate Global Time Service for Large-scale Systems, The
Journal of Real-Time Systems, 12, pp.243-294, dez 1997.
[WaL99] Y.-C. Wang, K.-J. Lin. Implementing a General Real-Time
Scheduling Framework in the RED-Linux Real-Time Kernel. Proc. of
the Real-Time Systems Symposium, December 1999.
[Wur99] P. Wurmsdobler. A Simple Control Application with Real-Time
Linux, Real-Time Linux Workshop, Vienna, 1999.
[XuP93] J. Xu, D. L. Parnas. On Satisfying Timing Constraints in Hard Real-
Time Systems. IEEE Transaction on Software Engineering, Vol. 19,
No 1, pp. 70-84, January 1993.
[YoB99] V. Yodaiken, M. Barabanov. RT-Linux Version Two, Real Time
Linux Workshop, http://www.thinkingnerds.com/projects/rtl-ws/rtl-
ws.html, Vienna, 1999.
[You82] S. J. Young, Real-Time Languages Design and Development, Ellis-
Harwood Ed., 1982.
[ZhB94] S. Zhang, A. Burns. Timed Proprieties of the Timed Token Protocol.
Technical Report YCS 243. University of York, UK, 1994.

Sistem As de Tempo Real Far Ines

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Sistem As de Tempo Real Far Ines

Caricato da

Copyright:

Formati disponibili

Sistemas de Tempo Real

Joni da Silva Fraga

Rmulo Silva de Oliveira

Departamento de Automao e Sistemas

Universidade Federal de Santa Catarina

Florianpolis, julho de 2000.

A preocupao com o tempo, entre filsofos e matemticos, vem desde a

essas duas abordagens ao visto de exemplos ilustrativos e um ltimo captulo de

1 Introduo sobre o Tempo Real . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 O Escalonamento de Tempo Real . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.6 Tarefas Dependentes: Compartilhamento de Recursos . . . . . . . . . . . . . . 35

3 Suportes para Aplicaes de Tempo Real . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4 O Modelo de Programao Sncrona para os Sistemas de Tempo Real . . 105

5 Aplicao das Abordagens Assncrona e Sncrona . . . . . . . . . . . . . . . . . . . 131

5.2 Aplicao com Abordagem Sncrona . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

6 Tendncias Atuais em Sistemas de Tempo Real . . . . . . . . . . . . . . . . . . . . . 155

ANEXO A - Extenses em Esquemas de Prioridade Dinmica . . . . . . . . . . 165

Figura 1.1 Sistema de tempo real . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Figura 3.7 Tipos de suportes para aplicaes de tempo real . . . . . . . . . . . . . . 84

Tabela 2.1 Utilizao de tarefas peridicas . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Introduo sobre o Tempo Real

1.1 Os Sistemas de Tempo Real

Na medida em que o uso de sistemas computacionais prolifera na sociedade atual,

Essas prioridades so determinadas usualmente a partir da importncia das

1.2 O Tempo: Diferentes Interpretaes

A noo de tempo em sistemas informticos difcil de ser expressa, podendo

[Ray91], [Mot92], [Kop92a], [Jos91]. Alguns desses enfoques so colocados em

1.3 Conceituao Bsica e Caracterizao de um Sistema

Excetuando sistemas computacionais normalmente identificados como Sistemas

Um Sistema de Tempo Real (STR) um sistema computacional que deve reagir a

Figura 1.1: Sistema de Tempo Real

Existem tambm situaes nas quais as restries temporais no so impostas pelo

manuseio ou da apresentao de vdeos em sistemas multimdias). Nesses casos utiliza-

1.4 A Previsibilidade nos Sistemas de Tempo Real

as hipteses de carga e de falha que descrevem o comportamento do ambiente sejam

1.5 Classificao dos Sistemas de Tempo Real

Os sistemas de tempo real podem ser classificados a partir do ponto de vista da

probabilistas sobre a carga esperada e os cenrios de falhas aceitveis. Essa

1.6 O Problema Tempo Real e Abordagens para a sua

O Problema Tempo Real consiste ento em especificar, verificar e implementar

princpio bsico na considerao que os clculos e as comunicaes no levam tempo.

O Escalonamento de Tempo Real

Em sistemas de tempo real que seguem a abordagem assncrona os aspectos de

Em sistemas onde as noes de tempo e de concorrncia so tratadas explicitamente,

Na seqncia introduzido um conjunto de conceitos que permitem a caracterizao

2.2 Modelo de Tarefas

2.2.1 Restries Temporais

Tarefas Brandas ou No Crticas (tarefas "soft"): Essas tarefas quando se

Tarefas Peridicas: Quando as ativaes do processamento de uma tarefa ocorrem,

Tarefas Aperidicas ou Tarefas Assncronas: Quando a ativao do processamento

Tempo de computao ("Computation Time"): O tempo de computao de uma

Tempo de incio ("Start Time"): Esse tempo corresponde ao instante de incio do

Tempo de trmino ("Completion Time"): o instante de tempo em que se

Tempo de chegada ("Arrival Time"): O tempo de chegada de uma tarefa o

Tempo de liberao ("Release Time"): O tempo de liberao de uma tarefa

a tiv a o 1 a tiv a o 2 a tiv a o 3

2.2.2 Relaes de Precedncia e de Excluso

Em aplicaes de tempo real, muitas vezes, os processamentos no podem executar

2.3 Escalonamento de Tempo Real

2.3.1 Principais Conceitos

O termo escalonamento ("scheduling") identifica o procedimento de ordenar tarefas

na fila de Pronto. O escalonador ("scheduler") o componente do sistema responsvel

falha em um conjunto de tarefas na determinao de uma escala realizvel ento todos