588441-Aulas STR 2

SOFTWARE DE TEMPO-REAL
Professor Paulo Rgis
O que so sistemas de tempo-real?
Sistema em tempo real qualquer sistema no qual o

tempo cuja sada produzida significante.
Qualquer sistema ou atividade de processamento de
informao o qual deve responder a um estmulo de
entrada gerada externamente dentro de um perodo
finito e especificado.
Conseqentemente, o funcionamento correto de um
sistema de tempo-real no est somente associado
resposta lgica correta, mas tambm ao tempo no
qual a resposta foi produzida.
Exemplos de aplicaes ou sistemas

de tempo-real
Sistemas de controle de veculos para
automveis, metrs, aeronaves, ferrovias e
navios;
Controle de trfego para auto-estradas,
espao areo, trilhos de ferrovias e
corredores de navegao martima;
Controle de processo para usinas de energia,
indstrias qumicas e para produtos de
consumo, como refrigerantes e cerveja;
Bloco de um sistema de tempo-real
Tempo de resposta
Existem
muitas interpretaes do conceito

exato de sistemas de tempo-real. Mas, todos
tm em comum a noo de tempo de
resposta. Ou seja, o tempo necessrio para
o sistema gerar uma sada de alguma
entrada associada.
Sistemas de tempo-real hard e soft
Os sistemas de tempo-real ainda podem ser

classificados como do tipo Hard eSoft:
O sistema de tempo-real hard aquele que
imperativo (essencial) que respostas aconteam
dentro de um prazo-limite (deadline) especfico.
O sistema de tempo-real soft aquele em que
tempos de resposta so importantes, mas o sistema
ainda ir funcionar corretamente se o prazo-limite for
ocasionalmente perdido. Ou seja, nesses sistemas
no existem deadlines explcitos.
Exemplos de sistemas de tempo-real

hard e soft
Como exemplo, podemos citar um sistema de

controle de trfego areo como um sistema de
tempo-real hard. Pois, nesse sistema, se uma
resposta da localizao de uma aeronave no for
produzida em um prazo especfico uma catstrofe
poder acontecer.
Como exemplo de um sistema de tempo-real soft,
podemos citar o sistema operacional Windows. Se
um atraso na abertura de uma aplicao acontecer,
isso no ser visto como falha do sistema. Nesse
caso, observa-se que no h um prazo-limite
especfico.
Caractersticas de sistemas de temporeal

Nem
todos os sistemas de tempo-real iro

exibir as caractersticas abaixo. Mas,
qualquer linguagem de proposta geral
utilizada para desenvolver um sistema de
tempo-real deve apresentar facilidades que
suportem essas caractersticas.
Tamanho e Complexidade
A maioria dos problemas associados com o desenvolvimento

de aplicaes est relacionada ao tamanho e complexidade.
Aplicaes pequenas so fceis de serem mantidas,
recodificadas e entendidas por qualquer pessoa. Mas, uma
linguagem que se proponha ao desenvolvimento de um
sistema de tempo-real deve oferecer facilidades para minimizar
o tamanho e complexidade de uma aplicao. Como por
exemplo, oferecer facilidades para modularizar o cdigo,
oferecer nmero reduzido de instrues, apresentar funes
eficientes, entre outras. A complexidade pode ser diminuda
utilizando-se uma linguagem com poucas funes eficientes.
Operaes com Nmeros Reais
A maioria dos sistemas de tempo-real monitoram ou controlam

eventos do ambiente externo. Em geral, esse monitoramento
pode ser realizado por sensores, cujas sadas podem ser
dadas por um sinal de corrente ou tenso. Como exemplo, por
correntes variando entre 4 a 2OmA ou tenses variando entre
O a 10V.
Assim, uma linguagem que se prope ao desenvolvimento de

sistemas de tempo-real, deve ser capaz de oferecer facilidades
para operao com nmeros reais.
Confiabilidade e Segurana
Em alguns exemplos de sistemas de tempo-real, uma falha pode

ocasionar perdas de vidas humanas, danos ao meio ambiente ou
grandes danos financeiros. Assim, esses sistemas podem ser
considerados como sistemas crticos.
Confiabilidade a probabilidade de operao livre de falhas durante

um tempo espec em um dado ambiente, para um propsito especfico.
Segurana reflete a capacidade do sistema operar de forma normal e
anormalmente, sem oferecer ameaas as pessoas ou ao ambiente.
Disponibilidade.
Controle Concorrente de Componentes

Sistemas de tempo-real lidam com eventos do mundo real,
muitos deles ocorrendo simultaneamente.
Ou seja, dois ou mais eventos podem ocorrer
simultaneamente. Assim, o hardware e o software devem
apresentar tcnicas ou implementaes que permitam a
concorrncia desses processos.
Assim sendo, um hardware que apresentasse mltiplas
entradas e sadas, com um SO que permitisse escalonamento
de processos e uma linguagem que apresentasse funes
para criao de threads, permitiria uma concorrncia em nvel
de hardware e software.
Linguagens e SOs para tempo-real:
- RTOS: RTLinux QNX, CMX (da CMX company), AMX (da

KADAK), Femto OS, Neutrino, entre outros;
- Linguagens para STR: OCCAM, MODULA, ADA, MESA,
entre outras.
Facilidades de Tempo-Real
Tempo de resposta essencial em uma aplicao de temporeal. Para isso, o hardware utilizado deve apresentar bom
desempenho, alm da linguagem e do suporte de run-time
apresentar facilidades como:
- Especificar tempos nos quais as aes so executadas;
- Especificar tempos nos quais as aes devem ser finalizadas;
- Responder a situaes em que todos os requisitos de tempo
no podem ser atendidos;
- Responder a situaes em que os requisitos de tempo so
mudados dinamicamente.
Interao com Interfaces de Hardware
Sistemas de tempo-real interagem intimamente com o mundo

externo. Para isso, eles devem apresentar interfaces para
monitoramento e controle de eventos do meio externo. Como
exemplo, conversores AD podem ser adicionados ao sistema
para monitorar variveis externas. O sistema tambm pode
oferecer o conceito de interrupo para monitorar eventos
espordicos, caractersticos do mundo externo.
A linguagem utilizada tambm pode apresentar facilidades
para programao em baixo-nvel. Programao em baixonvel permite melhor acesso e operao ao hardware do
sistema.
Implementao Eficiente
Desde que sistemas de tempo-real so crticos no tempo, uma

implementao eficiente da aplicao torna-se necessria. Em
muitas situaes, a utilizao de uma linguagem de alto nvel
deve ser evitada, pois pode ocasionar um tempo de resposta
de milisegundos, em vez de microsegundos, como requerido
pela aplicao.
Como exemplo, uma aplicao simples em C pode gerar um
tempo de resposta bem menor do que a mesma aplicao
desenvolvida em JAVA.
Arquitetura e Programao
Concorrente
A Noo de Processo
Um
programa concorrente pode ser

