Re: Distributed Ada, robustness etc.

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Thu, 25 May 2006 01:12:08 GMT, Dr. Adrian Wrigley wrote:

> On Tue, 23 May 2006 12:14:05 +0000, Dr. Adrian Wrigley wrote:
> 
>> Up until now, I have been using fairly elementary Annex E features
>> with GNAT/GLADE on Linux.
> <snip>
> 
> Hmm.  Seems to have gone quiet round here!
> 
> OK. I've prototyped a system based on LRM E.4.2 (p. 412), where a
> Remote_Call_Interface unit registers servers as they are instantiated.
> 
> This will work nicely, except for the single point of failure
> issue resulting from having RCI units, and the following nuisance:
> 
> EITHER
> every subprogram declaration using the remote despatching type
> has to refer to it as "access Tape" (or whatever the type is called),
> 
> procedure Rewind (T : access Tape) is abstract; -- need to add "access"
> ...
> TapeAccess := Find ("NINE-TRACK");
> ...
> Rewind (TapeAccess);
> 
> Or
> 
> every despatching call needs to dereference an access variable
> (so calls become something like "Tapes.Rewind (TapeAccess.all);")
> 
> procedure Rewind (T : Tape) is abstract;
> ...
> TapeAccess := Find ("NINE-TRACK");
> ...
> Rewind (TapeAccess.all); -- Need to add ".all" for every call!
> 
> I'd rather not change all my code to say "access" or "all" every
> time I define or use one of these calls (lazy).  The only solution
> I have come up with to avoid modifying the existing code to have
> "all" with every call is to define a corresponding set of subprograms
> which take the access values as parameters, and call the underlying
> (remote) despatching interface by dereferencing it in the body.
> 
> So the code would become:
> 
> procedure Rewind (T : Tape) is abstract; -- unchanged code
> procedure Rewind (T : access Tape) is begin Rewind (T.all); end Rewind;
> ...
> TapeAccess := Find ("NINE-TRACK");
> ...
> Rewind (TapeAccess); -- unchanged code
> 
> Am I missing a better, more obvious solution?

Basically I have same problem with other, but similar things. I do with
smart pointers. A smart pointer cannot be a perfect substitute for the
thing it refers to because you have to dereference it here and there.
Usually I make wrappers like you did, to delegate calls. It is a big
nuisance. Then it does not work properly when you have a types hierarchy
and wish to have a corresponding hierarchy of pointers.

This is rather a language problem. Alas, Ada has no support for either
delegation or parallel types hierarchies.

> (interestingly, the remote despatching call may fail from
> communications errors or other failure.  The corresponding
> non-remote call can handle the exception by using the "Find"
> to get another server to call instead, or take other
> recovery actions.  Perhaps this is the way to go...)

You have to decide whether objects are distributed or not. I would provide
both. Sometimes I would like to know the exact location of the object and
be sure that it is the one I am talking with. In other cases the object is
a clique of that provides a service, and I don't care which one does. But
this clique is an object itself, though distributed across partitions.

> I'm wondering whether Annex E has ever been used as a basis
> for a big commercial project...

Firstly, one should get a big project for Ada. (:-)) Then I'd like to see
remote entry calls, I don't know how it is in Ada 2005.

[rant on]
From my application domain (automotive automation), it is very important to
be able to get grip on the transport layer of Annex E. I didn't look at
GLADE, and I don't know how deep it is tangled with the compiler. But we
need the transport layer talking our protocols. Some of them are multicast,
like Ethernet based PGM or FlexRay, CAN, LIN-bus based protocols. That
could make synchronous RCIs difficult, as well as RCI as a paradigm (P2P).
I puzzled some time what an entry call to multiple tasks or a multiple
protected action could be. It seems that it goes in direction of multiple
dispatch anyway. Plain Java programming in Ada makes little sense to me.
[rant off]

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de