Re: Problem with tasks

["Ehud Lamm" <mslamm@mscc.huji.ac.il>]

> Right. That's why a good design would make use of a task-allocator
> abstraction, which may allocate a new taks, but may later be changed to
> manage a finite sized pool of tasks (the "thread pool" pattern).
>


Creating such a task allocator (or manager) abstraction is far from trivial.
Some difficulties stem from Ada's apporach to tasking.

Ada tasks types are not polymorphic, in the sense of allowing you create
code that accepts any tasks supporting a given interface.
In Ada95 we can solve this problem by vreating a tagged type that
encapsualtes the task: All task type that support a given interface will
simply derive from this type, allowing us to code class-wide routines, store
them in heterogenous structures etc.
(This approach has some problem. Using this approach we will not call task
entries directly, but rather by using a wrapper routine. The excludes the
possibility of timed-entry calls etc. This approach is also rather
cumbersome and verbose).

Another related issue is that tasks in this scheme must all behave along
similar lines (e.g., they usually all have to be server tasks accepting work
inside a loop.  Exit/Restart entries may be needed, esp. if you want to
support resing existing tasks instead of allocating new tasks, and task may
have initial operation and state).
In a sense we may want parametrized tasks.
There are several ways of doing this in Ada: using generic packages (but
this is a bit restrctive), or using another tagged type hierarchy, and have
tasks parametrized (using an access discr. for example) with a specific type
defining their behaviour.

Other more technical design issues exist. A major issue is copying tasks
(tasks are limited, so one must use access values), and GC them
(Controlledness maybe problematic with all the inheritance going around, we
don't have MI). We must also remember that tasks are by their very nature
mutable: a task has state. This makes aliasing very problematic, and thus
copying tasks is essential, yet difficult (recall that the tasks themselves
are "limited"). How do we solve this prolem?
If you answer is to use task allocator abstracion, You should reread this
message... :-)

All this makes this an interesting problem. I'd love to hear experiences
people had with building such a thing (esp. in Ada95, since it offers what
seem to me to be useful tools).
My attempts are in rather more restricted domain; when finished I'll put
them up somewhere.


Ehud Lamm