conceituado como um conjunto de processos
seqenciais autnomos executando em
paralelo. Toda linguagem de programao
concorrente deve incorporar, implcita ou
explicitamente, a noo de processo. Cada
processo tem sua prpria linha de execuo
de controle, chamada de thread.
Concorrente
Processo
o objeto ativo de um sistema e

a unidade lgica de trabalho escalonada
pelo sistema operacional.
Concorrente
Processos
e Modelos de Sistemas
Baseados em Estados
Um processo pode ter uma ou mais linhas de

execuo, chamadas de threads. Uma linguagem
que permite apenas uma linha de execuo em
um processo chamada de monothread. Caso a
linguagem permita a criao de duas ou mais
threads, ela chamada de multithread.
Concorrente
O processo pode apresentar alguns estados:
- Criado: neste estado, o processo pai est criando a thread que

levada a fila de prontos;
- Executando: neste estado a linha de execuo est usando a CPU;
- Pronto: neste estado, a linha de execuo avisa a CPU que pode
entrar no estado de
execuo e entra na fila de prontos;
- Bloqueado: neste estado, por algum motivo, a CPU bloqueia a linha
de execuo,
geralmente enquanto aguarda algum dispositivo de I\O;
- Trmino: neste estado so desativados os contextos de hardware e
a pilha deslocada.
Concorrente
Processos
Peridicos e Espordicos
Sistemas de tempo-real geralmente contm
dois tipos de processos: peridicos e
espordicos. Processos peridicos so
ativados de forma regular entre intervalos
fixos de tempo.
Concorrente
Em
contraste, processos espordicos so

dirigidos por eventos; eles so ativados por
um sinal externo ou uma mudana de
alguma relao. Um processo espordico
poderia ser usado para reagir a um evento
indicando uma falha de alguma pea de
equipamento ou uma mudana no modo de
operao de um sistema.
Concorrente
Na sua forma mais simples, um processo peridico P

caracterizado por uma tripla (c, p, d), onde c
representa o tempo de computao, usualmente uma
estimativa do pior caso, para P cdigo; p o perodo
ou ciclo de tempo e d o prazo-limite (deadline), com
c <= d <= p. O significado que o processo ativado
a cada unidade p de tempo e sua computao c deve
ser completada antes que seu prazo-limite d expire.
O perodo e o prazo-limite so obtidos ou derivados a
partir dos requisitos do sistema; p e d so geralmente
idnticos.
Concorrente
Um processo espordico tambm representado

por uma tripla (c, p, d), c <= d <= p. Aqui, c e d tm
um significado similar ao do caso peridico. Na
ocorrncia de um evento, a computao deve ser
concluda dentro do prazo-limite especificado; isto ,
o tempo de concluso t deve satisfazer
t <= te + d,
onde te o tempo de ocorrncia de evento. p
representa o tempo mnimo entre eventos; isto ,
eventos sucessivos esto separados por, no mnimo,
p.
Concorrente
Execuo Concorrente
Embora construes para programao concorrente variem de uma

linguagem para outra, existem 3 facilidades fundamentais que devem
ser produzidas:
- A expresso de execuo concorrente atravs da noo de
processo;
- Sincronizao de processos;
- Comunicao inter-processo.
Em relao interao de processos, eles podem ser caracterizados
da seguinte maneira:
- Independentes;
- Cooperantes;
- Competidores.
Concorrente
Representaco de Processos
Fork e Join:
. A estrutura Fork especifica que a rotina projetada deveria iniciar executando

concorrentemente com o invocador do Fork. A estrutura Join permite o invocador para
sincronizar com a finalizao da rotina invocada. Como exemplo:
Funo F retum...;
Procedure P;
C:= fork F;
J:= join C;
End P;
Entre a execuo do fork e do join, a procedure P e a funo F iro executar em paralelo.
No ponto do join a procedure ir esperar at a funo finalizar (se ela j no tiver
finalizado). A notao fork e join pode ser achada na linguagem Mesa. A verso de fork e
join pode tambm ser encontrada no UNIX.
Concorrente
- Cobegin:
O cobegin (ou parbegin ou par) um caminho estruturado de
denotao de execuo concorrente de uma coleo de
estruturas:
Cobegin
S1;
S2;
S3;
Sn;
Coend
A estrutura cobegin pode ser encontrada em OCCAM2.
Concorrente
Declarao de Processo Explcito:
O exemplo abaixo foi desenvolvido em linguagem Modula-1.

MODULE main;
TYPE dimension = (xplane, yplane, zplane);
PROCESS control (dim: dimension);
VAR position: integer;
setting : integer;
BEGIN
position:= 0 ;
LOOP
newsetting(dim, setting);
position:= position + setting;
move_arm (dim, position);
END
END control;
BEGIN
control (xplane);
control (yplane);
control (zplane);
END main.
Confiabilidade e Tolerncia a Faltas
Se um sistema de controle tem que responder a um

evento em um determinado tempo, a falha desse
sistema impossibilitar a entrega dessa resposta no
tempo apropriado. Como exemplo, um radar em
uma sala de controle areo tem que varrer uma
regio a cada 3 segundos. Uma falha desse sistema
impossibilitar a visualizao de aeronaves nesse
intervalo de tempo, podendo ocasionar um desastre
areo.
Fontes de faltas:
Existem, em geral, 4 fontes de faltas que podem resultar

em uma falha do sistema de tempo-real:
- Especificao inadequada. A maioria das faltas de
software originada por especificao inadequada.
- Faltas introduzidas de erros de projeto em componentes
de software.
- Faltas introduzidas pela falha de um ou mais
componentes processadores no sistema de tempo-real.
- Faltas introduzidas por interferncia permanente ou
transiente no subsistema de comunicao.
Diferenciando falta, erro e falha:

Uma falta poderia ser exemplificada como uma
imperfeio fsica ou mecnica de algum componente do
sistema ou a um erro no algoritmo de software do
sistema.
Um sistema de tempo-real pode ser caracterizado por um
certo nmero de estados internos e externos. Em um
determinado instante, um estado do sistema no
esperado pode ser caracterizado por um estado errneo,
ou seja, por um erro.
Uma falha caracterizada por um desvio de
comportamento do sistema no qual ele foi especificado
para isso.

Exemplificando
falta, erro e falha.
Tipos de faltas:
Faltas transientes: uma falta transiente inicia em
um tempo particular, permanece no sistema por
algum tempo e ento desaparece. Exemplos de tais
faltas esto em componentes de hardware os quais
tem uma reao adversa a alguma interferncia
externa, tais como campos eltricos ou
eletromagnticos. Muitas faltas em sistemas de
comunicao so transientes.
Faltas permanentes: faltas permanentes iniciam

