RE: [Embedlets-dev] Re: Threads

[James C. <ca...@vi...>]

>One benefit of this is the KISS principle for
>developers of Embedlets.  Most Java developers have trouble with
>threads....so it would be much nicer if (like with Servlets) threading was
>transparent and you never had to use them directly.

I tend to agree, I think the real-time layer is the JAPL/Cork layer.

I know this may seem weird but I have a gut feeling that RTJ may not
actually the best place to look for real-time performance other than quite
high level scheduling. Real 'real-time' is just so close to the bone of the
platform that I suspect it will be a while before RTJ is the prefered way of
handling it.

I think real-time is not the Embedlets problem nor is threading or the way
things happen in the Container ie. This is the container implementors
problem and even though we will have a reference implementation for this I
don't think the Embedlet container should specify HOW* it is implemented.
For instance I fully expect the muvium container is going to be 100%
assembler implementation of the Container Interface specification.

JAPL/Cork is natural real-time layer and I really like Ted's idea of JAPL
components publishing their real-time capabilities. Poor-man's real-time..
Hardly! This is more fine grained real-time than RTJ! And again, it should
be an interface that supports non-java implementations behind the scenes.

Finally, I don't there is a Real-time Silver Bullet so we shouldn't try to
integrate it into the spec upfront but as we gain more insight by tackling
real world problems it might make more sense to attach more Real-Time
details to the spec.

James Caska
http://www.muvium.com
'Java Bred for Embedded'




> -----Original Message-----
> From: emb...@li...
> [mailto:emb...@li...]On Behalf Of
> Andrzej Jan Taramina
> Sent: Tuesday, February 04, 2003 11:12 AM
> To: emb...@li...
> Subject: [Embedlets-dev] Re: Threads
>
>
> Topic tags:[Arch][Wiring][Doc][HW][PM]
> _______________________________________________
>
> Chris says:
>
> > One way to address this would be to have Embedlets designated as
> > thread-aware or unaware. The guidelines for thread aware Embedlets would
> > be set out based on RT requirements. It seems that that the container
> > would not have to be  concerned with RT threading. Am I right??
>
> Yup...that is one way to deal with it.  But I don't like the idea
> of Embedlets that
> are thread aware or not.  I would prefer to see Embedlets not
> have to worry
> about that, and the Outpost Build system to add any extra thread-based
> requirements depending on whether the Container was build to support
> threads or not (based on the platform's capabilities).  That is,
> the design
> contracts and patterns that an Embedlet has to abide by should be
> of such a
> nature that whether the container was threaded or not should (ideally) be
> transparent to the Embedlet code.  One benefit of this is the
> KISS principle for
> developers of Embedlets.  Most Java developers have trouble with
> threads....so it would be much nicer if (like with Servlets)
> threading was
> transparent and you never had to use them directly.
>
> It may be possible to design the Embedlet base classes and
> Outpost Services
> so that even though they support the same invocation signatures,
> one version
> supports threads under the covers (using synchronized methods under the
> covers for instance) and another version just uses a co-operative
> approach
> without threads.  There would probably be two different versions of the
> Scheduler/Event Manager Services as well.
>
> My gut feel is to implement in a 3 phase process: to first get a
> non-threaded
> implementaton of the Container working.  Then learn from that and add
> threads.  Then look at how to handle the RT requirements.
>
> If we try to do threads and RT off the bat, it will probably take
> way too long to
> get the first implementation out the door.
>
> Andrzej Jan Taramina
> Chaeron Corporation: Enterprise System Solutions
> http://www.chaeron.com
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer
>
>