1

RTSJ - Especificação de JAVA para

Programação em Tempo-Real
Paulo Roberto M. Cunha
paulo.cunha@tj.pa.gov.br

Abstract— Este trabalho1 aborda a especificação de
JAVA para programação em Tempo-Real(RTSJ), que tem
sido um processo realizado pela comunidade Java, patroci-
nado pela empresa Sun Microsystems. Nele são sumariza-
dos aspectos ligados à modificações na especificação da lin-
guagem (necessárias para atender os requisitos de progra-
mação para sistemas em Tempo-Real e distribuídos). Neste
trabalho são apresentadas ainda a definição de termos li-
gados a sistemas de Tempo-Real, as motivações que impul-
sionaram a escolha da linguagem, e o estado atual de sua
disponibilidade comercial.
dos Estados Unidos, iniciando em junho de 1998 e cul-
minando em novembro de 20012 com a publicação da es-
pecificação de Java para Tempo Real – Real Time Spe-
cification for Java (RTSJ). A Sun não vai produzir uma
implementação da especificação – esta tarefa ficou a cabo
da empresa americana TimeSys (www.timesys.com).
Um mérito especial desse grupo foi ter definido, de
forma clara e precisa, um vocabulário para Tempo-Real,
com conceitos antes usados pela comunidade de usuários
e vendedores (practitioners) de forma contraditória, e as
vezes até errônea.

I. I NTRODUÇÃO
II. D IFICULDADES NO D ESENVOLVIMENTO PARA
T EMPO -R EAL

U MA questão natural que surge espontaneamente

com o título deste trabalho é perguntar-se por que
usar Java para aplicações de Tempo-Real.
Portabilidade: Desenvolvedores de sistemas em-
barcados (embedded) de tempo-real freqüentemente
encontram-se tendo de lidar com um certo número de mi-
A plataforma Java tem valor potencial significativo croprocessadores diferentes. É comum encontrar-se mis-
no espaço de aplicações de Tempo–Real, tanto como uma turas de hosts dotados de Motorola 68000, PowerPC, e
linguagem de programação produtiva, quanto como uma Intel 960 em um único laboratório de desenvolvimento.
plataforma portátil de aplicações dentro da miríade de Mesmo dentro de uma família de processadores, a geração
processadores e sistemas operacionais de Tempo–Real. A de código tem de ser direcionada para hosts específicos
perspectiva de reaproveitamento de projetos e de perícia objetivando alcançar altas performances (ex: O PowerPC
de profissionais sob diversas plataformas de processado- 604 necessita de código diferente do que o PowerPC 601).
res e sistemas operacionais na arena de desenvolvimento Isso é importante na área de produtos eletrônicos onde
para tempo-real é bastante bem vinda, seja devido a difi- tanto hardware quanto software mudam durante o ciclo
culdade de se treinar novos profissionais, seja pelos custos de vida da família dos produtos. A manutenção das fer-
de adaptar um sistema já existente para uma nova plata- ramentas apropriadas para trans-desenvolvimento (cross-
forma. development) para todos esses diferentes hosts é que se
pode chamar de um “ pesadelo administrativo.” Garan-
Reconhecendo isso, o grupo de peritos em Tempo– tir que todas as combinações componentes de hardware e
Real para Java (Real-Time for Java Expert Group - RT- software trabalhem corretamente no sentido de tempo-real
JEG) organizou uma série de workshops, sob o patrocí- é um desafio bastante difícil. O processo de desenvolvi-
nio do Instituto Nacional de Padrões e Tecnologia (NIST) mento seria muito mais fácil se os programadores pudes-
sem escrever seus códigos em uma linguagem que fosse


Trabalho apresentado na disciplina Programação de Objetos Dis-

tribuídos no Curso de Mestrado em Engenharia Elétrica (Computação O RTSJ teve a distinção de ser a primeira Java Specification Re-
Aplicada) ministrada pelo Prof. Dr. Rodrigo Quites, na Universidade quest (JSR 1), embora não tenha sido a primeira requisição a ter sido
Federal do Pará (UFPa), Jan.,2003. feita.