em um determinado tempo e permanecem no
sistema at serem reparadas. Como exemplo, um
fio partido ou um erro de projeto de software.
Faltas intermitentes: so faltas transientes que
ocorrem de tempo em tempo. Um exemplo um
componente de hardware que sensvel ao calor.
Ele trabalha por um perodo, aquece, pra de
trabalhar, volta a esfriar e ento trabalha novamente.

Preveno
de Faltas:
Essa tcnica permite eliminar qualquer possibilidade

de faltas no sistema antes de se tornar operacional.
Existem dois estgios de preveno de faltas: fault
avoidance (evitar faltas) e fault removal (remoo
de faltas).
Fault avoidance a tcnica que possibilita limitar a

introduo de potenciais componentes defeituosos
durante a construo do sistema. Para o hardware,
temos:
- O uso de componentes mais confiveis dentro do
custo e desempenho exigidos;
- O uso de tcnicas refinadas para interconexo de
componentes e para a montagem de subsistemas;
- Encapsulamento do hardware para diminuir efeitos
de interferncias externas
Com relao ao software, faltas podem ser evitadas

da seguinte maneira:
- Especificao de requisitos rigorosos, seno
formais;
- Uso de metodologias de projeto comprovadas;
- Uso de linguagens que facilitem a abstrao de
dados e modularidade;
- Uso de ambientes de suporte de projeto que
ajudem a desenvolver os componentes de software
e tambm gerenciar a complexidade;

Tcnicas
de Remoo de Faltas:
Mesmo com o uso de tcnicas para se evitar
faltas, faltas iro inevitavelmente estar
presentes no sistema depois de sua
construo. Em particular, devido a erros de
projetos em componentes de hardware e
software. Assim, um segundo estgio de
preveno de faltas empregado. a
tcnica de remoo de faltas.
Na tcnica de remoo de faltas, testes so

realizados e faltas so retiradas quando
encontradas. Alguns problemas podem existir:
Um teste pode somente ser usado para mostrar a
presena de falta, no sua ausncia;
Em algumas situaes, impossvel testar em
condies realistas;
Erros que so introduzidos em tempo de projeto,
mas que s se manifestam quando o sistema passa
a operar.
Obs: Mesmo com o uso de tcnicas de preveno
de faltas, faltas podem existir e levar o sistema a
falhar.
Tolerncia a faltas:
Por causa das inevitveis limitaes de tcnicas de preveno de

faltas, projetistas de sistemas de tempo real devem considerar o uso
de tcnicas de tolerncia a faltas.
Existem alguns nveis diferentes de tolerncia a faltas que

podem ser produzidas para um sistema:
falha operacional (fail operational): O sistema continua a
operar na presena de faltas, por um perodo limitado de
tempo, sem perda significante de sua funcionalidade ou
desempenho;
falha suave(failsoft): O sistema continua a operar na
presena de erros, aceitando uma degradao de sua
funcionalidade ou desempenho durante a recuperao ou
reparo.
falha segura (failsafe): O sistema mantm sua integridade
enquanto aceita uma parada temporria em sua operao.
Redundncia:
Todas as tcnicas para se conseguir tolerncia a
faltas dependem de elementos extras que so
introduzidos no sistema para detectar e se recuperar
de faltas. Esses componentes so redundantes,
mas no so requeridos no sistema para que este
tenha modo de operao normal.
A redundncia pode ser classificada como:

redundncia esttica e redundncia dinmica.
Redundncia Esttica:
Na redundncia esttica, os componentes redundantes
so usados dentro do sistema para esconder os efeitos
das faltas. Um exemplo de redundncia esttica a
TMR. TMR consiste de trs subcomponentes idnticos e
um circuito de votao majoritria. Esse circuito de
votao compara a sada de todos os componentes, e se
uma sada difere das outras duas, essa sada
mascarada.

Redundncia
Dinmica:
Redundncia dinmica uma redundncia

produzida dentro do componente o qual indica
explcita ou implicitamente que a sada est errada.
Essa redundncia fornece facilidades de deteco
de erro em vez de facilidades de mascaramento de
erro. Recuperao deve ser produzida para qualquer
componente.
Programao N-Verso (redundncia esttica de

software):
O sucesso de TMR e NMR de hardware tem
motivado uma abordagem similar para tolerncia
a faltas de software. Embora software no se
degrade com o uso, essa abordagem permite
detectar faltas de projeto. Programao N-verso
definida como a produo independente de N
programas equivalentes funcionalmente de uma
mesma especificao inicial.

Programao
N-Verso:
Uma vez projetado e escrito, os programas

executam concorrentemente com as mesmas
entradas e seus resultados so comparados por um
processo driver. Em princpio, os resultados
deveriam ser idnticos, mas na prtica pode existir
alguma diferena. O resultado consensual (da
maioria) considerado como o correto.

Programao
N-Verso:
Para a produo de verses diferentes, as N
verses podem ser desenvolvidas em
linguagens diferentes, ou com mesma
linguagem, mas com compiladores
diferentes, ou at com mesma linguagem e
compilador, mas com escopos diferentes.

Um
programa N verso controlado por um

processo driver o qual responsvel por:
invocar cada uma das verses;
esperar cada verso finalizar;
comparar e agir sobre o resultado.

Componentes
do processo driver e das
verses:
- Vetores de comparao;
- Indicadores de status de comparao;
- Pontos de comparao.
Vetores de comparao so estruturas de dados os quais

representam as sadas, ou votos, das verses. Esta
comparao deve ser realizada pelo driver.
Indicadores de status de comparao so comunicados do
driver para as verses; eles indicam que aes cada verso
deve desempenhar como resultado da comparao do driver.
Tais aes vo depender da comparao, podem ser:
continuao da execuo da verso;
trmino de uma ou mais verses;
continuao e posterior mudana de um ou mais votos para
valor majoritrio.
Pontos de comparao so os pontos nas verses em que
eles devem comunicar seus votos para o processo driver.
Confiabilidade e Tolerncia a
Faltas
Programa
N-verso:
Redundncia Dinmica de Software:

Com redundncia dinmica, os componentes
redundantes s iro operar se um erro for detectado.
Esta tcnica de tolerncia a faltas possui quatro
fases:
Deteco de erro;
Avaliao e confinamento de danos;
Recuperao de erro;
Tratamento de falta e servio continuado.
Duas classes de tcnicas de deteco de erros

podem ser identificadas:
- deteco de ambiente: Existem erros que so
detectados no ambiente no qual o programa
executa. Como exemplo, podemos citar: execuo
ilegal de instrues; overflow aritmtico; violao de
proteo; valor fora de range; ponteiro nulo no
referenciado, entre outros.
- deteco de aplicao: Existem erros que so
detectados pela prpria aplicao.
Deteco de aplicao:
Muitos testes podem ser realizados na aplicao
para deteco de erros:
Teste de replicao;
Teste de temporizao (tempo);
Teste reverso;
Teste de codificao;
Teste de razoabilidade;
Teste estrutural;

