Q re glade for slaves.

Q re glade for slaves.

[Bobby D. Bryant]

I've just started in on distributed programming, and I can modify some
of the gnat-glade examples to do what I need (structurally), but the
solution I came up with doesn't seem very elegant, so I wonder if anyone
has a better suggestion before I get too far in to it.

I need a master and some number of slaves.  The slaves will all execute
identical code on different data, and their work is very CPU-intensive,
so I would like to run each slave on a different processor.  In most
cases I will simply let the number of processors available dictate the
number of slaves to be used.  The master will communicate with the
slaves intermittently while the distributed job runs, and do a bit of
collation when the slaves are all finished with their share of the
work.  The slaves do not need to share any common state.  (FYI, this is
not a non-terminating server system; rather, for each run of the job it
will start, run for a few hours, and be finished.)

The solution that I came up with is to create a generic package for the
common code for the slaves, create an instance of that package for each
slave, and have the .cfg file assign each instance to a different
processor.  However, since the Remote_Call_Interface pragma seems to
apply to library units rather than to instances of a generic package
that can be created at run time, my solution means I have to decide in
advance how many slaves I want, and provide a separate file to
instantiate each one.

This is not a show-stopper, because changing the number of slaves this
way is a very small amount of work.  However, I would be surprised if
something more flexible is not possible.  Am I missing something?

Thanks,

Bobby Bryant
Austin, Texas

Re: Q re glade for slaves.

[Bobby D. Bryant]

Wilhelm Spickermann wrote:

> On 08-Apr-01 Bobby D. Bryant wrote:
> ...
> > The solution that I came up with is to create a generic package for
> > the
> > common code for the slaves, create an instance of that package for
> > each
> > slave, and have the .cfg file assign each instance to a different
> > processor.  However, since the Remote_Call_Interface pragma seems to
> ...
> You can dynamically add and remove clients even if the machine didn´t
> exist when the cfg files were made. But the clients are not accessed by
> an RCI -- RCIs are too static. You have to use dispatching calls for
> that.
>
> Example:

OK, thanks.  It looks like the Examples/Bank/ application that comes with
gnat-glade does something similar to what you described for the
registration, although the server does not directly demand any work from
the clients in that example.

Do I understand correctly that in your outline the server can call a
procedure or function that is defined by the client, even though he client
is not pragma'd to be an RCI?  It looks like that is what you are
suggesting, and that the "Where" argument causes the call to be dispatched
to the correct client.

If that is correct, then I could just have a newly launched client call the
server for registration, and have the server immediately turn arround and
call a routine on the client as part of the registration logic, so that the
client in effect becomes a slave.  Right?

Thanks,

Bobby Bryant
Austin, Texas

RE: Q re glade for slaves.

[Wilhelm Spickermann]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 1712 bytes --]


On 08-Apr-01 Bobby D. Bryant wrote:
...
> The solution that I came up with is to create a generic package for
> the
> common code for the slaves, create an instance of that package for
> each
> slave, and have the .cfg file assign each instance to a different
> processor.  However, since the Remote_Call_Interface pragma seems to
...
You can dynamically add and remove clients even if the machine didn�t
exist when the cfg files were made. But the clients are not accessed by
an RCI -- RCIs are too static. You have to use dispatching calls for
that. 

Example:

1. make a pure package ("Places") containing something like
   type Abstract_Place is abstract tagged limited private;
   procedure doit1(Where: access Abstract_Place;...) is abstract;
   procedure doit2(Where: access Abstract_Place;...) is abstract;
   (All the subprograms take a parameter "Where")
   This allows the server to call the subprograms.

2. a "non netwide" package ("Places.Local") containing something
   like:
   type Place is new Abstract_Place with private;
   Override the subprograms with what You need.
   This package is used by the clients. Note that every partition has
   it�s own type "Place".

3. a "non netwide" package("Terminals.Local.Identification") creating a
   variable of that type:
   Id: aliased Places.Local.Place;

4. The client partitions transfer that "Id" as a parameter to the server
   using the servers remote call interface.

5. The server should maintain a list of these ids and use them as
   parameters for all the subprograms which should be executed in the
   client partitions. The call will be dispatched according to the
   Id-Type and so it will use the correct partition.

Wilhelm

Re: Q re glade for slaves.

[Bobby D. Bryant]

Wilhelm Spickermann wrote:

> I think so. BTW: the RM contains a very good example in E.4.2

I looked at that a bit on the Web this morning, and I've also been playing
with the code in the gnat-glade Bank example.  It was pretty easy for the
server to make something happen on the client end once I figured out where
to put the call.  However, it still looks like there are more layers of
code than I would have thought necessary, and the visibility is a bit
obscure as well.  I've been trimming the example down to a minimal program
that still works, and I think I'm almost there with it, so that should
help me understand what's going on better.

Thanks again,

Bobby

Re: Q re glade for slaves.

[Wilhelm Spickermann]

On 08-Apr-01 Bobby D. Bryant wrote:
...
> 
> Do I understand correctly that in your outline the server can call a
> procedure or function that is defined by the client, even though he
> client
> is not pragma'd to be an RCI?  It looks like that is what you are
> suggesting, and that the "Where" argument causes the call to be
> dispatched
> to the correct client.
> 
> If that is correct, then I could just have a newly launched client
> call the
> server for registration, and have the server immediately turn arround
> and
> call a routine on the client as part of the registration logic, so
> that the
> client in effect becomes a slave.  Right?

I think so. BTW: the RM contains a very good example in E.4.2

Wilhelm