portátil entre todas essas arquiteturas, mantendo uma ver-
são única de seus sistemas.
Adaptabilidade Dinâmica: Outra dificuldade
freqüente na manutenção de sistemas em tempo-real em-
barcados é que os refinamentos de software incrementais
tem de ser instalados sem que o sistema seja desligado
para uma reinicialização completa. Isso inclui aplicações
que tem de prover serviços ininterruptos para sua comu-
nidade de usuários (ex.: controle de tráfego aéreo, cen-
trais comutadoras de telefonia, e reconhecimento militar),
e aplicações para as quais o custo de desligamento (down-
time) são proibitivos (ex.: controle de reatores nucleares,
e sistemas de automação de manufatura).
Tolerância à Falhas: Na presença de falhas no nó
ou na rede, freqüentemente torna-se necessário redistri-
buir informações e carga de trabalho. Seria bastante de-
sejável poder dispor de um ambiente de execução no qual
fosse permitido, de forma transparente (ou o mais sim-
ples possível), realizar essa transferência, mesmo consi-
derando que os outros nós podem conter arquiteturas e
sistemas operacionais heterogêneos, tornando-os capazes
de executar quaisquer das tarefas que precisem ser execu-
tadas.
III. P OR QUE JAVA ?
O que poucas pessoas sabem, ou lembram, é que ori-
ginalmente a linguagem Java foi criada como parte de
um projeto de pesquisa para desenvolvimento de software
avançado para uma larga variedade de “dispositivos” in-
terconectados em rede e sistemas “embarcados” (embed-
ded systems). O objetivo era desenvolver um ambiente
operacional pequeno, confiável, portátil, distribuído, e de
tempo–real [11], uma resposta aos desafios de desenvolvi-
mento de aplicações dentro do contexto de ambientes dis-
tribuídos em redes, e heterogêneos. Dentre os desafios, a
entrega segura de aplicações que consumissem o mínimo
de recursos, fossem capazes de rodar em qualquer plata-
forma de harware e software, e pudessem ser estendidas
dinamicamente eram as de maior relevância [11].
O projeto de pesquisa inicialmente escolheu usar C++
para o desenvolvimento.Subseqüentemente os desenvol-
vedores encontraram tantas dificuldades com C++ até o
ponto de decidirem que seria melhor projetar um ambi-
Resumindo, o Grupo de Requerimentos considerou as
ente de linguagem totalmente novo. Passando por alguns
pontuações abaixo como sendo uma base para os reque-
percalços iniciais, Java surge a partir dessa decisão.
rimentos e motivações para uso de Java pela comunidade
Java oferece um certo número de melhoras em rela- de Tempo–Real [4]:
ção ao desenvolvimento de software em linguagens popu-
lares como C e C++ [9]:
2
¯ Java empresta das linguagens C e C++ a sintaxe fa-
miliar. Tal como C++, Java é orientada para objetos,
embora seja mais simples que C++ por decisão inten-
cional de seus projetistas em descartar características
que, segundo [9], estavam presentes primeiramente
para dar suporte à retrocompatibilidade com código
legado. Um benefício adicional da sua simplicidade
é o tamanho pequeno do seu sistema de tempo-de-
execução. Existem relatos da Sun alegando que o
interpretador básico tem cerca de 40 Kbytes, e a bi-
blioteca básica e o suporte à thread somam aproxi-
madamente 175 Kbytes [11].
¯ O ciclo de desenvolvimento tende a ser mais rápido
devido ao fato de Java suportar implementações in-
terpretadas e compiladas através do método just-in-
time. Durante o desenvolvimento e prototipação rá-
pida os desenvolvedores podem economizar tempo
usando o interpretador.
¯ Os softwares aplicativos são mais portáteis porque o
ambiente Java especifica cuidadosamente uma repre-
sentação intermediária baseada em byte-code inde-
pendente de máquina a qual pode ser transferida en-
tre nós heterogêneos de rede e interpretada ou compi-
lada sob demanda para código-nativo pelo ambiente
local de tempo-de-execução Java.
¯ Os softwares aplicativos são mais robustos devido ao
fato de o ambiente de tempo-de-execução prover ge-
rência de memória (garbage-collection) automática.
Embora essa seja uma característica bastante dese-
jável por eliminar a possibilidade de ocorrência de
ponteiros perdidos e vazamento de memória, para
sistemas em tempo-real essa gerência deve ser re-
pensada devido às implicações que ela causa devido
a sua natureza não determinística no modelo inicial
proposto pela Sun Microsystems.
¯ Aplicações são adaptáveis à ambientes em mudança
já que é possível baixar (download) dinamicamente
módulos de código a partir de outros nós da rede sem
necessidade de reiniciar o sistema.
¯ A segurança é imposta por proteções embutidas no
ambiente contra vírus e outras tentativas indevidas de
interferência. Essa proteção é implementada através
de simples “provadores de teoremas” que analisam
módulos de byte-code baixados através da rede antes
de tentar executá-los.
¯ O alto nível de abstração presente em Java conduz
 3