Avaliao
e Confinamento de Dano:
Como pode existir algum atraso entre a
ocorrncia de uma falta e o aparecimento do
erro, necessrio avaliar qualquer dano que
tenha ocorrido. Uma informao errnea
poderia se espalhar atravs do sistema e
dentro do seu ambiente. Ento, avaliao de
dano est fortemente relacionada a
precaues de confinamento de dano.
Avaliao e confinamento de danos:

Existem duas tcnicas que podem ser usadas para
estruturao de sistemas, as quais iro ajudar no confinamento
de danos: decomposio modular e aes atmicas.
Decomposio modular uma tcnica que possibilita quebrar
o sistema em componentes menores, em que cada
componente pode representar um ou mais mdulos.
A atividade de um componente dita ser atmica se no existe
interao entre a atividade e o sistema durante a ao. Nesse
caso, para o resto do sistema, uma ao atmica aparenta ser
indivisvel e executada instantaneamente. Nenhuma
informao pode ser passada da ao atmica para o sistema
ou vice-versa.

Recuperao
de Erro
a fase que deve converter um estado
errneo do sistema em um estado de
operao normal, embora haja uma
degradao do servio. Duas abordagens
para recuperao de erro so utilizadas:
recuperao para frente e recuperao para
trs.
Recuperao de erro para frente permite continuar

de um estado errneo pela correo seletiva para o
estado do sistema.
Recuperao de erro para trs permite restabelecer
o sistema a um estado seguro antes do erro
ocorrido. Uma seo alternativa do programa
ento executada. A seo alternativa a ser
executada deve ter algoritmo diferente da seo que
causou o erro. Como na programao N-verso,
desejvel que a seo alternativa no resulte na
mesma falta recorrente. O ponto no qual o processo
deve ser restabelecido chamado de ponto de
recuperao e a ao de substituio chamada de
check-pointing.

Problemas
de IPC:
Tratamento de Falta e Servio Continuado

Tratamento de faltas pode ser dividido em dois
estgios: localizao da falta e reparo do sistema.
Tcnicas de deteco de erro podem ajudar a
encontrar a falta do componente. Para um
componente de hardware, essa localizao deve ser
precisa, com o reparo sendo feito pela substituio
do componente. Uma falta de software pode ser
removida em uma nova verso do cdigo.

Blocos
de Recuperao:
Tcnica de recuperao de erro para trs.

Blocos
de recuperao so blocos no
sentido de uma linguagem de programao
normal, exceto que a entrada de um bloco
um ponto de recuperao automtico e a
sada um teste de aceitao. Teste de
aceitao usado para testar se o sistema
est em um estado aceitvel depois da
execuo do bloco, ou mdulo primrio,
como geralmente chamado.
O escopo de cdigo abaixo apresenta um exemplo de bloco de

recuperao:
Ensure (teste de aceitao)
By
(mdulo primrio)
Else by
(mdulo alternativo)
Else by
(mdulo alternativo)
Else by
(mdulo alternativo)
Else error
Exceo:
Vimos anteriormente que um erro uma
manifestao de uma falta, e que uma falta um
desvio de especificao de um componente. Os
erros podem ser antecipados ou no antecipados.
Uma exceo pode ser definida como a ocorrncia
de um erro. A apresentao de uma condio de
exceo para o invocador da operao chamada
de raising the exception (aumentar a exceo) e a
resposta do invocador chamada de handling the
exception (manipulao de exceo).
Abaixo, apresentado um escopo de cdigo que

exemplifica a exceo e sua manipulao.
if chamada_funo(parmetro) = ERRO ento
Cdigo de manipulao de erro
seno
Cdigo de retorno normal
fim;
Software de Tempo Real
Sincronizao e Comunicao baseada em Memria

Compartilhada
A maior dificuldade associada programao concorrente deve-se

interao de processos concorrentes.
A troca de dados ou informaes entre processos chamada de
comunicao entre processos. Essa troca de dados pode ser por varivel
compartilhada ou passagem de mensagem.
A sincronizao de processo pode ser representada por um processo que
deve aguardar pela ao de outro processo ou do prprio sistema.
Varivel compartilhada uma varivel que vrios processos podem
acessar.
Excluso Mtua
Embora variveis compartilhadas sejam uma boa facilidade para

passagem de informaes entre processos, elas apresentam
problemas srios quando h alteraes mltiplas de seus valores.

Como a alterao de seu valor no uma ao nica e indivisvel, a
alterao mltipla pode apresentar leituras erradas de seus valores.
Como exemplo, suponha dois processos que queiram executar a
seguinte atribuio: X = X+1.
A seqncia de estruturas que deve aparecer para ser executada
indivisivelmente chamada de seo crtica. A sincronizao
requerida para proteger uma seo crtica chamada de excluso
mtua.
Condio de Sincronizao
Muitas vezes, um processo deve esperar at que outro processo

execute certa ao. Nesse caso, no h necessidade de excluso
mtua, pois os dois processos no concorrem a uma varivel nica.
Esse um caso tpico de condio de sincronizao, em que um
processo deve esperar pela ao de um outro processo.
A implementao de qualquer forma de sincronizao implica

que processos devem, em tempo, serem seguros at que seja
apropriado para prosseguirem. Excluso mtua e condio de
sincronizao devem ser programadas usando busy wait
loops e flags.
Busy Waiting
Um caminho para implementar sincronizao ter processos alterando e

testando variveis compartilhadas que esto atuando como flags.
Para sinalizar uma condio, um processo seta (coloca em um) o valor de uma
flag. Para esperar por esta condio qualquer outro processo testa esta flag, e
prossegue somente quando o valor apropriado lido. Observe o exemplo
abaixo:
process P1; (* processo esperando)

while flag = down do
null
end;
end P1;
process P2; ( * processo sinalizando)
flag: = up
end P2;
Flags e Busy Waiting

Vamos exemplificar excluso mtua atravs de dois processos que tm
mutuamente sees crticas. Vejamos exemplo abaixo:
process P1;
loop
flag1:= down
while flag 2= down do
null
end;
<seo crtica>
flag1:=up;
<seo no-crtica>
end
end P1;
process P2; loop
flag2:= down
null
end;
<seo crtica>
flag2:=up;
<seo no-crtica>
end
end P2;
Qual fenmeno acontece nesse algoritmo?

Vejamos outro exemplo de excluso mtua:
process P1;
loop
null
end;
flag1:= down
<seo crtica>
flag1:=up;
<seo no-crtica>
end
end P1;
process P2;
loop
null
end;
flag2:= down
<seo crtica>
flag2:=up;
<seo no-crtica>
end
end P2;
O que acontece nesse algoritmo?

