embedlets-developer

[Andrzej J. T. <an...@ch...>]

I've been thinking about how to structure the spec/RI so that we can 
support at least some subset of real-time processing, which is a 
requirement of many embedded systems.

There are many fuzzy definitions of real-time. Hard real-time seems to be 
the most stringent, and looks like a pre-emptive interrupt driven scheme 
that keeps things like planes from crashing and chemical plants from 
blowing up.  I'm pretty sure that these most stringent of requirements 
for response to critical interrupts will not be a good fit for the 
Embedlet architecture, at least not in the first few iterations, since 
they very much rely on the underlying hardware capabilities (to provide 
the deterministic, interrupt-processing stuff), and there are not too 
many RTJ (real time for Java) implementations out there.  Many Java 
implementations of threads are not pre-emptive which is something the 
Embedlet container can't easily address.

However, this does leave a large middle ground, for the implementation of 
"softer" real-time requirements.

A typical event-driven paradigm (like the one we have been discussing and 
planning on implementing), with a decoupling queue in the middle (the 
Event Service) does not provide deterministic response times and so 
compromises hard real-time capability, though a simple/flexible event 
priority scheme might go a long way to mitigate this, and would allow for 
many "soft" rt application implementations.

The concept of synchronous events might work to  handle this, with 
suitable caveats/provisos in how they should be used (so as not to 
compromise overall performance, and blow the stack space). 

By synchronous event, I mean one that the event manager will process 
immediately, without queuing, where the posting of an synchronous event 
by and event producer looks more like a procedural method invocation 
(albeit an indirect one delegated through the Event Service).  This might 
be a good way to address certain classes of RT problems, since it will 
run in the current thread, and run to completion on a non-preemptive 
threading platform.  

The problem here is if this capability is abused.  If a single sync event 
produces multiple child sync events (event cascade scenario) or a 
circular situation, then you can go into an infinite loop or blow the 
stack space.  If running on a pre-emptive platform, then you can easily 
run into situations that are not thread-safe.  

That being said, I think it's worthy of inclusion, with appropriate 
caveats/warnings/best practices to keep developers from getting into 
troubles.

Any other thoughts/collective wisdom on Real Time support for Embedlets?



...Andrzej

Chaeron Corporation
http://www.chaeron.com