a uma melhora na produtividade dos programadores pela criação da especificação de Java para Programação
(embora reconheça que o compromisso (trade–off) em Tempo-Real:
comprometa a eficiência de tempo de execução (run-
time efficiency). ¯ Advanced Logic Corp.
¯ Java é relativamente mais fácil de ser dominada do ¯ Bay Networks / Bay Architecture Lab
que C++. ¯ Hewlett-Packard Company
¯ Java é relativamente segura, mantendo componentes ¯ Honeywell Inc.
3
de software (incluindo a própria JVM ) protegidos ¯ IBM Corp.
entre si. ¯ Lexmark International, Inc.
¯ Java suporta o carregamento dinâmico de novas clas- ¯ Microsoft
ses. ¯ The Mitre Corporation
¯ Java é altamente dinâmica, oferecendo suporte à cri- ¯ Mitsubishi Electric Corporation
ação de objetos e dethreads em tempo de execução. ¯ Motorola, Inc.
¯ Java foi projetada para dar suporte à integração de ¯ Nokia Research
componentes e reutilização. ¯ Nortel
¯ As tecnologias ligadas à Java foram desenvolvidas ¯ QNX Software Systems, Ltd.
com considerações criteriosas, utilizando conceitos e ¯ Rockwell Collins
técnicas que foram escrutinizadas pela comunidade. ¯ Siemens AG, A&D
¯ A linguagem de programação Java e a plataforma ¯ Sony
Java dão suporte à portabilidade de aplicações. ¯ SRI International
¯ As tecnologias ligadas à Java dão suporte a criação ¯ Sun Microsystems, Inc.
de aplicações distribuídas. ¯ The MITRE Corporation
¯ Java oferece uma semântica de execução bem- ¯ The Open Group
definida. ¯ Xerox Corporation

Muito embora isso não seja um fator decisivo no sucesso

IV. O G RUPO DE R EQUISITOS
O Instituto Nacional de Padrões e Tecnologia (NIST)
dos Estados Unidos patrocinou o Grupo de Requisitos
para Extensões de Tempo-Real para Plataforma Java. O
Grupo de Requisitos (Requirements Group) incluiu repre-
sentantes das companhias e organizações cuja capacidade
técnica abrangem a indústria da computação e a academia
[4].
O objetivo do grupo foi desenvolver requisitos inter-
disciplinares para funcionalidades voltadas para Tempo-
Real necessárias para uso em aplicações escritas na lin-
guagem de programação Java e sendo executadas em vá- lar: O RTSJ não deverá incluir especificações que restrin-
rias plataformas diferentes.
A. Empresas Participantes da Especificação
ou fracasso de uma tecnologia (e sim as forças de mer-
cado) mas o aval de grandes empresas em uma especifica-
ção empresta um pouco de suas reputações a ela.
V. P RINCÍPIOS NORTEADORES DO T RABALHO DO
RTJEG
Os princípios norteadores são declarações de alto ní-
vel que delimitam o escopo do trabalho do RTJEG e intro-
duzem requisitos de compatibilidade para A Especificação
de Tempo-Real para Java.
Aplicabilidade a um Ambiente Java em Particu-
jam seu uso a ambientes Java específicos, tais como uma
versão particular do Java Development Kit (JDK), o Em-
bedded Java Application Environment, ou o Java 2 Micro
Edition
 .

Um indicador do grau de importância de uma dada Retrocompatibilidade: O RTSJ não deverá impedir
tecnologia é o número de empresas (especialmente gran- que programas Java já existentes, escritos de forma apro-
des empresas) interessadas nela. Cada uma das empre- priada e sem a característica de Tempo-Real, sejam exe-
sas listadas abaixo participou diretamente, através de um cutados em implementações do RTSJ.
ou mais representantes, do grupo de trabalho responsável
Write Once, Run Anyware: O RTSJ deve reco-

Java Virtual Machine nhecer a importância do paradigma “Write Once, Run
 4

Anywhere” – (WORA) (escreva uma vez, execute em qual- ser entregues dentro de um intervalo de tempo bem defi-
quer lugar), mas também deverá reconhecer a dificuldade nido. Um resultado entregue fora desse tempo (tarde de-
de se alcançar WORA para programas de tempo-real, e mais) é tão ruim quanto, ou até mesmo pior do que, um
não tentar aumentar ou manter portabilidade binária às resultado que não é entregue. Os aspectos de temporali-
custas de presibilidade. dade de aplicações para Tempo-Real fazem com que estes
sistemas sejam notoriamente complexos.
Práticas Atuais versus Características Avançadas:
O RTSJ deve considerar as práticas correntes usadas em Os termos chave de computação de Tempo-Real, tais
sistemas de tempo-real, assim como permitir futuras im- como real–time, hard real–time, soft real–time, determi-
plementações para inclusão de características avançadas. nismo, e predisível são freqüentemente usados na comuni-
dade de Tempo–Real de forma mal definida, indefinida ou
Execução Predizível: O RTSJ referenciará a capa- contraditória. Nessa comunidade não existe um consenso
cidade de execução predizível como sua primeira priori- quanto ao significado de “hard” real-time (embora as pes-
dade em todos os compromissos (tradeoffs); Isto poderá soas pareçam acreditar que sabem o significado quando
acontecer, algumas vezes, às custas de medidas típicas de vêem), e “soft real–time” normalmente tido como sendo
performance computacional de propósito geral. do tipo “o que será, será” (um conceito que normalmente
se aplica à sistemas que não sejam de tempo–real).
Nenhuma Extensão Sintática: Objetivando facilitar
o trabalho dos desenvolvedores de ferramentas, e assim
aumentar as chances de se ter implementações dentro de VII. RTSJ E AS Á REAS A MPLIADAS DE JAVA
prazos razoáveis, o RTSJ não introduzirá novas palavras
reservadas (keywords) ou fará outras extensões sintáticas
A especificação final, fruto dos encontros do grupo de
na linguagem Java.
trabalho de paritos (RTJEG), resultou no que ficou conhe-
cido como Real-Time Specification for Java (RTSJ) [3], e
Permitir Variação nas Decisões de Implementa-
nela são feitas algumas ampliações na definição original
ção: O RTJEG reconhece que as implementações do
da linguagem Java, as quais são descritas abaixo:
RTSJ podem variar em um número de decisões de imple-
mentação, tais como o uso de algoritmos eficientes ou não,
compromissos entre eficiência de tempo ou de espaço, in-
clusão de algoritmos de escalonamento não requisitados A. Escalonamento de Thread e Despacho:
na implementação mínima, e variação no comprimento do
caminho para o código para execução de byte-codes. O Projeto: Em face da significante diversidade de mo-
RTSJ não deve obrigar algoritmos ou constantes de tempo delos de escalonamento e despacho, e do reconhecimento
específicas para tal, mas requerer que a semântica da im- de que cada modelo tem ampla aplicabilidade na diversa
plementação seja atingida. O RTSJ oferece aos implemen- indústria de sistemas de tempo-real, ficou definido que
tadores a flexibilidade de criar implementações adequadas deveria haver um mecanismo interno de escalonamento,
para atender os requisitos de seus clientes. mas não seria especificada previamente a natureza de to-
dos (ou mesmo de alguns) possíveis mecanismos de esca-
lonamento. A especificação foi construída permitindo às
implementações proverem algoritmos de escalonamento
VI. C ONCEITOS DE T EMPO -R EAL
não antecipados. As implementações devem permitir a
designação através de programa de parâmetros apropri-
Software para aplicações de Tempo-Real reage a es- ados para o mecanismo de escalonamento subjacente, as-
tímulos de seu ambiente. O estado da aplicação é deter- sim bem como prover quaisquer métodos necessários para
minado pelo ambiente, enquanto que o estado do ambi- a criação, gerenciamento, admissão, e término de threads
ente, a sua vez, é determinado pelo estado da aplicação. Java. Bastante flexibilidade foi deixada no arcabouço de
A aplicação de controle de processo freqüentemente inte- escalonamento de thread objetivando permitir que futu-
rage fortemente com algum processo físico (processo este ras versões da especificação pudessem ser construídas a
sob controle). partir desta versão e permitir o carregamento dinâmico de
módulos de políticas de escalonamento. Um escalonador
Os resultados de uma aplicação para Tempo-Real não base é requerido em todas as implementações, e este deve
somente tem de ser funcionalmente corretos, eles têm de ser familiar aos programadores de tempo-real. Ele será

baseado em prioridades, preemptivo, e deve ter no mínimo usada (tal como atraso médio) e pode aceitar vários valo-
28 prioridades únicas. res para a métrica em uso.
Especificação: Uma das preocupações de programa-
ção para tempo-real é a garantia da execução em tempo,
ou previsível, de seqüências de instruções de máquina.
Vários esquemas de escalonamento nomeiam diferente-
mente essas seqüências de instruções. Nomes comumente
usados incluem threads, tarefas, módulos, e blocos. O
RTSJ introduz o conceito de objeto escalonável. Qual-
quer instância de qualquer classe que implemente a inter-
face Schedulable é um objeto escalonável e seu escalo-
namento e despacho serão gerenciados pela instância de
Scheduler da qual ele tenha uma referência. O RTSJ re-
quer três classes que são objetos escalonáveis:
¯ RealtimeThread,
¯ NoHeapRealtimeThread,
¯ AsyncEventHandler.
Por execução temporalmente adequada de thread
subentende-se que o programador pode determinar por
análise do programa, teste do programa em uma imple-
mentação particular, ou ambos, se threads particulares
sempre completarão sua execução antes de alguma res-
trição temporal. Essa é a essência da programação para
tempo-real:
A adição de restrições temporais às condições
de corretude para a computação.
Por exemplo, para que um programa compute a soma
de dois números, não poderá mais ser aceitável compu-
tar apenas a resposta aritmeticamente correta, mas a res-
posta deverá ser computada antes de um tempo particular.
Tipicamente, restrições temporais são prazos (deadlines)
expressos em tempo relativo ou absoluto.
Usa-se o termo escalonamento (scheduling) ou algo-
ritmo de escalonamento para referir-se à produção de uma
seqüência, ou ordenação, para a execução de uma con-
junto de threads, uma escala (schedule). Essa escala tenta
otimizar uma métrica particular ( uma métrica que possa
medir quão bem o sistema está atingindo as restrições
temporais). Uma análise de realização (feasibility analy-
sis) determina se uma escala tem um valor aceitável para
a métrica.
Por exemplo, em sistemas de tempo-real crítico (hard B. Gerenciamento de Memória:
real-time) a métrica é “número de prazos perdidos”, e o
único valor aceitável para essa métrica é zero. Em siste-
mas de tempo-real leves (soft real-time) outra métrica é mático de memória é uma característica particularmente
5
Muitos sistemas usam prioridade de thread em uma
tentativa de determinar uma escala. Prioridade tipica-
mente é um número inteiro associado com a thread. Es-
ses inteiros informam ao sistema a ordem na qual as thre-
ads devem ser executadas. A generalização do conceito
de prioridade é a elegibilidade de execução. Usa-se o
termo despachar dispatching para referir-se à porção do
sistema que seleciona a thread com a mais alta elegibi-
lidade de execução do conjunto de threads que estejam
prontas para serem executadas. Na prática corrente de sis-
temas de tempo-real, a atribuição de prioridades está tipi-
camente sob controle do programador em oposto ao con-
trole do sistema. No RTSJ cabe ao programador também
a atribuição de prioridades.
O RTSJ requer um número de classes com nomes no
formato <string>Parameters (tais como Scheduling-
Parameters). Uma instância de uma dessas classes de
parâmetros contém uma característica de demanda por re-
curso em particular para ser usada por um ou mais ob-
jetos escalonáveis. Por exemplo, a subclasse PriorityPa-
rameters contém a métrica de elegibilidade de execução
do escalonador básico, ou seja, prioridade. Em algumas
momentos (tempo de criação ou configuração (ou recon-
figuração) de thread), outras instâncias de classes de pa-
râmetros são ligadas à um objeto escalonável. O objeto
escalonável então assume as características dos valores
presentes no objeto parâmetro. Por exemplo, se uma ins-
tância de PriorityParameter que tinha em seu campo de
prioridade o valor representante da mais alta prioridade
disponível for ligada a um objeto escalonável, então esse
objeto assumirá a característica de que ele executará sem-
pre que estiver pronto preferencialmente à todos os outros
objetos escalonáveis ( exceto, é claro, àqueles que tam-
bém possuirem a mais alta prioridade).
O RTSJ especifica ao menos um algoritmo de escalo-
namento e mudança semântica na JVM que suporta exe-
cução previsível, e este deve estar disponível em todas as
implementações de RTSJ. O algoritmo de escalonamento
inicial e default é prioridade-fixa preemptiva com pelo
menos 28 níveis únicos, e será representado em todas as
implementações pela classe PriorityScheduler subclasse
de Scheduler.
Projeto: É reconhecido que o gerenciamento auto-
 6

importante do ambiente de programação Java, e foi bus- definido pelo escopo sintático (o tempo de vida dos
cada uma direção que permitisse, tanto quanto possível, objetos no heap).
que o serviço de gerencia automática de memória pudesse 2) Physical Memory: permite que objetos sejam cri-
ser implementado automaticamente pelo sistema subja- ados em regiões de específicas de memória física
cente e não se intrometesse na tarefa de programação. que tenham características particulares importantes,
tais como memória que tenha velocidade de acesso
Existem diversos algoritmos de gerenciamento auto- substancialmente mais rápida, ou áreas de memória
mático de memória, também conhecidos como garbage destinadas a mapeamento de dispositivos.
collection (GC), e muitos deles acomodam-se a certas 3) Immortal Memory: representa uma área de me-
classes de estilos e sistemas de programação para tempo- mória que contém objetos que, uma vez alocados,
real. Em uma tentativa de acomodar um conjunto diverso passam a existir durante toda a execução da apli-
de algoritmos de GC foi buscado definir-se uma especifi- cação, ou seja, os objetos são imortais. Imortal-
cação alocação e retomada de memória que: Memory é um recurso de memória compartilhado
entre todas as threads em uma aplicação. Obje-
¯ fosse independente de qualquer algoritmo de GC em tos alocados em ImortalMemory só são liberados
particular, quando o ambiente de execução Java (Java run-time
¯ permitisse o programa caracterizar de forma precisa environment) termina, e nunca são alvo de garbage-
o efeito de um algoritmo implementado de GC no collecting ou de movimentação.
tempo de execução, preempção, e despacho de thre- 4) Heap Memory: representa uma área de memória
ads Java de tempo- real, e que é o heap. O RTSJ não muda o determinante
¯ permitisse a alocação e retomada de objetos fora de do tempo de vida dos objetos presentes no heap.
qualquer interferência de qualquer algoritmo de GC. O tempo de vida ainda é determinado pela visibi-
lidade.
Especificação: Garbage-collected memory heaps
sempre foram considerados um obstáculo para programa-
ção para tempo-real devido às latências imprevisíveis in- C. Sincronização e Compartilhamento de Recursos:
troduzidas pelo garbage-collector. O RTSJ responde essa
questão provendo várias extensões ao modelo de memó- Projeto: A lógica de programação freqüentemente
ria as quais dêem suporte ao gerenciamento de memória necessita compartilhar recursos serializáveis. Sistemas
de uma forma que não interfira com a habilidade do có- para tempo-real introduzem uma complexidade adicio-
digo de tempo-real prover comportamento determinístico. nal: inversão de prioridade. Foi decidido que a especi-
Este objetivo é alcançado através da permissão da aloca- ficação menos intrusiva para permitir sincronização se-
ção de objetos fora do heap do garbage-collector tanto gura em tempo-real é requerer qua as implementações de
para objetos de curto quanto de longo tempo de vida: synchronized (palavra reservada da linguagem Java)
inclua um ou mais algoritmos que previnam inversão de
Memory Areas: O RTSJ introduz o conceito de área prioridade entre threads Java de tempo-real que compar-
de memória. Uma área de memória representa uma área tilhem o recurso serializado. Foi notado também que em
da memória que pode ser usada para alocação de obje- alguns casos o uso da palavra reservada synchronized
tos. Algumas áreas de memória existem fora do heap e implementando o algoritmo requerido de inversão de pri-
impõem restrições sobre o que o sistema e o garbage- oridade não é suficiente nem para prevenir inversão de pri-
collector podem com os objetos alocados nestas áreas. oridade nem permitir uma thread ter uma elegibilidade de
Objetos em algumas áreas de memória nunca são co- execução logicamente mais alta que o carbage collector.
letados pelo garbage-collector, entretanto, o garbage- É provido um conjunto de classes de filas livres de espera
collector tem de ser capaz de vasculhar essas áreas de me- (wait-free queue classes) a serem usadas em tais situações.
mória em busca de referências a quaisquer objetos dentro
do heap para preservar a integridade do heap. Especificação: Em particular o termo highest
priority thread indica meramente a thread mais elegível,
Existem quatro tipos básicos de áreas de memó- ou seja, a thread a qual o despachante (ıdispatcher)
ria: escolheria entre todas as threads que estão prontas
para serem executadas, e não presume necessariamente
1) Scoped Memory: provê mecanismos para tratar um mecanismo de despacho baseado estritamente em
com classes de objetos que tem um tempo de vida prioridade.