Vejamos outro exemplo de excluso mtua:
process P1;
loop
while turn= 2 do
null
end;
<seo crtica>
turn:=2;
<seo no-crtica>
end
end P1;
process P2;
loop
while turn = 1 do
null
end;
<seo crtica>
turn:=1;
<seo no-crtica>
end
end P2;
Resolve o problema de excluso mtua e livelock?

Vejamos outro exemplo de excluso mtua proposto por Peterson, em 1985:
process P1;
loop
flag2:= up;
turn:= 2;
while flag2 = up turn = 2 do
null
end;
<seo crtica>
flag1:= down;
<seo no-crtica>
end
end P1;
process P2;
loop
flag1:= up;
turn:= 1;
while flag1 = up turn = 1 do
null
end;
<seo crtica>
Flag2:= down;
<seo no-crtica>
end
end P2;
Semforo
Utilizado para implementar excluso mtua e condio de

sincronizao.
Eles foram originalmente desenvolvidos por Dijkstra, em 1986,

e tem as seguintes vantagens:
Eles simplificam os protocolos para sincronizao;
Eles removem a necessidade de busy wait loops.

Semforo
Um semforo uma varivel inteira no negativa que,

excluindo a inicializao, pode ser operada por dois
procedimentos. Esses procedimentos so chamados de P e
V por Dijkstra, mas so referenciadas por wait e signal por
outros autores. As semnticas de wait e signal so as
seguintes:
WAIT (S) : Se o valor do semforo, S, maior do que zero,
ento decrementa seu valor de um. Caso contrrio, atrasa o
processo at S ficar maior do que zero (e ento decrementa
seu valor).
SIGNAL (S) : incrementa o valor do semforo, S, de um.
Semforo
Uma propriedade importante de wait e signal que suas aes so

atmicas (indivisveis). Dois processos executando operaes wait no
mesmo semforo no podem interferir entre eles. Outra vantagem
que um processo no pode falhar durante a execuo de uma
operao semforo.
Semforo
Condio de sincronizao utilizando semforo:
(* condio de sincronizao*)
var consyn: semforo; (*inicializado com 0*)
process P1; (*processo esperando*)
wait (consyn);
end P1;
process P2; (*processo sinalizando*)
signal (consyn);
end P2;
Semforo
Excluso mtua utilizando semforo:
(* excluso mtua*)
var mutex: semforo; (*inicializado com 1*)
process P1;
loop
wait (mutex);
<seo crtica>
signal (mutex);
<seo no crtica>
end
end P1;
process P2;
loop
wait (mutex);
<seo crtica>
signal (mutex);
<seo no crtica>
end
end P2;
Semforo:
Na definio de wait est claro que se o semforo 0, ento

processo deve ser atrasado. Um mtodo de atraso (busy wait)
foi comentado anteriormente, mas apresentava problemas.
Todas as primitivas de sincronizao negociam com atrasos pela
remoo do processo do conjunto de processos executveis.
Um novo estado de suspenso (algumas vezes chamado de
bloqueado ou no executvel) necessrio.
Quando um processo executa um wait em um semforo em 0, o
RTSS(Run Time Support System) invocado, e o processo
removido do processador, e colocado na fila de processos
suspensos (que a fila de processos suspensos em um
semforo particular). No exemplo abaixo, apresentado como o
processo suspenso.
Semforo:
WAIT (S) :
if S > 0 then
S:= S - 1
else
nmero suspenso:= nmero suspenso +1
suspende processo chamador
SIGNAL(S) :
if nmero suspenso > 0 then
nmero suspenso:= nmero suspenso -1
coloca o processo suspenso como executvel novamente
else
S:= S + 1
Deadlock:
O uso de semforo pode causar o conceito de deadlock. Ou

seja, um ou mais processos suspensos por tempo infinito ou
indeterminado.
O exemplo abaixo apresenta o conceito de deadlock:
P1
P2
wait (S1);
wait (S2);
wait (S2);
wait (S1);
signal (S2);
signal (S1);
signal(S1);
signal (S2);

Starvation:
Outro problema menos srio que ocorre com a utilizao de

semforos o conceito de starvation. Esse problema
caracterizado por um processo que deseja ganhar acesso a
um recurso, via seo crtica, e nunca permitido acessar tal
recurso, pois h outro processo que sempre ganha acesso
antes dele.
Semforos Binrios:
Em todos os exemplos adotados at agora, somente os valores 0 e 1

foram utilizados para o semforo. Uma forma simples de semforo,
chamado de semforo binrio, pode ser implementado para adotar
esses valores.
Um semforo binrio pode ser utilizado para prover sincronizao a

apenas um recurso. Como exemplo, 3 processos que concorrem a
apenas um bloco de memria podem utilizar um semforo binrio.

Semforo de Quantidade:
Qualquer outra variao da definio normal de um semforo
chamado de semforo de quantidade. Com essa estrutura o
conjunto a ser decrementado por um wait ou incrementado por
um signal no fixado em 1, mas dado como um parmetro
para as procedures:
WAIT (S, i) :
if S >= i then
S:= S i
else
delay
S:= S i
SIGNAL (S,i) :
S:= S + i
Semforo de Quantidade:
O exemplo abaixo apresenta o uso de um semforo de

quantidade.
procedure allocate (size : integer);
begin
wait(QS, size)
end;
procedure deallocate (size : integer);
begin
signal(QS, size)
end;
No exemplo acima, o semforo deve ser inicializado com o
nmero total de recursos no sistema.
Monitores:
monitor buffer;
export append, take;
const size = 32;
var BUF : array[0size-1] of integer;
top, base : 0size-1;
spaceavailable, itemavailable : condition;
NumberInBuffer : integer;
procedure append (I : integer);
begin
if NumberInBuffer = size then
wait(spaceavailable);
BUF[top] := I;
NumberInBuffer := NumberInBuffer + 1;
top := (top+1) mod size;
signal(itemavailable);
end append;
procedure take (I : integer);
begin
if NumberInBuffer = 0 then
wait(itemavailable);
I:= BUF[base];
base := (base+1) mod size;
NumberInBuffer := NumberInBuffer - 1;
signal(spaceavailable);
end take;
begin (*inicializao*)
NumberInBuffer := 0;
top := 0;
base := 0;
end;
Monitores:
Abaixo, apresentado exemplo de uso de monitor na linguagem MODULA-1.

INTERFACE MODULE resource_control;
DEFINE allocate, deallocate;
VAR busy : BOOLEAN;
Free : SIGNAL;
PROCEDURE allocate;
BEGIN
IF busy THEN WAIT(free) END;
busy := TRUE
END;
PROCEDURE deallocate;
BEGIN
busy := FALSE
SEND(free)
END;
BEGIN (*inicializao do mdulo*)
busy := FALSE
END

