Que “tempo real” é este de que falam tanto?

O que é tempo-real? O que o pessoal anda chamando de tempo-real é realmente tempo-real? Node.js ou websocket realmente me propiciam uma web “real time”? Vou tentar responder a todas estas perguntas neste post com a visão de alguém que trabalha em um sistema de tempo-real de verdade (eu).

Como a computação define tempo-real

Quando falamos em tempo-real no contexto da computação nos referimos a toda uma gama de aplicações que possuí como requisito fundamental restrições temporais. O que é uma restrição temporal? Ela diz que seu software executa corretamente se e somente se duas condições forem satisfeitas:

• O software é lógicamente correto.
• A execução do sistema se dá no momento esperado.

Se já é difícil escrever software com uma lógica válida, ainda mais é garantir que execute no momento esperado. Talvez seus sistemas atuais já possuam características de tempo-real e você nem tenha se dado conta. O exemplo mais claro é a execução de tarefas agendadas que precisam executar no momento em que você as programou.

Dependendo do autor você encontrará duas categorias de sistemas de tempo real. Hard, quando o atraso na execução compromete completamente o seu resultado  e Soft (mais comum pra todos nós) quando o atraso é mais aceitável e no máximo ocorrerá uma degradação na execução do sistema.

O agendamento de tarefas com o qual a maior parte dos usuários está acostumado (usando ferramentas como, por exemplo, CRON, Quartz ou Timer do Java) é do tipo Soft. Se você agenda sua execução para as 13:00:00, pode ser que só sejam iniciadas alguns segundos depois sem normalmente ferrar a sua vida.

Há sistemas nos quais você requer uma precisão maior como por exemplo no processamento de sinais. Há diversos protocolos que enviam dados em uma cadência bem estrita, como por exemplo de 50 em 50 milisegundos. Nestes casos qualquer atraso é fatal, pois você irá perder a transmissão de dados caso seu código não esteja estritamente sincronizado com o relógio do sistema.

A dificuldade na implementação de sistemas de tempo-real

Não é a toa que Hard Real Time se chama Hard Real Time. Se um processo do sistema operacional começa a consumir seus recursos computacionais no momento errado, por exemplo, é grande a probabilidade de que você perca seu deadline. Aliás, deadline é O termo. Tudo em tempo-real gira em torno disto: o momento no qual a coisa deve ocorrer.

Tempo-real em Java é difícilimo graças ao garbage collector. Muitas vezes sua execução atrasa a execução do sistema. Na pratica é quase impossível escrever um sistema hard real time em Java em grande parte por esta razão. Por isto há tanta preocupação com a criação de objetos: quanto menor o número de objetos, menor a probabilidade do GC executar e, consequentemente, menos interrupção temporal. Outro grande desafio é a compilação just-in-time: a JVM recompila seu código diversas vezes enquanto este encontra-se em execução. Tunar a sua JVM para evitar sua ocorrência em um momento inoportuno é outro grande desafio. E adivinha qual é a JSR de número 1? Real-time.

(este artigo de 2007 da IBM sobre os desafios de se escrever sistemas real-time em Java é uma boa leitura (claro, depois eles vão te tentar vender a JVM RT deles))

É devido a este tipo de problema que normalmente soluções de tempo-real envolvem além do software, hardware. Há inclusive sistemas operacionais específicos para este tipo de problema, como por exemplo o QNX da BlackBerry, usado a décadas neste nicho. O que estes sistemas operacionais nos dão de tão especial? Basicamente nos permitem controlar melhor a prioridade dos processos.

“Meu sistema é real-time: vejam como é rápido!” – OUCH!

Esta é a maior bobagem que você pode falar sobre tempo-real com base no que disse acima. Lembra que eu havia dito que tempo real envolve deadline? Então: se o seu sistema demora 23 horas para computar o resultado, mas o entrega no tempo exato, temos um sistema real-time do tipo hard. Lembre-se: deadline, não performance é quem manda aqui.