Wait Queues: Threads esperando para adquirir con-
trole sobre um recurso devem ser liberadas em ordem
de elegibilidade de execução. Isso tanto se aplica ao
processador quanto a blocos sinconizados. Caso threads
com a mesma elegibilidade de execução sejam possíveis
dentro da política de escalonamento ativa, tais threads são
acordadas em ordem FIFO. Por exemplo:
¯ Threads esperando para entrar em blocos synchroni-
zed tem acesso garantido ao bloco sincronizado em
ordem de elegibilidade de execução.
¯ Uma thread bloqueada que se torna pronta para exe-
cutar recebe acesso ao processador em ordem de ele-
gibilidade de execução.
¯ Uma thread cuja elegibilidade de execução é expli-
citamente configurada (set) por si mesma ou por ou-
tra thread recebe acesso ao processador em ordem de
elegibilidade de execução.
¯ Uma thread que executa o comando yeld( ) abrindo
mão de seu uso do processador receberá novamente
acesso ao processador após esperar por threads de
mesma elegibilidade de execução.
¯ Threads que sejam relocadas (preempted) em favor
de uma thread com maior elegibilidade de execução
podem receber acesso ao processador em qualquer
momento assim determinado por uma implementa-
ção particular. A implementação é requisitada em
prover documentação declarando exatamente o algo-
ritmo usado para garantir tal acesso.
essa é a lógica a ser seguida.
Evitando Inversão de Prioridade: Todas as imple-
mentações de RTSJ devem prover uma implementação
da primitiva synchronized com um comportamento
padrão que garanta que não ocorra inversão de prioridade
descontrolada. Além disso, essa regra deve aplicar-se à
código se for executado com a implementação assim bem
como com threads de tempo-real. O protocolo de herança
de prioridade tem de ser implementado por default. O
protocolo de herança de prioridade é um algoritmo bem
conhecido dentro da literatura de escalonamento de
tempo-real e tem o seguinte efeito:
Caso a thread ½ tente ganhar controle so-
bre um lock que está sendo mantido por uma
thread ¾ de prioridade mais baixa, então a pri-
oridade de ¾ é elevada ao nível da de ½ en-
quanto ¾ mantenha controle sobre o lock ( e
recursivamente caso a própria ¾ esteja espe-
rando para ganhar controle sobre uma lock man-
7
tida por uma thread com prioridade ainda mais
baixa ).
Questões associadas à sincronização entre
thread de tempo-real e threads regulares de
Java podem surgir nesse contexto. O RTSJ
provê três filas do tipo livre-de-espera (wait-free
queue) para prover acesso compartilhado a ob-
jetos acessados tanto por threads Java regulares
quanto por NoHeapRealtimeThreads. Essas
classes são providas explicitamente para permi-
tir comunicação entre a execução de tempo-real
de NoHeapRealtimeThreads e threads Java
regulares.
D. Gerenciamento de Eventos Assíncronos
Projeto: Sistemas de tempo-real tipicamente intera-
gem de perto com o mundo real. A respeito da execução
da lógica, o mundo real é assíncrono. Isso compeliu o
RTJEG a incluir mecanismos eficientes para disciplinas
de programação que pudessem acomodar essa assincronia
inerente. O RTSJ generaliza o mecanismo da linguagem
Java de gerencia de eventos assíncronos. Classes reque-
ridas representam coisas que possam acontecer e a lógica
que é executada quando essas coisas acontecem. Uma ca-
racterística notável é que a execução da lógica é escalo-
nada e despachada por uma escalonador implementado.
Espeficifcação: A estrutura de eventos assíncronos é
composta de duas classes:
¯ AsyncEvent
¯ AsyncEventHandler
Um objeto AsyncEvent representa algo que possa acon-
tecer, como um signal POSIX, uma interrupção de hard-
ware, ou um evento computado tal como um avião en-
trando em uma região específica. Quando um desses even-
tos ocorre, que é indicado pela execução do método fire( ),
os métodos associados handleAsyncEvent( ) de instân-
cias de AsyncEventHandler são escalonados e dessa
forma realizam a lógica requerida.
Uma instância de AsyncEvent gerencia duas coi-
sas:
1) o desbloqueio de handlers quando o evento é dispa-
rado,
2) o conjunto de handlers assossiados ao evento. Este
conjunto pode ser questionado, ter handlers adicio-
nados ou removidos.
 8

