1
RTSJ - Especificação de JAVA para Programação em Tempo-Real Paulo Roberto M. Cunha
[email protected]
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, patrocinado pela empresa Sun Microsystems. Nele são sumarizados aspectos ligados à modificações na especificação da linguagem (necessárias para atender os requisitos de programação para sistemas em Tempo-Real e distribuídos). Neste trabalho são apresentadas ainda a definição de termos ligados a sistemas de Tempo-Real, as motivações que impulsionaram a escolha da linguagem, e o estado atual de sua disponibilidade comercial.
dos Estados Unidos, iniciando em junho de 1998 e culminando em novembro de 20012 com a publicação da especificação de Java para Tempo Real – Real Time Specification 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 Portabilidade: Desenvolvedores de sistemas emusar Java para aplicações de Tempo-Real. barcados (embedded) de tempo-real freqüentemente encontram-se tendo de lidar com um certo número de miA plataforma Java tem valor potencial significativo croprocessadores diferentes. É comum encontrar-se misno 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 ferde adaptar um sistema já existente para uma nova plata- ramentas apropriadas para trans-desenvolvimento (crossforma. development) para todos esses diferentes hosts é que se pode chamar de um “ pesadelo administrativo.” GaranReconhecendo 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 desenvolvinio do Instituto Nacional de Padrões e Tecnologia (NIST) mento seria muito mais fácil se os programadores pudessem escrever seus códigos em uma linguagem que fosse Trabalho apresentado na disciplina Programação de Objetos Distribuídos no Curso de Mestrado em Engenharia Elétrica (Computação Aplicada) ministrada pelo Prof. Dr. Rodrigo Quites, na Universidade Federal do Pará (UFPa), Jan.,2003.
O RTSJ teve a distinção de ser a primeira Java Specification Request (JSR 1), embora não tenha sido a primeira requisição a ter sido feita.
2
portátil entre todas essas arquiteturas, mantendo uma versão única de seus sistemas. Adaptabilidade Dinâmica: Outra dificuldade freqüente na manutenção de sistemas em tempo-real embarcados é 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 comunidade de usuários (ex.: controle de tráfego aéreo, centrais comutadoras de telefonia, e reconhecimento militar), e aplicações para as quais o custo de desligamento (downtime) 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 redistribuir informações e carga de trabalho. Seria bastante desejável poder dispor de um ambiente de execução no qual fosse permitido, de forma transparente (ou o mais simples possível), realizar essa transferência, mesmo considerando que os outros nós podem conter arquiteturas e sistemas operacionais heterogêneos, tornando-os capazes de executar quaisquer das tarefas que precisem ser executadas.
¯
¯
¯
¯
III. P OR QUE JAVA ? O que poucas pessoas sabem, ou lembram, é que originalmente a linguagem Java foi criada como parte de um projeto de pesquisa para desenvolvimento de software avançado para uma larga variedade de “dispositivos” interconectados em rede e sistemas “embarcados” (embedded 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 desenvolvimento de aplicações dentro do contexto de ambientes distribuí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 plataforma de harware e software, e pudessem ser estendidas dinamicamente eram as de maior relevância [11].
¯
¯
Java empresta das linguagens C e C++ a sintaxe familiar. Tal como C++, Java é orientada para objetos, embora seja mais simples que C++ por decisão intencional 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-deexecução. Existem relatos da Sun alegando que o interpretador básico tem cerca de 40 Kbytes, e a biblioteca básica e o suporte à thread somam aproximadamente 175 Kbytes [11]. O ciclo de desenvolvimento tende a ser mais rápido devido ao fato de Java suportar implementações interpretadas e compiladas através do método just-intime. 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 representação intermediária baseada em byte-code independente de máquina a qual pode ser transferida entre nós heterogêneos de rede e interpretada ou compilada 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 gerência de memória (garbage-collection) automática. Embora essa seja uma característica bastante desejá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 repensada 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 projeto de pesquisa inicialmente escolheu usar C++ para o desenvolvimento.Subseqüentemente os desenvolvedores encontraram tantas dificuldades com C++ até o ponto de decidirem que seria melhor projetar um ambiResumindo, o Grupo de Requerimentos considerou as ente de linguagem totalmente novo. Passando por alguns pontuações abaixo como sendo uma base para os requepercalç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¯ O alto nível de abstração presente em Java conduz lares como C e C++ [9]:
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¯ Advanced Logic Corp. time efficiency). ¯ Bay Networks / Bay Architecture Lab Java é relativamente mais fácil de ser dominada do ¯ Hewlett-Packard Company que C++. ¯ Honeywell Inc. Java é relativamente segura, mantendo componentes 3 ¯ IBM Corp. de software (incluindo a própria JVM ) protegidos ¯ Lexmark International, Inc. entre si. ¯ Microsoft Java suporta o carregamento dinâmico de novas clas¯ The Mitre Corporation ses. ¯ Mitsubishi Electric Corporation Java é altamente dinâmica, oferecendo suporte à cri¯ Motorola, Inc. ação de objetos e dethreads em tempo de execução. ¯ Nokia Research Java foi projetada para dar suporte à integração de ¯ Nortel componentes e reutilização. ¯ QNX Software Systems, Ltd. As tecnologias ligadas à Java foram desenvolvidas ¯ Rockwell Collins com considerações criteriosas, utilizando conceitos e ¯ Siemens AG, A&D técnicas que foram escrutinizadas pela comunidade. ¯ Sony A linguagem de programação Java e a plataforma ¯ SRI International Java dão suporte à portabilidade de aplicações. ¯ Sun Microsystems, Inc. As tecnologias ligadas à Java dão suporte a criação ¯ The MITRE Corporation de aplicações distribuídas. ¯ The Open Group Java oferece uma semântica de execução bem¯ Xerox Corporation definida.
IV. O G RUPO DE R EQUISITOS
Muito embora isso não seja um fator decisivo no sucesso ou fracasso de uma tecnologia (e sim as forças de mercado) mas o aval de grandes empresas em uma especificação empresta um pouco de suas reputações a ela.
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 V. P RINCÍPIOS NORTEADORES DO T RABALHO DO Grupo de Requisitos (Requirements Group) incluiu repreRTJEG sentantes das companhias e organizações cuja capacidade técnica abrangem a indústria da computação e a academia Os princípios norteadores são declarações de alto ní[4]. vel que delimitam o escopo do trabalho do RTJEG e introduzem requisitos de compatibilidade para A Especificação O objetivo do grupo foi desenvolver requisitos interde Tempo-Real para Java. disciplinares para funcionalidades voltadas para TempoReal necessárias para uso em aplicações escritas na linAplicabilidade a um Ambiente Java em Particuguagem de programação Java e sendo executadas em vá- lar: O RTSJ não deverá incluir especificações que restrinrias plataformas diferentes. jam seu uso a ambientes Java específicos, tais como uma
A. Empresas Participantes da Especificação
versão particular do Java Development Kit (JDK), o Embedded Java Application Environment, ou o Java 2 Micro Edition .
Retrocompatibilidade: O RTSJ não deverá impedir Um indicador do grau de importância de uma dada tecnologia é o número de empresas (especialmente gran- que programas Java já existentes, escritos de forma aprodes empresas) interessadas nela. Cada uma das empre- priada e sem a característica de Tempo-Real, sejam exesas 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 qualquer lugar), mas também deverá reconhecer a dificuldade de se alcançar WORA para programas de tempo-real, e não tentar aumentar ou manter portabilidade binária às custas de presibilidade.
ser entregues dentro de um intervalo de tempo bem definido. Um resultado entregue fora desse tempo (tarde demais) é tão ruim quanto, ou até mesmo pior do que, um resultado que não é entregue. Os aspectos de temporalidade de aplicações para Tempo-Real fazem com que estes sistemas sejam notoriamente complexos.
Práticas Atuais versus Características Avançadas: Os termos chave de computação de Tempo-Real, tais O RTSJ deve considerar as práticas correntes usadas em como real–time, hard real–time, soft real–time, determisistemas de tempo-real, assim como permitir futuras implementações para inclusão de características avançadas. nismo, e predisível são freqüentemente usados na comunidade 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 pesdade 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 do tipo “o que será, será” (um conceito que normalmente performance computacional de propósito geral. 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 conhecido como Real-Time Specification for Java (RTSJ) [3], e Permitir Variação nas Decisões de Implementanela 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 implementação, tais como o uso de algoritmos eficientes ou não, compromissos entre eficiência de tempo ou de espaço, inclusã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 moRTSJ 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 todos (ou mesmo de alguns) possíveis mecanismos de escalonamento. 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 apropriSoftware para aplicações de Tempo-Real reage a es- ados para o mecanismo de escalonamento subjacente, astí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 futurage 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á
5
baseado em prioridades, preemptivo, e deve ter no mínimo usada (tal como atraso médio) e pode aceitar vários valores para a métrica em uso. 28 prioridades únicas. 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 diferentemente 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. Qualquer instância de qualquer classe que implemente a interface Schedulable é um objeto escalonável e seu escalonamento e despacho serão gerenciados pela instância de Scheduler da qual ele tenha uma referência. O RTSJ requer 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 implementação particular, ou ambos, se threads particulares sempre completarão sua execução antes de alguma restriçã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 computar apenas a resposta aritmeticamente correta, mas a resposta 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 algoritmo de escalonamento para referir-se à produção de uma seqüência, ou ordenação, para a execução de uma conjunto 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 analysis) determina se uma escala tem um valor aceitável para a métrica.
Muitos sistemas usam prioridade de thread em uma tentativa de determinar uma escala. Prioridade tipicamente é um número inteiro associado com a thread. Esses inteiros informam ao sistema a ordem na qual as threads 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 elegibilidade de execução do conjunto de threads que estejam prontas para serem executadas. Na prática corrente de sistemas de tempo-real, a atribuição de prioridades está tipicamente sob controle do programador em oposto ao controle 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 Parameters (tais como SchedulingParameters). Uma instância de uma dessas classes de parâmetros contém uma característica de demanda por recurso em particular para ser usada por um ou mais objetos escalonáveis. Por exemplo, a subclasse PriorityParameters 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 reconfiguração) de thread), outras instâncias de classes de parâ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 instâ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á sempre que estiver pronto preferencialmente à todos os outros objetos escalonáveis ( exceto, é claro, àqueles que também possuirem a mais alta prioridade). O RTSJ especifica ao menos um algoritmo de escalonamento e mudança semântica na JVM que suporta execuçã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.
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 Projeto: É reconhecido que o gerenciamento autoúnico valor aceitável para essa métrica é zero. Em sistemas de tempo-real leves (soft real-time) outra métrica é mático de memória é uma característica particularmente
6
importante do ambiente de programação Java, e foi buscada uma direção que permitisse, tanto quanto possível, que o serviço de gerencia automática de memória pudesse ser implementado automaticamente pelo sistema subjacente e não se intrometesse na tarefa de programação. Existem diversos algoritmos de gerenciamento automático de memória, também conhecidos como garbage collection (GC), e muitos deles acomodam-se a certas classes de estilos e sistemas de programação para temporeal. Em uma tentativa de acomodar um conjunto diverso de algoritmos de GC foi buscado definir-se uma especificação alocação e retomada de memória que: ¯ ¯
¯
fosse independente de qualquer algoritmo de GC em particular, permitisse o programa caracterizar de forma precisa o efeito de um algoritmo implementado de GC no tempo de execução, preempção, e despacho de threads Java de tempo- real, e permitisse a alocação e retomada de objetos fora de qualquer interferência de qualquer algoritmo de GC.
Especificação: Garbage-collected memory heaps sempre foram considerados um obstáculo para programação para tempo-real devido às latências imprevisíveis introduzidas pelo garbage-collector. O RTSJ responde essa questão provendo várias extensões ao modelo de memória as quais dêem suporte ao gerenciamento de memória de uma forma que não interfira com a habilidade do código de tempo-real prover comportamento determinístico. Este objetivo é alcançado através da permissão da alocação de objetos fora do heap do garbage-collector tanto para objetos de curto quanto de longo tempo de vida: Memory Areas: O RTSJ introduz o conceito de área de memória. Uma área de memória representa uma área da memória que pode ser usada para alocação de objetos. Algumas áreas de memória existem fora do heap e impõem restrições sobre o que o sistema e o garbagecollector podem com os objetos alocados nestas áreas. Objetos em algumas áreas de memória nunca são coletados pelo garbage-collector, entretanto, o garbagecollector tem de ser capaz de vasculhar essas áreas de memória em busca de referências a quaisquer objetos dentro do heap para preservar a integridade do heap.
definido pelo escopo sintático (o tempo de vida dos objetos no heap). 2) Physical Memory: permite que objetos sejam criados em regiões de específicas de memória física que tenham características particulares importantes, tais como memória que tenha velocidade de acesso substancialmente mais rápida, ou áreas de memória destinadas a mapeamento de dispositivos. 3) Immortal Memory: representa uma área de memória que contém objetos que, uma vez alocados, passam a existir durante toda a execução da aplicação, ou seja, os objetos são imortais. ImortalMemory é um recurso de memória compartilhado entre todas as threads em uma aplicação. Objetos alocados em ImortalMemory só são liberados quando o ambiente de execução Java (Java run-time environment) termina, e nunca são alvo de garbagecollecting ou de movimentação. 4) Heap Memory: representa uma área de memória que é o heap. O RTSJ não muda o determinante do tempo de vida dos objetos presentes no heap. O tempo de vida ainda é determinado pela visibilidade.
C. Sincronização e Compartilhamento de Recursos: Projeto: A lógica de programação freqüentemente necessita compartilhar recursos serializáveis. Sistemas para tempo-real introduzem uma complexidade adicional: inversão de prioridade. Foi decidido que a especificação menos intrusiva para permitir sincronização segura em tempo-real é requerer qua as implementações de synchronized (palavra reservada da linguagem Java) inclua um ou mais algoritmos que previnam inversão de prioridade entre threads Java de tempo-real que compartilhem o recurso serializado. Foi notado também que em alguns casos o uso da palavra reservada synchronized implementando o algoritmo requerido de inversão de prioridade não é suficiente nem para prevenir inversão de prioridade nem permitir uma thread ter uma elegibilidade de execução logicamente mais alta que o carbage collector. É provido um conjunto de classes de filas livres de espera (wait-free queue classes) a serem usadas em tais situações.
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.
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 objetos acessados tanto por threads Java regulares quanto por NoHeapRealtimeThreads. Essas classes são providas explicitamente para permitir comunicação entre a execução de tempo-real de NoHeapRealtimeThreads e threads Java regulares.
Wait Queues: Threads esperando para adquirir controle 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 synchronized tem acesso garantido ao bloco sincronizado em ordem de elegibilidade de execução. Uma thread bloqueada que se torna pronta para executar recebe acesso ao processador em ordem de elegibilidade de execução. Uma thread cuja elegibilidade de execução é explicitamente configurada (set) por si mesma ou por outra 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 algoritmo usado para garantir tal acesso.
D. Gerenciamento de Eventos Assíncronos Projeto: Sistemas de tempo-real tipicamente interagem 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 requeridas representam coisas que possam acontecer e a lógica que é executada quando essas coisas acontecem. Uma característica notável é que a execução da lógica é escalonada e despachada por uma escalonador implementado. Espeficifcação: A estrutura de eventos assíncronos é composta de duas classes:
essa é a lógica a ser seguida. ¯
Evitando Inversão de Prioridade: Todas as implementaçõ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:
¯
AsyncEvent AsyncEventHandler
Um objeto AsyncEvent representa algo que possa acontecer, como um signal POSIX, uma interrupção de hardware, ou um evento computado tal como um avião entrando em uma região específica. Quando um desses eventos ocorre, que é indicado pela execução do método fire( ), os métodos associados handleAsyncEvent( ) de instâncias de AsyncEventHandler são escalonados e dessa forma realizam a lógica requerida. Uma instância de AsyncEvent gerencia duas coi-
Caso a thread ½ tente ganhar controle sobre um lock que está sendo mantido por uma thread ¾ de prioridade mais baixa, então a prioridade de ¾ é elevada ao nível da de ½ enquanto ¾ mantenha controle sobre o lock ( e recursivamente caso a própria ¾ esteja esperando para ganhar controle sobre uma lock man-
sas: 1) o desbloqueio de handlers quando o evento é disparado, 2) o conjunto de handlers assossiados ao evento. Este conjunto pode ser questionado, ter handlers adicionados 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.
do mecanismo tradicional, inseguro, e obsoleto da linguagem Java de parar threads, o mecanismo do RTSJ para tratamento de eventos assíncronos e transferência de controle é seguro.
G. Acesso à Memória Física: Pretende-se que o sistema possa lidar bem com situações onde haja um grande número de instâncias de AsyncEvent e AsyncEventHandler (dezenas de milhares). 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ência é dirigida pelo tempo. Existem dois tipos de Timers: O tipo OneShotTimer e o PeriodicTimer. Instancias de OneShotTimer disparam uma vez, em um momento específico. Timers periódicos disparam em momentos específicos e então periodicamente de acordo com um intervalo 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).
E. Transferência Assíncrona de Controle: As vezes o mundo real muda tão drasticamente (e assincronamente) que o ponto atual da execução da lógica deve ser imediatamente e eficientemente transferido para outra localização. O RTSJ inclui um mecanismo o qual estende o mecanismo de tratamento de exceção para permitir às aplicações mudar, através de programação, o local (locus) de controle de outra thread Java. É importante notar que o RTSJ restringe essa transferência assíncrona de controle à lógica especificamente escrita sob a presunção de que o seu local de controle pode mudar assincronamente.
Embora não seja diretamente uma questão de temporeal, acesso à memória física é algo desejável para muitas 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 JavaWorld 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 foi chamada de “sumo de Robôs” (Fig.1). O sumo de robôs segue regras semelhantes as da luta de sumo real. Dois robôs se enfrentam em uma arena circular, cada qual tentando forçar o outro para fora do ringue. Diferentemente de Battlebots e outros shows de televisão populares nos Estados Unidos, os competidores do sumo de robôs não são violentos. A tentativa intencional de causar danos ao oponente é expressamente proibida. Da mesma forma, os robôs não são controlados por seres humanos. Ao invés disso eles se baseiam em comportamentos preprogramados (comportamento autônomo) – software é tão importante quanto hardware.
O público presente pôde configurar os robôs através de “Java-powered wireless phones”, utilizando Sun ONE (One Network Environment) Web services e wireF. Término Assíncrono de Thread: less Ethernet. O 1público poderia escolher enfatizar velocidade sobre agilidade de uma forma familiar aos entusiNovamente, 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, exseu 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 dencâ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 Este esforço foi bem sucedido em seu intento de criar de ser preprogramadas. uma especificação (RTJEG), posteriormente uma padronização (RTSJ), e por último uma implementação para o padrão, mas se o RTSJ sobreviverá e onde ele se encaixará 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 servidor 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 embarcadas (embedded VM) e hardware parecem estar concentrando seus esforços mais em J2ME7 e não tem planos para embarcarem em Java de Tempo-Real. Uma das razões para isso é que todas elas já oferecem alguma capacidade 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 meses), mas a maioria está esperando para ver a demanda de mercado antes de se comprometer com esta nova API. Concluímos que a RTSJ é o resultado de um esforço conjunto, criterioso da comunidade de tempo-real (academia e empresas) para prover a criação de um ambiente
aJile Systems, Esmertec, NewMonics, Zucotto Wireless, etc. . . A empresa aJile Systems (www.ajile.com) participou no Grupo de Peritos para Especificação de Java para Tempo-Real (RTJEG) e atualmente trabalha em uma implementação de RTSJ para seus processadores Java aJ-80 e aJ-100. Java 2 Platform, Micro Edition
[1] Allen, D., Standards for Real-Time Distributed Object Computing. 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 Saddle 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. 400407, 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 Performance Engineering Section The MITRE Corporation,2000. [8] Lamport, L. - LATEX A Document Preparation System – User´s Guide & Reference Manual. Addison-Wesley, Reading, Massachusetts, 1986. [9] Nilsen, K., Issues in the Design and Implementation of RealTime 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.
A PPENDIX AGRADECIMENTOS
Este trabalho foi feito usando LATEX. Falar sobre seus méritos quanto à preparação de documentos é chover no molhado, mas gostaria de deixar registrada aqui minha
10
profunda admiração pelos autores dos pacotes TEX, Donald 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 ideais mais nobres que sustentam e promovem o avanço da ciência da computação. Agradecemos também ao Prof. Dr. Rodrigo Quites, 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 linguagem Java. ¯
Bolela, G., Goslin, J. et. al., "The Real-Time Specification 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 and Real-Time POSIX". Addison-Wesley, ¿ edition, 2001. (Fig. 4).
Fig. 3. Outro livro sobre Java para Tempo-Real da série Java patrocinada pela Sun.
Fig. 4. Com uma abordagem mais genérica, o livro acima aborda outras linguagens de programação para tempo-real além de Java.
