Re: Help with a Remote Type / Iterator

["Robert I. Eachus" <rieachus@comcast.net>]

Michael Lamarre wrote:

> Basically, this program is a client/server program. One server, many 
> clients. The server will piece together these COLLECTION_TYPEs, stick 
> them in a protected structure, and then the clients will come by and 
> process them. But each COLLECTION_TYPE must have its constituent 
> elements processed in order. The collection will NOT be modified by the 
> server once it is placed into the protected structure for the clients to 
> retrieve it from.

I think I see what you are saying here, but I don't like the way you are 
saying it. ;-)  You have a server which will create collections and pass 
them to clients to process.  Why the change?  With your conditions, 
there is no explicit need for a protected collection type.  The server 
puts together collections and based on some trigger, it passes 
collections to clients to process.   This is easy to model in Ada with 
one server task and many clients.  DO THAT.

First get that working, with entries either where the clients request a 
processing job from the server or with a mechanism for the server to 
call a ready client and pass it data.  Next, change the collection type 
(or whatever parameter type you pass in the task interactions) to a 
remote type, and deal with all the issues of having a program with 
multiple partitions--one server partition and a lot of client partitions.

Does this make for a lot more work?  Not really.  Doing the design first 
as "just" a tasking program, then distributing it will introduce a 
little extra work.  But in my experience it is really worthwhile to 
start the distribution process with a running program, and to be able to 
compare outputs (and timings of course) to insure that the distribution 
part of the system works correctly.  If you can, I would make the 
collection passed to the client partitions a record with an array of 
records.

You don't have to collect the data that way, but why not organize it 
better before sending it between processors?  The advantage is that, 
even if the data structure during accumulation is, say, a linked list, 
the data structure passed between partitions/CPUs is an array (within a 
record) with no explicit or implicit pointers required.

Nick did show how you can create a child package with a remote access 
type, but personally I like to avoid them when possible.

> It almost sounds like you think that we're doing REMOTE_TYPES for the 
> wrong reasons. That is something I started to wonder the other day. If 
> it is such a pain in the butt to iterate over a distributed object, 
> perhaps that's for a reason? (i.e., you shouldn't) Like I said, I'm 
> still not entirely comfortable with classwide types, so I'm not really 
> sure how to tell what types you would want to make REMOTE_TYPES and 
> which to leave normal and just write 'Read and 'Write for. Are there any 
> rules of thumb as to when it is appropriate to make a type a remote 
> type? Thanks for your help.

Yes.  Iterating over a collection of objects of a remote type can mean 
that every object in the collection comes from a different 
partition/processor.  You can do it, and it works.  (In other words, 
remote access types can point between processors.)  But it looks like 
extra overhead because it is.  If you are actually passing collections, 
not individual records, you will usually find that passing them as a 
collection is a lot more efficient.  Of course, if you are doing all 
this on a shared memory architecture system, the collection can be 
passed between partitions by reference instead of by copy.
-- 
                                           Robert I. Eachus

100% Ada, no bugs--the only way to create software.