Sincronizao e Comunicao baseada em Mensagem
Uma alternativa para comunicao e sincronizao de
processos concorrentes utilizando passagem de mensagem.
A semntica para passagem de mensagem baseada em trs
temas:
- o modelo de sincronizao;
- o mtodo de nomeao de processos;
- e estrutura da mensagem.
Sincronizao de Processos
Variaes no modelo de sincronizao de processos so baseadas
na semntica do processo (sender) origem ou remetente, que podem
ser classificadas da seguinte maneira:
Assncrono: o processo origem ou remetente prossegue
imediatamente, desconsiderando se a mensagem foi recebida ou
no;
Sncrono: o processo origem ou remetente somente prossegue
quando a mensagem for recebida;
Invocao remota: o processo origem ou remetente somente
prossegue quando um retorno (replay) for enviado pelo processo
receptor ou destinatrio. O paradigma requisio de resposta de
comunicao modelado pelo envio de invocao remota e
encontrada em ADA e em vrios sistemas operacionais.
Modelo sncrono conseguido de modelo assncrono:
P1
asyn_send(message)
wait(acknowledgement)
P2
wait (message)
asyn_send(acknowledgement)
Modelo de invocao remota conseguido com

modelo sncrono:
P1
syn_send(message)
wait(replay)
P2
wait (message)
constri replay
syn_send(replay)
Nomeao de Processos (Process Naming)
Nomeao de processos envolve dois sub-temas: direo

versus indireo, e simetria. No esquema de nomeao
direta, o emissor da mensagem explicitamente nomeia o
receptor:
send (message) to (process-name)
Com esquema de nomeao indireta, o emissor ou origem
nomeia alguma entidade intermediria (conhecida por canal,
mailbox, link ou pipe).
send (message) to (mailbox)
Um esquema de nomeao simtrico se ambos, emissor e receptor,

nomeiam cada um (direta ou indiretamente).
send (message) to (process-name)

wait (message) from (process-name)
send (message) to (mailbox)
wait (message) from (mailbox)
O esquema assimtrico se o receptor no nomeia nenhuma fonte

especfica, mas aceita mensagem de qualquer processo ou entidade
intermediria. Veja exemplo abaixo:
wait (message)
Nomeao assimtrica encaixa-se no paradigma cliente-servidor, no
qual o processo servidor produz servio em resposta a mensagens de
qualquer nmero de processos clientes. No entanto, uma
implementao deve suportar uma fila de processos esperando pelo
servidor.
Estrutura de Mensagem
Idealmente, uma linguagem deveria permitir qualquer objeto de

dado de qualquer tipo definido para ser transmitido em uma
mensagem. Obter esse ideal muito difcil, particularmente se
objetos de dados tm representaes diferentes no emissor
(origem) e no receptor (destino). E ainda mais se as
representaes incluem ponteiros. Por causa dessa
dificuldade, algumas linguagens, como OCCAM, tm restrio
no contedo de sua mensagem para dados no-estruturados,
exige objetos de tamanho fixo e de tipos definidos pelo
sistema.
Espera seletiva (Seletive Waiting)
uma forma de passagem de mensagem no qual o processo destino

deve esperar at que um processo especfico ou canal libera uma
mensagem.
Exemplo de espera seletiva em OCCAM:

While true
Alt
ch1 ? I
chout ! I
ch2 ? I
chout ! I
ch3 ? I
chout ! I
Exemplo de espera seletiva em C Paralelo:

CHAN *CAN[3];
int x, y;
x = alt_wait(3, CAN[0], CAN[1], CAN[2]);
chan_in_word(&y,CAN[x]);
Ao Atmica
Em uma aplicao em que processos concorrem a recursos comuns,

o conceito de ao atmica deve estar bem claro.
Ento, podemos conceituar uma ao atmica como:

Uma ao atmica se o processo desempenhando a ao
no se preocupa com a existncia de qualquer outro processo
ativo, e nenhum outro processo ativo se preocupa com a
atividade do processo durante o tempo que o processo est
desempenhando a ao.
Ao Atmica
Outro conceito tambm pode ser apresentado para ao
atmica. Uma ao atmica se o processo desempenhando
a ao no troca informaes com outros processos enquanto
a ao est sendo desempenhada. Ou, uma ao atmica se
o processo desempenhando a ao no detecta nenhuma
alterao de estado, exceto aquele desempenhado pela
prpria ao, e se no revela sua alterao de estado at o
trmino da ao.
Um conceito simplificado para ao atmica pode ser
apresentado como segue: uma ao dita atmica se ela
vista pelo sistema como instantnea e indivisvel.
Aes Atmicas de Duas Fases

Idealmente, todos os processos envolvidos em uma
ao atmica deveriam obter os recursos
requeridos, durante a ao. Esses recursos
poderiam ser desalocados aps a ao atmica
terminar. Se essas regras forem seguidas, ento
no h necessidade para uma ao atmica
interagir com qualquer ente externo, que uma
definio estrita para ao atmica. Infelizmente,
esse ideal pode levar a uma utilizao pobre de
recursos.
Como primeiro passo, necessrio permitir uma ao atmica

iniciar sem seu nmero total de recursos. Em algum ponto, um
processo dentro da ao ir requerer uma alocao de
recurso: a ao atmica deve ento comunicar com o
gerenciador de recurso. Para uma definio estrita de ao
atmica, esse gerenciador de recursos deveria ter que
participar da ao atmica, com o efeito de serializar todas as
aes envolvendo o gerenciador de recursos. Claramente, isso
indesejvel, e ento permitido a uma ao atmica
comunicar externamente com gerenciadores de recurso.

Se recursos podem ser obtidos mais tarde e desalocados mais
cedo poderia ser possvel para uma mudana de estado
externo para ser afetado por um recurso liberado e observado
pela aquisio de um novo recurso. Isto poderia quebrar a
definio de ao atmica. Logo, uma poltica segura para uso
de recursos deve possuir duas fases distintas. Na primeira
fase, chamada de growing phase, recursos so somente
requeridos. Na segunda fase, chamada de shrinking phase, os
recursos podem ser liberados (mas, nenhuma nova alocao
pode ser produzida). Com tal estrutura, a integridade da ao
atmica garantida.
Transaes Atmicas
Dentro da teoria de sistemas operacionais e banco de dados o termo

transao atmica geralmente usado. Uma transio atmica tem
todas as propriedades de uma ao atmica, com uma caracterstica
adicional, sua execuo acontece com sucesso ou falha.
Se uma ao atmica falha ento os componentes do sistema

os quais esto sendo manipulados pela ao devem ser
deixados em um estado inconsistente. Com uma transao
atmica isto no pode acontecer, pois os componentes so
retornados para o estado original. Transaes atmicas so
comumente chamadas de aes recuperveis e, infelizmente,
os termos aes atmicas e transaes atmicas so usados
com o mesmo significado.

