Re: Fun with Tasking

["Randy Brukardt" <randy@rrsoftware.com>]

<mhamel_98@yahoo.com> wrote in message
news:1175104396.231171.125360@e65g2000hsc.googlegroups.com...
...
> Thank you Adam.  While making this sample program a sneaking suspicion
> started to creep up that I really didn't know what I was doing, and
> you helped verify that suspicion.  What's really going on is I have a
> number of tasks I'm going to run, and while themselves completely
> independent of one another, they send updates to a single listening,
> or collating, task.  That is the task at the heart of my initial
> post.  My approach was to start up this collating task and give it's
> pointer (or address) to the processing tasks.  This works fine if the
> collating task definition is in the acc_add_test procedure and the
> Control_Block has a pointer to that task within it.  However, I would
> like the collating task definition to reside with the "exec" procedure/
> package as the sample has it.  How would one declare and start up that
> task, without any visibility into the package, just a procedure
> pointer with a mode argument?  My (terribly flawed) idea was the
> PreProcess element of the procedure would set that up, but as you
> pointed out, the procedure would never exit while the task is
> running.  So how to define the task and put it on "hold" until the
> processing tasks can utilize it?  I don't expect it's possible without
> incurring as much ugliness as the program has already, but I thought
> I'd give it a try.  Thanks again =)

I'm not going to try to figure out precisely what it is that you are trying
to do (a listening task doesn't require anything special to listen!), but a
couple of thoughts about trying to manage unrelated tasks with another task.

(1) You really don't want to try to manage unrelated anything in Ada (Ada is
strongly typed, after all). If you are using a very new compiler, probably
the best way to relate some tasks that would otherwise be unrelated is to
define them all to be derived from the same task interface. The idea is that
you would put the control operations into the task interface, and then the
manager would use access-to-interface'class to keep track of the tasks and
call operations on them as needed. But you'll need a complete and non-buggy
implementation of the entire Ada language, as amended; so far as I know only
GNAT Pro even claims to support this. So you'd be better off trying to do
this next year...

Note that you have to start each task individually. The usual trick is to
use a constructor function for that purpose.

(2) Otherwise, I'd say that it can't be done reasonably. You could use
Task-Ids to track the status of the tasks,  but that won't help starting
them.

(3) Probably the best plan is to forget about having the management task
interoperate directly with the other tasks. Rather, define an abstract
tagged type (or interface, if you prefer) Processor, and have each package
define any instance of that tagged type. It would have the needed management
operations ("Start", "Status", "Stop", etc.), and again you would create an
appropriate instance of each one (probably with the main program), and have
the management task save a list of these as access-to-Processor'class, and
manage them appropriately.

The advantage of this technique is that you can wrap anything you need in
these operations: if you need a conditional entry call, for instance, you
would just implement one of those operations that way. (That's precisely how
task interfaces get implemented anyway; you're just doing some of the work
that the compiler would done.)

Hope this helps.

                                      Randy.