Re: Ada Annex E (Just curious :-)

["Kevin Rigotti" <rigotti@atc.dera.gov.uk>]

Marin David Condic wrote in message <982veb$l62$1@nh.pace.co.uk>...
>Obviously, there is more than one way to skin this cat, but having glanced
>at the rationale for Annex E, I can see how it was intended to be used and
>could be fairly handy for some systems with shared resources. I think that
a
>big drawback would be that to use it in a system that didn't have a nice,
>common architecture & RTK/RTOS, you'd have to get your compiler
>custom-modified for the hardware you had.

I'm speaking from a position of ignorance, having never done it, but perhaps
BSP (http://www.bsp-worldwide.org/) style distributed processing would be
useful?

Namely, all non-local read and write requests queued locally until the end
of the super-step, then completed by message passing using "Annex E
mechanisms". There would be no need for that to be homogenous.

If one partition were set up as controller, and each of the others
registered themselves with it on startup then it would be easy enough to
give everything a vector of access values for remote dispatching to the
other components.

What you *do* need for any BSP-like thing is an efficient way of doing
multicast messaging and n-way rendezvous. I'm not at all clear on how to do
that efficiently in Ada.

If the application had sufficiently many natural synchronisation points then
deferring the communication wouldn't be too expensive, and performance would
at least be predictable if not actually scalable.

Maybe? It's something I've wanted to play with but never had the time or
funding for :-)

Kevin
--
ATC Systems Group, DERA, St Andrews Road, Malvern, Worcestershire WR14 3PS,
UK
Phone +44 (0)1684 89 69 11, fax +44(0)1684 89 41 09
DERA disclaimers and restrictions apply, details on request