As duas propriedades principais de transaes
atmicas so:
- falha de atomicidade: significa que a transao deve
ou completar com sucesso ou no ter nenhum
efeito.
- sincronizao de atomicidade: significa que a
transao indivisvel no sentido que sua execuo
parcial no pode ser observada por qualquer
transao executando concorrentemente.
- Obs: Transaes atmicas so muito utilizadas para
sistema de banco de dados.
Requerimentos para aes atmicas
Se uma linguagem de programao de tempo-real capaz de

suportar aes atmicas, ento deve ser possvel expressar os
requerimentos necessrios para sua implementao. Esses
requerimentos so independentes da noo de processo, e da forma
de comunicao inter-processo produzida pela linguagem. So eles:
- Limites bem definidos: cada ao atmica deveria ter um incio

e um fim, e um limite bem definido de cada lado. O limite de
incio a localizao em cada processo envolvido na ao
atmica em que a ao considerada a iniciar. O limite de fim
a localizao em cada processo envolvido na ao atmica
em que a ao considerada a terminar. O limite de lado
separa esses processos envolvidos na ao atmica do resto
do sistema.
Indivisibilidade: uma ao atmica no deve permitir uma troca de

qualquer informao entre os processos ativos dentro da ao e
aqueles fora da ao. Se duas aes atmicas compartilham dados,
ento o valor destes dados depois das aes determinado por um
seqenciamento estrito das duas aes em alguma ordem.
Aninhamento: aes atmicas devem ser aninhadas desde que
no sobreponham outras aes atmicas. Conseqentemente,

somente aninhamentos estritos so permitidos (duas
estruturas so aninhadas estritamente se uma
completamente contida dentro da outra).
- Concorrncia: deveria ser possvel executar diferentes aes
atmicas concorrentemente. Uma maneira de forar

invisibilidade rodar aes atmicas seqencialmente. O
efeito geral de executar uma coleo de aes atmicas
concorrentemente deveria ser o mesmo que obtido da
serializao de suas execues.
- Procedimentos de recuperao: como a inteno de aes
atmicas a de formar a base para confinamento de danos,
elas devem permitir que procedimentos de recuperao sejam
programados.
Aes atmicas em linguagens concorrentes
- Uso de semforos para se conseguir ao atmica

Veja como podemos implementar uma ao atmica utilizando o
conceito de excluso mtua por semforo:
wait(mutual_exclusion_semaphore)
atomic_action
signal(mutual_exclusion_semaphore)
- Uso
de monitor para se conseguir ao atmica

Atomic_action_begin1, atomic_action_begin2: semaphore :=1;
Atomic_action_end1, atomic_action_end2: semaphore := 0;
Procedure code_for_first_process is
Begin
- Start atomic action
Wait(atomic_action_begin1)
- get resource in non-sharable mode
- update resource
- signal second process that it is ok
- for it to acess resource
- any final processing
Wait (atomic_action_end2);
- return resource
Signal(atomic_action_end1);
Signal(atomic_action_begin1);
End code_for_first_process;
Procedure code_for_second_process is
Begin
- Start atomic action
Wait(atomic_action_begin2)
- initial processing
- wait for first process to signal
- that it is ok to acess resource
- acess resource
Signal(atomic_action_end2);
Wait (atomic_action_end1);
Signal(atomic_action_begin2);
End code_for_second_process;
Controle de recursos
- A coordenao entre processos deve ser requerida se eles
compartilham acesso a recursos escassos tais como dispositivos
externos, arquivos, campos de dados compartilhados, buffers e
algoritmos codificados. Esses processos so conhecidos como
processos competidores.
- Para que processos concorram a recursos escassos um controle ou

uma gerncia que coordene o acesso dos processos a esses recursos
de suma importncia. Como recursos, podemos citar: dispositivos de
hardware (timer, portas, interface serial), arquivos, blocos de
memrias, campos de dados, entre outros.
Controle de recurso e aes atmicas
Um controle de recursos pode ser realizado por uma troca simples e

confivel de mensagens, no necessitando de uma ao atmica para
isso.
Gerncia de recursos
- Uma das maneiras para se ter um controle de acesso ao recurso
empacotar ou encapsular o recurso. Com isso, consegue-se
sincronizar o acesso dos processos ao recurso. O exemplo abaixo
utilizado pela linguagem ADA:
Package RESOURCE_MANAGER is
type RESOURCE is private;
function ALLOCATE return RESOURCE;
function FREE (THIS_RESOURCE:RESOURCE)
Private
type RESOURCE is ...
End RESOURCE_MANAGER;
Potncia expressiva e facilidade de uso

- Bloom (1979) usa o termo potncia expressiva para
representar a abilidade de uma linguagem de expressar
restries requeridas na sincronizao. Facilidade de uso de
uma primitiva de sincronizao engloba:
- a facilidade de expresso de cada restrio de sincronizao;
- a facilidade com o qual ele permite a restrio para ser
combinada em ordem para conseguir esquemas de
sincronizao mais complexos.

Deadlock
- Situao comumente encontrada quando alguns processos

concorrem a um nmero finito de recursos. Como exemplo, um
processo P1 est usando o recurso R1, enquanto espera o acesso ao
recurso R2. Se um processo P2, que est usando o recurso R2,
tambm quiser acesso ao recurso R1, tem-se um caso de deadlock.
Uma das maneiras de se evitar o deadlock no implementar o hold
and wait.
Exemplo:
P1
P2
Main()
Main()
allocate (R1)
allocate (R2)
allocate (R2)
allocate (R1)
Recursos de Tempo-Real
Abaixo, seguem alguns recursos importantes de tempo-real:
- Acesso ao clock;
- Retardo de processos;
- Implementao de Timeout;
- Especificao de prazo de encerramento (deadline) e
escalonamento.
Acesso ao Clock
- Para aplicaes de tempo-real importante que a linguagem
a ser utilizada interaja de alguma maneira com o tempo. Ou
seja, tendo acesso de alguma maneira a informao do tempo
ou, pelo menos, a medida do tempo que j passou.
Isso pode ser feito de duas maneiras:
- Implementando funes de acesso ao clock na linguagem;
- Implementando um driver de dispositivo de clock associado
aos processadores ou microcontroladores.
Exemplo 1 de acesso ao clock em OCCAM:

TIMER clock:
INT Time:
SEQ
clock ? Time

- Exemplo 2 de acesso ao clock em OCCAM:
TIMER clock:
INT old, new, interval:
SEQ
clock ? Old
other functions
clock ? new
interval := new MINUS old
- Exemplo 3 de acesso ao clock na linguagem C para o

PIC:
Get_timer0();
Get_timer1();
Restart_wdt();
Atrasando um Processo
- Alm do acesso ao clock do sistema, processos em aplicaes de
tempo-real devem tambm ser capazes de se atrasarem por um
perodo de tempo. Esse procedimento pode ser realizado atravs do
seguinte exemplo:
NOW:= CLOCK;
Loop
exit when (clock-NOW) > 10.0;
End Loop;