Uma instância de AsyncEventHandler pode ser pensada
como bastante similar a uma thread. Quando um evento é
disparado, os handlers são executados assincronamente,
escalonados de acordo com os ReleaseParameters e
SchedulingParameters de uma forma que parece como
se o handler tenha assumido a sua própria thread.
Pretende-se que o sistema possa lidar bem com si-
tuações onde haja um grande número de instâncias de
AsyncEvent e AsyncEventHandler (dezenas de milha-
res). O número de handlers disparados (em processo) deve
ser menor. Uma forma especializada de AsyncEvent é a
classe Timer a qual representa um evento cuja ocorrên-
cia é dirigida pelo tempo. Existem dois tipos de Timers:
O tipo OneShotTimer e o PeriodicTimer. Instancias de
OneShotTimer disparam uma vez, em um momento es-
pecífico. Timers periódicos disparam em momentos espe-
cíficos e então periodicamente de acordo com um inter-
valo especificado.
Os Timers são dirigidos por objetos do
tipo Clock. Existe um objeto Clock especial,
Clock.getRealtimeClock( ) que representa o reló-
gio de tempo-real. A classe Clock pode ser extendida
para representar outros clocks que o sistema possa
tornar disponíveis (tais como um soft clock com alguma
granularidade).
do mecanismo tradicional, inseguro, e obsoleto da lingua-
gem Java de parar threads, o mecanismo do RTSJ para
tratamento de eventos assíncronos e transferência de con-
trole é seguro.
G. Acesso à Memória Física:
Embora não seja diretamente uma questão de tempo-
real, acesso à memória física é algo desejável para mui-
tas das aplicações que pudessem produtivamente fazer uso
de uma implementação do RTSJ. Foi definida então uma
classe que permite aos programadores acesso à memória
física ao nível dos bytes, assim bem como uma classe que
permite a construção de objetos na memória física.
VIII. R EAL -T IME JAVA EM AÇÃO
Recentemente (26 de março de 2002) a revista Ja-
vaWorld realizou uma reportagem sobre o uso de Java para
programação para tempo-real. No artigo Tim Rohaly [10]
faz referência a uma apresentação feita durante a SunOne4
de uma aplicação projetada para “capturar a imaginação”
do público e enfatizar a integração de várias tecnologias
chave da Sun (Web Services, Java para Tempo-Real, e
aplicações Wireless).

