From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ed1009970959aab0 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-12-02 15:17:58 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!small1.nntp.aus1.giganews.com!border1.nntp.aus1.giganews.com!intern1.nntp.aus1.giganews.com!nntp.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail NNTP-Posting-Date: Tue, 02 Dec 2003 17:17:55 -0600 Date: Tue, 02 Dec 2003 18:17:53 -0500 From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Help with a Remote Type / Iterator References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: NNTP-Posting-Host: 24.34.214.193 X-Trace: sv3-gJzEUqP38GI+17/eSJKnxc+7dxPgPsscptfEe/KgrXeBGtGgPXd6/HXbwls1jmfwJL/QyUpdZmpxcYD!Q9JpZFQSN1sKH6W2Nmp/53pPFe3HHauU5b3yql7aE1ubBLqbJ/2PAULaQITEDQ== X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.1 Xref: archiver1.google.com comp.lang.ada:3081 Date: 2003-12-02T18:17:53-05:00 List-Id: 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.