Professional Documents
Culture Documents
Jean-Marie Farines
Joni da Silva Fraga
Rmulo Silva de Oliveira
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
ii
iii
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
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
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
Lista de Figuras
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
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;
Sistema
a
Controlar
Interface de
Instrumentao
Sistema
Computacional
de Controle
Interface
HomemMquina
Operador
manuseio ou da apresentao de vdeos em sistemas multimdias). Nesses casos utilizase 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.
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.
Captulo 2
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
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.
13
14
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
D
Pi
D
J
Ci
a
r1
Ci
ct
st
a =r
st
Ci
ct
r3
st
ct
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 2
r e q u is i o 1
m in i
m in i
Di
Di
Ci
0
st
C
ct
st
= a
ct
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
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.
16
17
18
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.
19
20
A b o rd a g e n s c o m G a ra n tia
e m T e m p o d e P ro je to
E x e c u tiv o
C c lic o
A b o rd a g e n s c o m
G a ra n tia D in m ic a
A b o rd a g e n s d e
M e lh o r E sfo r o
T c n ic a s
A d a p ta tiv a s
D irig id o a
P rio rid a d e s
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
te ste su fic ie n te
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
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
21
U =
[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:
U =
22
23
Ci
Pi n 2
[2 ]
1 .
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
Tarefas Peridicas
Pi 1.
Periodo
Tempo de Computao
Prioridade RM
Utilizao
(Pi)
(Ci)
(pi)
(Ui)
tarefa A
100
20
0,2
tarefa B
150
40
0,267
tarefa C
350
100
0,286
0 , 753 n 2
1 = 0 , 779
24
A ,B ,C
40
80
1 20
A ,B
160
200
2 40
2 80
320
3 60
U =
i=1
Ci
25
[3 ]
Pi 1 .
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.
C
ta r e fa A
10
20
20
ta r e fa B
25
50
50
A ,B
ta r e fa A -
ta re fa s p e ri d ic a s
10
20
30
(a)
A ,B
ta r e fa B -
40
50
60
E sc a lo n a m e n to E D F
B
p e r d a d e d e a d lin e d e B
10
20
30
(b)
40
50
60
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
26
Ci
Pi
Di
pi
ta r e f a A
10
ta r e f a B
10
ta r e f a C
20
16
ta r e f a A ta r e f a B ta r e f a C -
A ,B ,C
A ,B ,C
A ,B
d
dB
dC
12
16
20
24
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
27
j =1
t
. C j ,
Pj
[4 ]
28
S i = kPj 1 j i,
Pi
k = 1 ,2 , . . . ,
.
P j
[6 ]
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
29
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
W1 (t ) =
.1 0
2 0
t
t
W 2 (t ) =
.2 5 +
.1 0 ,
5 0
2 0
W1 ( t )
t
W2 (t )
.
t
30
"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 +
j h p (i)
R
= i C
Pj
31
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 re fa s p e ri d ic a s
ta r efa A
ta r efa B
ta r efa C
Ci
2
2
8
Pi
10
10
20
Di
6
8
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
.2 +
.2 = 1 2
R C1 = 8 +
1 0
1 0
12
12
.2 +
.2 = 1 6
R C2 = 8 +
10
1 0
16
16
.2 +
.2 = 1 6
R C3 = 8 +
1 0
1 0
32
Wi + J j
Cj
Pj
j h p (i)
[9 ]
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 ]
33
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 "ibusy 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]:
W i ( q ) = ( q + 1) C i +
Wi (q )
C .
Pj j
j h p (i)
[1 1 ]
[1 2 ]
34
W i ( q ) = ( q + 1) C i +
Wi ( q ) + J j
Cj
Pj
j h p (i)
[1 3 ]
[1 4 ]
R i = m a x ( J i + W i ( q ) q Pi ).
q = 0 , 1 , 2 ,...
Ji
Ci
Pi
Di
ta r efa T 1
10
40
40
ta r efa T 2
10
80
25
ta r efa T 3
20
40
5 + 3
8 0 .1 0 = 2 5
25 + 3
+
.1 0 = 2 5
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
35
5 + 3
8 0 .1 0 = 3 0
30 + 3
.1 0 = 3 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 -
Ji
Ci
Pi
Di
tar efa T 2 -
tar efa T 1
10
40
40
tar efa T 2
10
80
25
tar efa T 3
20
40
tar efa T 3 -
T2
T1 T3
-3
-1 0
T3
10
d2
20
30
36
tarefas comunicantes.
p
> p
> p
> p
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
37
Descrio do Protocolo
38
> p
> p
> p
b lo q u e io d ir e to p o r T
T
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 0
1 1
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.
> p
> p
39
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
T3
T4
0
10
11
F ig u ra 2 .1 1 : B lo q u e io tra n s itiv o
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
1
+
i ( 2 i 1),
P
P
j =1 j
i
i.
[15 ]
40
ta r e f a s
Ci
Pi
Bi
T1
18
T2
20
T3
10
50
T a b e la 2 .5
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
i =1
B
1
Ci
B
+ m a x 1 , . . . . , n n . 2 n 1 .
Pi
P
P
1
n
[1 6 ]
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:
B B
1
C1
C
C
+ 2 + 3 + m a x 1 , 2 3 2 3 1
P1
P2
P3
P1 P2
41
i , min 0 < t Pi U i ( t ) 1.
[17 ]
Wi ( q ) + J j
C j.
Pj
j h p (i)
[1 8 ]
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.
Descrio do Protocolo
42
43
S2 -
S3 -
T1
T3
1
Eventos
10
11 12
13
14 15
16
17
Descrio
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).
T 1 libera S 1 .
10
T 1 fecha Semforo S2 .
11
T 1 libera S 2 .
12
13
14,15,16,17
44
B i = m a x D j ,k
j ,k
(p
< p i (C ( S k ) p i ) .
ta r e f a s
S1
S2
S3
ta r e f a T 1
ta r e f a T 2
ta r e f a T 3
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
45
46
tarefas
T2
T4
T1
J i Ci
Pi
Di
T1
10 40 40
T2
10 80 25
T3
T4
10 80 80
80 40
T3
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.
47
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
10 = 15
W 31 = 5 +
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 + 23
10 + 1
5 = 25
10 +
W 41 = 1 0 +
8 0
4 0
48
25 + 1
25 + 23
W 42 = 1 0 +
10 +
5 = 2 5
4
0
80
49
Servidor de "Background"
50
(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
ta r e f a
ta r e f a
ta r e f a
ta r e f a s
p e r i d ic a A
p e r i d ic a B
a p e r i d ic a C
a p e r io d ic a D
Ci
4
8
1
1
Pi
10
20
-
Di
10
20
-
ta r e f a A -
pi
1
2
3
3
ta r e f a B ta r e f a C ta r e f a D -
A ,B
10
12
A ,B
14
16
18
20
22
24
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
"Polling Server"
tarefa
tarefa
tarefa
tarefa
tarefa
tarefas
peridica A
peridica B
servidora PS
aperidica C
aperiodica D
Ci
4
8
1
1
0,5
Pi
10
20
5
-
Di
10
20
-
51
pi
3
2
1
-
A ,B
10
12
A ,B
14
16
18
20
22
24
C PS
1
10
15
16
20
i =1
ou seja
Ci
C
+ P S (n + 1) 2
Pi
PP S
U P ( n + 1) 2
( n + 1)
( n + 1)
1 ,
1 + U S .
52
"Deferrable Server"
Ci
Pi
Di
pi
t a r e fa p e r i d i c a A
ta re fa s
10
10
t a r e fa p e r i d i c a B
20
20
t a r e fa s e r v i d o r a P S
t a r e fa a p e r i d i c a C
t a r e fa a p e r i o d i c a D
0 ,5
A ,B
t a r e fa A t a r e fa B t a r e fa C t a r e fa D -
10
12
A ,B
14
16
18
20
22
24
C DS
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
53
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 Espordico
54
55
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 tarefa
tarefa
tarefa
tarefa
tarefa
Ci
1
6
2 ,5
1
1
Pi
5
14
10
-
Di
5
14
-
pi
1
3
2
-
ta refa s
p e ri d ic a A
p e ri d ic a B
serv id o ra S S
ap eri d ica C
ap erio d ica D
10
12
14
16
18
20
10
12
14
16
18
20
22
24
C SS
3
2
1
5
2
ln
.
U SS + 1
[2 0 ]
56
ta r e f a 1
10
ta r e f a 2
14
4 2 ,9
se rv id o r D S
1 ,0 0
2 0 ,0
se rv id o r P E
1 ,3 3
2 6 ,7
se rv id o r S S
1 ,3 3
2 6 ,7
U i (% )
2 0 ,0
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
ta re fa s
57
Ci
Pi
Di
M in i
pi
t a r e fa p e r i d i c a A
12
12
t a r e fa p e r i d i c a B
20
20
t a r e fa s e r v i d o r a S S
32
10
t a r e fa a p e r i d i c a C
10
32
A ,B ,C
t a r e fa A t a r e fa B t a r e fa C -
dC
10
12
14
16
18
20
22
24
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
ta r efa B ta r efa C -
A ,B ,C
Ci
Pi
Di
M in i
pi
ta r efa p er i d ica A
12
12
ta r efa p er i d ica B
20
20
ta r efa ser v id o r a S S
32
10
ta r efa a p er id ica C
10
32
dC
12
16
20
24
28
32
12
16
20
24
28
32
CSS
8
58
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
Captulo 3
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
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.
64
"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 prdeterminada. 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
inativa
bloqueada
65
Destruio
66
67
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:
68
69
70
71
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:
72
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
73
74
75
interrupo
latncia
(A)
k-des
hw
trat
tempo
interrupo
latncia
(B)
k-des
hw
k-des
trat
tempo
interrupo
(C)
latncia
k-hab
hw
k-hab
trat
tempo
76
77
situaes.
Apenas 1 tratador
interrupo
int.2
resposta
resposta 1
latncia
resposta 2
latncia
trat
trat.1
latncia
tempo
trat.1
trat.2
tempo
latncia
ctx
outra
ctx
trat
thread
thread
tempo
78
79
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:
A mesma questo pode ser feita com respeito aos mdulos do sistema
responsveis pela alocao de memria e pelo sistema de arquivos.
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 ?
80
81
10
15
20
25
30
35
40
21..30
31..40
41..50
51..60
61..70
71..80
81..90
91..100
82
83
84
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
Previsibilidade
maior
Ncleo de
Tempo Real
Previsibilidade
menor
Qualquer Ncleo
Simples
completa
Futuro...
Sistema Operacional
Adaptado
85
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
86
87
88
Inclui suporte para MMU ("Memory Management Unit"), vrias tarefas com
mltiplas "threads", mas sem sistema de arquivos;
89
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
90
91
92
93
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_upri - parte da prioridade definida pelo usurio (nice, entre -20 e +19);
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.
94
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.
95
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",
96
RT-POSIX (1003.1b/lc);
97
98
Network throughput: 1.1 Mbytes/s (10 Mbit Ethernet) e 7.5 Mbytes/s (100 Mbit
Ethernet).
Pentium/133
1.95
4.3
Pentium/100
2.6
4.4
486DX4
6.75
386/33
22.6
15
99
Protocolos TCP/IP, incluindo ftp, ftpd, telnet, telnetd e outros, alm de PPP e
rede local;
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.
100
101
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 coexiste com o "kernel" do Linux. O objetivo deste arranjo permitir que aplicaes
utilizem os servios sofisticados e o bom comportamento no caso mdio do Linux
tradicional, ao mesmo tempo que permite tarefas de tempo real operarem sobre um
ambiente mais previsvel e com baixa latncia. O "microkernel" de tempo real executa o
"kernel" convencional como sua tarefa de mais baixa prioridade (Tarefa Linux), usando
o conceito de mquina virtual para tornar o "kernel" convencional e todas as suas
aplicaes completamente interrompveis ("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
102
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
103
104
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 KURTLinux 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
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
107
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.
108
? B.~ R.! O
?A.~R.! O
?R
?R
?B.~R.! O
? A.~R.! O
109
110
111
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
112
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 ?.
113
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
114
trap T in
p
handle T do
q
end trap
115
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
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
116
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". Constatase 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.
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 CorrerRpido), 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.
118
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
119
weak abort
exec TASK (X) (...) return R;
when I
abort
exec TASK (X) (...) return R;
when I
120
su sp en d
e x e c T A S K ( X ) ( .. .) r e t u r n R ;
w h en S
exec
case T 1 (...) (...) return R 1 do p 1
...
loop
exec TA SK (X ) (...) return R ;
each I
121
122
123
124
125
126
127
Causalidade:
O programa seguinte:
128
||
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:
em it S (?S + 1)
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
130
Captulo 5
132
Nvel de planejamento;
Nvel de navegao;
Nvel de pilotagem.
133
Monitora
rodas
Reconhece
alarme
Estima
posio
Computa
posio
Obtm
Reconhece
imagem
referncia
Define
velocidade
e direo
Identifica
obstculo
Atualiza
mapa
Mapa
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.
134
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)
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
135
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)
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
136
Tarefa
Tipo
P (ms)
D (ms)
C (ms)
C_P
Peridica
100
100
20
L_I
Peridica
500
500
20
A_M
Peridica
500
500
100
R_R
Peridica
1300
1300
200
D_V_D
Peridica
100
100
30
E_D
Espordica
2000
20
Soft
Predecessor
Bloqueio (ms)
1 (c/R_R)
L_I
3 (c/D_V_D)
1 (c/C_P)
C_P
3 (c/A_M)
137
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,
138
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)
timer
peridica
10
10
0,1
C_P
peridica
100
100
20
Bk
L_I
peridica
500
500
20
Bk
A_M
peridica
500
500
100
R L_I
R_R
peridica
1300
1300
200
Bk
D_V_D
peridica
100
100
30
R C_P
E_D
espordica
2000
20
Bk
servidora
10000
80
Bk
1 (B R_R ))
L_I
C_P
3 (B A_M )
Bm
i : 1 i n, Ri Di .
Wi = Ci +
Wi + J j
C
Pj j
j hp(i)
R i = Wi + J i .
[9 ]
[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.
RE _ D = WE _ D + Bk = 1,3 ms
Ptimer
PE _ D
RR = WR + Bk = 6,2 ms
Ptimer
PE _ D
WC _ P + Bk
+
CR = 27,3
PR
RC _ P = WC _ P + Bk = 27 ,4 ms
139
140
WD_V _ D + Bk
+
CR = 39,6
PR
RD _V _ D = WD _V _ D + RC _ P = 67 ms
CR +
Ptimer
PR
PE _ D
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
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
141
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.
142
#define
RT_TASK
STACK_SIZE
my_task;
143
3000
144
Bomba
V lv u la
N v e l_ M a x i
N v e l_ M in i
In ic _ R e g
R E S E R V A T O R IO
F im _ R e g
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
145
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
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
146
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
147
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
148
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
149
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
Consumo_em Curso
handle
Inic
Fim
MINUTE
REPARO
Bomba_em_Reparo
Tarefa
externa
exec
Reparo_Bomba_Concludo
Alarme_Bomba
Nvel
Superior
Bomba_Autorizada
Inic_Consumo
Fim_Consumo
150
151
152
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
Tempo Real
Sistemas
de
156
(ii)
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.
158
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:
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
159
160
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.
161
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
162
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
163
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 (RealTime 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
A.1
Testes para
Dinmicas
Escalonamentos
com
Prioridades
Ci.
P i t Pi
n
166
Pi t
t
P C i.
i
[A 1 ]
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
L ( m + 1 ) = W ( L ( m ) ) ,
[A2]
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
W (t ) =
i=1
t
P Ci .
i
[ A 3]
Ci
1.
167
[ 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
W (t ) =
i=1
t + Ji
P
i
Ci .
Pi t + J i
t + Ji
P Ci .
Pi t + J i
t + Ji
Ci.
Pi
168
t Di
1 +
Ci .
Di t
Pi
C (t ) =
[ A 5]
Com isto uma condio necessria e suficiente para tarefas peridicas possuindo
deadlines arbitrrios e escalonadas pelo EDF, obtida atravs de:
t Di
1 +
Ci
Di t
Pi
[A 6 ]
[ A7]
t + J i Di
1 +
Ci
Pi
Di t + J i
Di t + Ji
[ A8]
t + Ji Di
1 +
Ci
Pi
[A 9 ]
ta re fa s p e ri d ic a s
Ci
Pi
Di
ta r e fa A
10
ta r e fa B
10
ta r e fa C
20
16
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
(1)
= W (L
(2)
= W (L
= 12
(0)
( 1)
) = 16
) = 16
Logo L=16, com isto obtemos o conjunto dos valores possveis de t [A7]:
= d ik d ik 1 6
170
Descrio 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
c a s o (a )
Dj
Di
t2
t1
di
dj
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
R r ( n
= m ax
[{0 } {
n r < r ,i
}].
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 = 1, 2 , ... , m .
172
T1
....
pedido (R 1,1)
libera (R 1)
pedido (R 2,3)
libera (R 2)
....
Rr
Max nr
R1
R2
R3
T2
....
pedido (R 3,2)
libera (R 3)
pedido (R 1,1)
libera (R 1)
....
T3
....
pedido (R 3,1)
pedido (R 2,1)
libera (R 2)
libera (R 3)
....
Semforos : S1 -
S2 -
S3 -
T1
T2
T3
0
10
12
14
16
18
20
22
1
2
3
10
12
14
16
18
20
22
Cj
j =1
Pj
Bi
1,
Pi
i ,1 i n .
173
j =1
Bi
1,
Di
i,1 i n.
1 +
D j t + J j
t + J j Dj
t + J i Di
C j + 1 +
Bi
Pj
Pi
i, 1 i n
= 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:
174
Bi = m ax D j , r
j ,r
< i R S r
(0)
175
Ci
Pi
ta r e fa B -
ta r e fa p e r id ic a A
ta r e fa s
ta r e fa C -
ta r e fa p e r id ic a B
14
14
-
ta r e fa s er vid o r a D S S
ta r e fa D D
2 ,5
10
ta r e fa a p e r id ic a C
ta r e fa a p e r iod ic a D
Di
10
12
14
10
12
14
16
18
20
22
24
C D SS
3
2
1
0
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
176
ta re fa s
t a r e fa B t a r e fa C t a r e fa D -
Pi
Di
5
t a r e fa p e r i d i c a B
14
14
t a r e fa s e r v i d o r a D S S
10
t a r e fa a p e r i d i c a C
t a r e fa a p e r i o d i c a D
C
A
Ci
t a r e fa p e r i d i c a A
10
12
14
16
18
20
22
24
10
12
14
16
18
20
22
24
C DSS
1
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
178
179
180
181
182
ANEXO C
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
Constantes
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
Tarefas
185
valor de tipo arbitrrio (por exemplo output <nome-sinal> := <valor inicial> : <tiposinal>;).
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
Relaes de entrada
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.
186
C.2.4 Expresses
As expresses possveis em Esterel so:
Expresses de dados
Expresses de sinais
Expresses de atraso
187
Atribuio
Chamada de procedimento
Emisso de sinal
Seqncia
Malha
188
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
o sinal for
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
Malha temporal
190
loop
abort
p; halt
when d
end loop
Exceo e tratamento
O mecanismo de exceo implementado pela construo:
trap T in
p
handle T do
q
end trap
191
Paralelismo
192
Bibliografia
[ABR91]
N. Audsley, A. Burns, M. F. Richardson, A. J. Wellings. Hard RealTime Scheduling: The Deadlin- Monotonic Approach. Proceedings of
the 8th IEEE Workshop on Real-Time Operating Systems and
Software, pp. 133-137, May 1991.
[AnP93]
[ARS91]
[AuB90]
[Aud93]
[Bak91]
[BCH95]
[BCJ97]
[BCL99]
[BCN95]
[BeB91]
194
Bibliografia
[BeB97]
[BeC99]
[BeG92]
[Ber89]
[Ber92]
[Ber98]
[Ber99]
[BNT93]
[BoS91]
[BoS96]
[Bud94]
[But97]
[BuW97]
195
[CaB97]
[CaK88]
[CER92]
[CGP99]
[CLL90]
[Coo96]
[Cos 89]
[CSR88]
[DEL91]
[DTB93]
[ENS99]
[FeC97]
196
Bibliografia
[Fid98]
[GaJ79]
[Gal95]
[GeR91]
[GLM94]
[GNM97]
[Gus94]
[Har94]
[HaR95]
[Har87]
[HCR91]
[HeM96]
[HSP98]
197
[JeS93]
[JLT85]
[JoP86]
[Jos91]
[Kic97]
[Kop92a]
[Kop92b]
[Kop92c]
[Kop97]
[KoS95]
[KSt86]
[KuM97]
[LeL90]
G. Le Lann. Critical Issues for the Development of Distributed RealTime Computing Systems, Rapport de Recherche INRIA N 1274,
Aot 1990.
198
Bibliografia
[LeR92]
[LeW82]
[Li95]
[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]
[LLG91]
[LSD89]
[LSS87]
[Mae87]
[Maf93]
[MFO99]
[Mil80]
199
[Mot92]
[OlF97]
[OMG98]
[Ort99]
S. Ortiz Jr, The Battle Over Real-Time Java, IEEE Computer, Vol.
32, No. 6, pp. 13-15, june 1999.
[Pin95]
[POS97]
[Raj91]
[RaS94]
[Ray91]
[RNS93]
[Rus93]
[SBS93]
[SeR98]
[SGW94]
200
Bibliografia
[SiG98]
A. Silberschatz, P. B. Galvi, Operating System Concepts, AddisonWesley, 5th edition, ISBN 0-201-59113-8, 1998.
[SpB96]
[SPG97]
[SPH98]
B. Srinivasan, S. Pather, R. Hill, F. Ansari, D. Niehaus. A Firm RealTime System Implementation Using Commercial Off-The-Shelf
Hardware and Free Software. Proc. of the Real-Time Technology and
Applications Symposium, june 1998.
[Spu96]
[SRL90]
[SSL89]
B. Sprunt, L. Sha, J. Lehoczky. Aperiodic Task Scheduling for HardReal-Time Systems. The Journal of Real-Time Systems, Vol. 1, pp.
27-60, 1989.
[Sta88]
[Sta96]
[STB96]
[StR88]
J. A. Stankovic, K. Ramamrithan, (Editors) Tutorial on Hard RealTime Systems, 1988, IEEE Computer Society Press.
[StR90]
J. A. Stankovic, K. Ramamrithan, What is predictability for RealTime Systems?, The Journal of Real Time Systems, vol.2, pp.247-254,
1990, Ed. Kluwer Academic Publications.
[TaT92]
[TaT93]
201
[TaW97]
[TBU98]
[TBW94]
[TiC94]
[Vah96]
[Vie99]
[VRC97]
[WaL99]
[Wur99]
[XuP93]
J. Xu, D. L. Parnas. On Satisfying Timing Constraints in Hard RealTime Systems. IEEE Transaction on Software Engineering, Vol. 19,
No 1, pp. 70-84, January 1993.
[YoB99]
[You82]
[ZhB94]