A aplicação é composta de uma “luta” ente robôs que

E. Transferência Assíncrona de Controle: foi chamada de “sumo de Robôs” (Fig.1). O sumo de
robôs segue regras semelhantes as da luta de sumo real.
As vezes o mundo real muda tão drasticamente (e as- Dois robôs se enfrentam em uma arena circular, cada qual
sincronamente) que o ponto atual da execução da lógica tentando forçar o outro para fora do ringue. Diferente-
deve ser imediatamente e eficientemente transferido para mente de Battlebots e outros shows de televisão populares
nos Estados Unidos, os competidores do sumo de robôs
outra localização. O RTSJ inclui um mecanismo o qual
não são violentos. A tentativa intencional de causar da-
estende o mecanismo de tratamento de exceção para per-
nos ao oponente é expressamente proibida. Da mesma
mitir às aplicações mudar, através de programação, o local
forma, os robôs não são controlados por seres humanos.
(locus) de controle de outra thread Java. É importante no-
Ao invés disso eles se baseiam em comportamentos pre-
tar que o RTSJ restringe essa transferência assíncrona de
programados (comportamento autônomo) – software é tão
controle à lógica especificamente escrita sob a presunção
importante quanto hardware.
de que o seu local de controle pode mudar assincrona-
mente. O público presente pôde configurar os robôs atra-
vés de “Java-powered wireless phones”, utilizando Sun
ONE (One Network Environment) Web services e wire-
F. Término Assíncrono de Thread: less Ethernet. O 1público poderia escolher enfatizar velo-
cidade sobre agilidade de uma forma familiar aos entusi-
Novamente, devido às mudanças, as vezes drásticas e astas de jogos do tipo role-playing através da divisão de
assíncronas, ocorridas no mundo real, a lógica da aplica- 100 pontos entre as duas categorias.
ção pode ter necessidade de fazer com que uma thread 
Festival anual patrocinado pela empresa Sun Microsystems inc. na
Java de tempo-real transfira segura e convenientemente qual são apresentador seminários de pesquisadores proeminentes, ex-
seu controle para seu escopo mais externo e assim ter- postas aplicações e novas tecnologias emergentes dentro do universo
mine de forma normal. Deve-se notar que diferentemente de produtos da empresa, em especial a linguagem Java.
 9

