Re: Tasks in Ada

[rlk@VisiCom.COM]

> What happens if we have Tasks without any entries ?
> 
> The tasks are instanstiated when the task body
> is elobrated .
> If there are more then one tasks I think
> the implementation decides which task starts first
> and then the tasks are inter-leaved (including the implicit main task).

Well, the startup-up of the tasks isn't quite interleaved. If you start
up a task without entries, and if your implementation does not time-slice, 
then you may end up with a task grabbing all of the CPU, preventing other
tasks from starting up.  Generally, it's a good idea to have 'startup'
entries on each of your tasks, and have a system controller start them
in the proper order, rather than relying on the tasks' elaboration and
startup ordering.

> Is it possible to provide mutual exclusion and synchronization
> to these tasks using pragma shared on a integer variable and
> using it as a semaphore?
> Would it depend on how implementation deals with tasks 
> (multi-tasking or time-slicing)?
> 
> Jani

Perhaps I'm missing something here, but the whole reason that the 
rendezvous was chosen as a synchronization mechanism was to get 
us away from low-level mechanisms such as semaphores, and towards 
more reliable mechanisms.  Why not just use a rendezvous?  You can 
write a semaphore task using rendezvous, but that's kind of like 
using a metal shop to build flint knives.

But if you're being pedantic... the answer is still 'no'.  For example,
How can you suspend a task that fails in its attempt to acquire a
semaphore?  The language provides no primitives to do this, and
attempting to do it on your own requires more knowledge about the
internals of the compilers runtime system (both code generator-wise and
kernel-wise) then is provided by vendors.

Many Ada development systems provide interfaces to real-time kernels
that underly their tasking systems.  Usually, more traditional (read:
non-portable, but sometimes necessary) synchronization primitives  are
provided in these kernels, such as semaphores, message passing, etc.
Personally, I think that these non-portable interfaces should be used
as a last resort, only when a pure tasking solution is either untenable
or too bulky.  The tasking mechanisms built into the language can solve
quite a few problems, in an elegant manner.

	.Bob.