Re: [Embedlets-dev] Real Time....

[Gregg G. W. <gr...@sk...>]

>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.

Hard real-time is hard, and is generally something designed specifically for a 
processor and associated hardware will all latency and hardware speeds are 
known and planned for.  I don't think embedlets help in this realm...

>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.  

This is what my pub/sub space does for locally connected entities.  For 
connected spaces, it creates a thread to dispatch into that space.  In this 
case there are typically remote access latencies that you don't want local 
processing to experience.  There might be local latencies, or SMP (to take 
advantage of) that might also make it beneficial to have two threads running 
to maximize throughput.

>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.  

Yes, all of these things are true, including the posibility of exceptions that 
may need to be passed up to defer procesing...

>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?

Soft typically implies predictable latencies with reasonable limits for 
windows into the latency times.  I am not sure that you can ever, really cap 
the windows maximum, without more explicit controls such as those that RTSJ 
provides...

-----
gr...@cy...  (Cyte Technologies Inc)