Os robôs também podiam transmitir vídeo a partir de maduro e portátil de desenvolvimento de aplicações den-
câmeras instaladas sobre si, transmitido através de wire- tro do espaço de aplicação intrinsecamente complexo e
less Ethernet para apresentação ao público. Já que os dispendioso como são as aplicações de tempo-real.
robôs eram autônomos, toda a estratégia e as ações tem
de ser preprogramadas. Este esforço foi bem sucedido em seu intento de criar
uma especificação (RTJEG), posteriormente uma padro-
nização (RTSJ), e por último uma implementação para o
padrão, mas se o RTSJ sobreviverá e onde ele se encai-
xará dentro das teconologias da Sun ainda é algo a ser
visto. Experiências passadas nesta área sugerem que a
Sun MicroSystems tem um bom caminho a trilhar antes
que as “forças de mercado” em última instância tornem
RTSJ bem sucedida.

R EFERENCES

Fig. 1. Corrida de robôs programados com diversas tecnologias Java.
IX. C ONCLUSÕES
Aplicações como as do robô lutador de sumo citadas
anteriormente deixam claro que a linguagem Java pode
ser aplicada fim-a-fim, do banco de dados, através do ser-
vidor de aplicações, web services, conectividade sem fio,
até o interfaceamento Java com o mundo real através de
J2ME/real-time acomodando diversos clientes fim-a-fim.
Embora muitas companhias5 ofereçam soluções de
tempo-real para Java, neste momento apenas uma (aJile
Systems6 ) oferece suporte à RTSJ em seus produtos. A
maioria das empresas que vendem máquinas vituais em-
barcadas (embedded VM) e hardware parecem estar con-
centrando seus esforços mais em J2ME7 e não tem planos
para embarcarem em Java de Tempo-Real. Uma das ra-
zões para isso é que todas elas já oferecem alguma capa-
cidade de tempo-real, portanto não identificam qualquer
razão que as obrigue ou motive para dar suporte imediato
à nova especificação RTSJ. Muitas estão considerando dar
suporte ao RTSJ para o futuro (nos próximos 12-18 me-
ses), mas a maioria está esperando para ver a demanda de
mercado antes de se comprometer com esta nova API.
[1] Allen, D., Standards for Real-Time Distributed Object Compu-
ting. The Edge. MITRE Corporation, 2000.
[2] Bollella, G., Real-Time Java: Status and Architecture.
(www.rtj.org/rtas99/rtas.htm), 1999.
[3] Bollella, G., et. al., The Real-Time Specification for Java - The
Real-Time for Java Expert Group. Addison-Wesley,Upper Sad-
dle River, NJ, 2000.
[4] Carnahan, L.,Ruark, M. (eds.), Requirements
for Real-Time Extensions for the Java Platform.
(www.nist.gov/itl/div897/ctg/real-time/rt-doc/rtj-final-draft.pdf),
National Institute of Standards and Technology, 1999.
[5] Hilderink, G., Bakkers, A., Broenink, J., A Distributed Real-Time
Java System Based on CSP. 3rd IEEE International Symposium
on Object-Oriented Real-Time Distributed Computing, pp. 400-
407, California, 2000.
[6] Interoperable Objects for Distributed Real
Time Systems. Embedded Systems Programming
(www.embedded.com/97/feat9703.htm), 2002.
[7] Jensen, E., The Distributed Real-Time Specification for Java - A
Proposed Initial Approach.(www.drtsj.org), Real-Time and Per-
formance Engineering Section The MITRE Corporation,2000.
[8] Lamport, L. - LATEX A Document Preparation System – User´s
Guide & Reference Manual. Addison-Wesley, Reading, Massa-
chusetts, 1986.
[9] Nilsen, K., Issues in the Design and Implementation of Real-
Time Java.1996.
[10] Rohaly, T., Real-Time Java takes the Stage. JavaWorld,
march,2002.
[11] Sun Microsystems Inc., The Java Language Environment: A
White Paper. Sun Microsystems Inc.:Mountain View, CA, 1995.