“Ocorreu lá no servidor, imediatamente foi pro cliente. Real-time!” OUCH!

Pode até ser tempo-real, mas não necessáriamente. Se algo é enviado imediatamente após ter sido executado no servidor, que garantia você tem de que foi executado no deadline esperado? Aliás, qual deadline? Nenhum: pode ter demorado, por exemplo. Aliás, isto tem outro nome: chama-se sistema on-line.

Um sistema on-line (ou online, sei lá) é aquele no qual o resultado do processamento está diretamente relacionado à interação do usuário. Você clica no botão submeter do seu browser e imediatamente tem uma resposta com base no seu input. Isto é online. Online pode ser tempo-real, mas não necessáriamente.

Aliás, este é o uso que eu vejo do termo real-time quando aplicado ao Node.js, como por exemplo aqui. Sacou a diferença? Você pode até conseguir um sistema de tempo real com Node.js, mas da forma normal, no máximo irá conseguir algo do tipo Soft. Que controle você tem sobre os outros processos do sistema operacional? Pergunte-se: que “tempo-real” é este que o pessoal usa pra vender o Node.js? Como alguém pode vender material por aí sobre “real-time web” se não fala sobre restrições temporais? Que restrições temporais são estas? Apenas pessoas incrívelmente brilhantes podem vê-las?

Dica: de nada adianta você ter um protocolo de comunicação de baixíssima latência se não conseguir cumprir seu deadline.

Web RTC: cadê o tempo-real?

Quer ver um exemplo muito interessante? Web RTC. É uma especificação da W3C que propicia comunicação em “tempo real” entre browsers. Me faz um favor? Primeiro da uma lida na especificação oficial. Leu? Sentiu falta de algo no texto? Te conto então: não há qualquer sitação aos termos “deadline”, “time restriction” ou similar. Nominho ruin hein? Tenho um nome pra isto: marketing. Por que não se chama “Web OTC”?

Reparem: há alguma restrição de tempo aqui? Sim. Qual é? Se você está se comunicando com outra pessoa e demora muito pra chegar a resposta. Mas aonde ela está definida? O que a diferencia de um sistema meramente interativo? “Ao vivo” pode ser considerado “tempo-real”? Há um questionamento interessante aqui que deixo para vocês.

(eu sei que este ponto vai dar pano pra manga, então podem me atacar ok? :) )

Então como eu evito falar bobagem por aí?

Muito simples: seu sistema tem algum requisito de tempo-real? Há algum do tipo “deve executar em no máximo n milisegundos” ou “deve ser executado na hora x” ou “vai ter de se repetir precisamente de n em n segundos” ou qualquer coisa do gênero? Tem? Ok: você tem um sistema de tempo real. De qual tipo? Hard? Soft? Se for soft, não há vantagem alguma, então por que bradar por aí?

Agora, sair dizendo que desenvolve sistemas de “tempo real” com Node.js sem estes requisitos te caracteriza como ignorante ok? :)

Recursos sobre tempo real

Quer saber mais sobre o assunto? Aqui está uma lista de recursos interessantes pra você.

• “The Concise Handbook of Real-Time Systems”: uma introdução maravilhosa ao assunto. Clique aqui.
• Conceitos relacionados a sistemas operacionais de tempo real (RTOS) você encontra aqui.
• Alguns padrões de projeto podem ser encontrados aqui.

Concluindo

O objetivo deste post foi desmistificar o uso que vejo sendo feito em todo lugar do termo tempo-real. Realmente não consigo entender qual é o tempo-real a que se referem pois não vejo as restrições temporais que tanto falei aqui e encontram-se confirmadas nos recursos que listei.

(se você é leitor antigo deste blog sabe que é uma luta antiga minha esta minha busca pelo melhor termo sempre)

Termino o post com perguntas ao leitor: e aí, é tempo-real mesmo? Que tempo-real é este? Como posso dizer que algo é de tempo-real se não há restrições temporais explícitas?