[Embedlets-dev] Re: Threads

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

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