Concluímos que a RTSJ é o resultado de um esforço

conjunto, criterioso da comunidade de tempo-real (acade- A PPENDIX
mia e empresas) para prover a criação de um ambiente

aJile Systems, Esmertec, NewMonics, Zucotto Wireless, etc. . . AGRADECIMENTOS

A empresa aJile Systems (www.ajile.com) participou no Grupo
de Peritos para Especificação de Java para Tempo-Real (RTJEG) e atu-
almente trabalha em uma implementação de RTSJ para seus processa-
Este trabalho foi feito usando LATEX. Falar sobre seus
dores Java aJ-80 e aJ-100. méritos quanto à preparação de documentos é chover no

Java 2 Platform, Micro Edition molhado, mas gostaria de deixar registrada aqui minha
 10

profunda admiração pelos autores dos pacotes TEX, Do-

nald E. Knuth e LATEX, Leslie Lamport. Aprender a usá-
los certamente não é uma tarefa trivial, mas certamente o
resultado de longe compensa o trabalho do aprendizado.
Espero que as gerações futuras saibam reconhecer o valor
dessas ferramentas, tão profundamete associadas aos ide-
ais mais nobres que sustentam e promovem o avanço da
ciência da computação.

Agradecemos também ao Prof. Dr. Rodrigo Qui-

tes, do Curso sobre Programação de Objetos Distribuídos,
pelo seu empenho, paciência, profissionalismo e esforço
em tornar esta disciplina interessante e capaz de contribuir
para a formação dos alunos da nossa turma de Mestrado
em Engenharia Elétrica (Computação Aplicada). Fig. 2. O livro do grupo que definiu o RTSJ. O seu conteúdo inteiro
encontra-se disponível na Internet em formato PDF.

L IVROS SOBRE R EAL -T IME JAVA

Em pesquisa recente encontramos os seguintes títulos

realcionados à Programação para Tempo Real e a lingua-
gem Java.

¯ Bolela, G., Goslin, J. et. al., "The Real-Time Specifi-

cation for Java - The Java Series". Addison-Wesley,
2000. (Fig. 2).

¯ Dibble, P., "Real-Time Java Platform Programming".

Java Series - Prentice-Hall, 2000. (Fig. 3).

¯ Burns, A., Welling, A., "Real-Time Systems and

Programming Languages - Ada95, Real-Time Java Fig. 3. Outro livro sobre Java para Tempo-Real da série Java patroci-
and Real-Time POSIX". Addison-Wesley, ¿ nada pela Sun.
edition, 2001. (Fig. 4).

Fig. 4. Com uma abordagem mais genérica, o livro acima aborda

outras linguagens de programação para tempo-real além de Java.