- Muitas linguagens apresentam funes de atraso que
eliminam os busy waits. Ada apresenta a seguinte funo:
delay 10.0; espera dez segundos
- Em linguagem C para PIC, temos a seguinte funo:
delay_ms(1000); espera um segundo. Essa funo
implementada com busy wait loop, e h processamento na espera.

Implementando Timeout
Um timeout uma restrio no tempo de um processo que est

esperando por um evento. A utilizao de timeout de suma
importncia para deteco em falhas na passagem de mensagens
entre processos, na eliminao de deadlocks, entre outros.
Implementando Timeout em ADA:

task CONTROL is
entry CALL(V:VOLTAGE)
end CONTROL;
task body CONTROL is
begin
loop
select
accept CALL(V:VOLTAGE) do
NEW_VOLT:=V;
end CALL;
or
delay 10.0;
end select;
end loop;
end CONTROL;
Exemplo de espera com timeout em C para PIC:

boolean erro_timeout;
char getc_timeout();
{
long int tempo;
erro_timeout = false;
while(!kbhit() && (++tempo<500) delay_ms(10);
if (kbhit()) return (getc());
else{
erro_timeout = true;
return (0);
}
}
Obs: A funo KBHIT verifica se h algum dado sendo recebido pela
USART (serial padro).
Exemplo de timeout em OCCAM:

WHILE TRUE
SEQ
ALT
call ? new_voltage
-- outras aes
clock ? time
-- ao para timeout
Deadline (Prazo de Encerramento)

- Antes, temos que falar primeiro sobre alguns conceitos
importantes, como tipos de processos em relao ao tempo.
Existem dois tipos de processos em relao ao tempo:
- Processos peridicos;
- Processos aperidicos ou espordicos.
Obs: ambos processos devem ser analisados para dar seus
tempos de execuo de pior caso.
Para facilitar a especificao dos vrios conceitos em
aplicaes de tempo-real, temos que explicar o que TS
(Temporal Scope Escopo Temporal). Tais escopos identificam
um conjunto de estruturas com uma restrio de tempo
associada.

- Atributos possveis de um TS:
- Deadline: tempo no qual a execuo do TS deve ser finalizada;
- Mnimo delay: o mnimo tempo que deve transcorrer antes do incio
da execuo do TS;
- Mximo delay: o mximo tempo que deve transcorrer antes do
incio da execuo do TS;
- Mximo tempo de execuo: do TS;
- Mximo tempo a transcorrer: do TS.
Na figura abaixo, apresentado um grfico com todos os

atributos de um escopo temporal.
Escalonamento para tempo-real

Escalonamento de processos uma atividade no qual um programa
do kernel do SO seleciona um processo para ser executado pela CPU.
O programa responsvel em fazer o escalonamento o escalonador.
Para um RTOS, o escalonamento deve apresentar quesitos de temporeal. Deve ser pre-emptivo e possuir polticas de escalonamento que
levem em conta os prazos de encerramento (deadlines) dos
processos.
Escalonamentos de tempo-real
Rate Monotonic: Usado para escalonamento de processos perdicos.

Designa prioridade fixa para cada processo com base no seu perodo.
Ou seja, o processo com menor perodo ter maior prioridade.
Earliest Deadline: Nesse algoritmo, o escalonador deve ter
informaes explcitas dos deadlines dos processos. Assim, o
processo com deadline mais prximo, ter maior prioridade.
Least Slack Time: Nesse algoritmo, o escalonador precisa saber no
somente todos os deadlines dos processos, mas tambm o tempo de
execuo requerido para cada processo antes do seu deadline. Ou
seja, o processo com menos tempo livre ter maior prioridade.

588441-Aulas STR 2

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

588441-Aulas STR 2

Diunggah oleh

Hak Cipta:

Format Tersedia

SOFTWARE DE TEMPO-REAL

Professor Paulo Rgis

O que so sistemas de tempo-real?

Sistema em tempo real qualquer sistema no qual o

Exemplos de aplicaes ou sistemas

Bloco de um sistema de tempo-real

muitas interpretaes do conceito

Sistemas de tempo-real hard e soft

Os sistemas de tempo-real ainda podem ser

Exemplos de sistemas de tempo-real

Como exemplo, podemos citar um sistema de

Caractersticas de sistemas de temporeal

todos os sistemas de tempo-real iro

Caractersticas de sistemas de temporeal

A maioria dos problemas associados com o desenvolvimento

Caractersticas de sistemas de temporeal

Operaes com Nmeros Reais

A maioria dos sistemas de tempo-real monitoram ou controlam

Assim, uma linguagem que se prope ao desenvolvimento de

Caractersticas de sistemas de temporeal

Em alguns exemplos de sistemas de tempo-real, uma falha pode

Confiabilidade a probabilidade de operao livre de falhas durante

Caractersticas de sistemas de temporeal

Controle Concorrente de Componentes

Caractersticas de sistemas de temporeal

Linguagens e SOs para tempo-real:

- RTOS: RTLinux QNX, CMX (da CMX company), AMX (da

Caractersticas de sistemas de temporeal

Caractersticas de sistemas de temporeal

Interao com Interfaces de Hardware

Sistemas de tempo-real interagem intimamente com o mundo

Caractersticas de sistemas de temporeal

Desde que sistemas de tempo-real so crticos no tempo, uma

programa concorrente pode ser

o objeto ativo de um sistema e

Um processo pode ter uma ou mais linhas de

O processo pode apresentar alguns estados:

- Criado: neste estado, o processo pai est criando a thread que

contraste, processos espordicos so

Na sua forma mais simples, um processo peridico P

Um processo espordico tambm representado

Embora construes para programao concorrente variem de uma

. A estrutura Fork especifica que a rotina projetada deveria iniciar executando

Declarao de Processo Explcito:

O exemplo abaixo foi desenvolvido em linguagem Modula-1.

Confiabilidade e Tolerncia a Faltas

Se um sistema de controle tem que responder a um

Confiabilidade e Tolerncia a Faltas

Existem, em geral, 4 fontes de faltas que podem resultar

Confiabilidade e Tolerncia a Faltas

Diferenciando falta, erro e falha:

Confiabilidade e Tolerncia a Faltas

falta, erro e falha.

Confiabilidade e Tolerncia a Faltas

Confiabilidade e Tolerncia a Faltas

Faltas permanentes: faltas permanentes iniciam

Confiabilidade e Tolerncia a Faltas

Essa tcnica permite eliminar qualquer possibilidade

Confiabilidade e Tolerncia a Faltas

Fault avoidance a tcnica que possibilita limitar a

Confiabilidade e Tolerncia a Faltas

Com relao ao software, faltas podem ser evitadas

Confiabilidade e Tolerncia a Faltas