No_Task_Termination and the main subprogram

No_Task_Termination and the main subprogram

[Maciej Sobczak]

Hi,

I have a philosophical question related to No_Task_Termination
restriction. It requires that tasks do not terminate and the common
wisdom is that tasks in RT software usually have some infinite loop
that satisfy this requirement.

What about the environment task?
Imagine a program where additional tasks are created at library level
to handle some work and where the main subprogram is used to trigger
initialization, configuration, etc. After doing everything, the main
subprogram can:

1. Fall in an infinite loop to clearly show that it does not
terminate. This is artificial.

2. Wait on some dummy condition that is never satisfied. This is even
more artificial and can require setting up separate structures/objects/
etc.

3. Change the role and do some useful work that would normally be put
in a separate task. This introduces arbitrary assymetry in the
project, because one chosen work package is executed in the
environment task whereas others run in their dedicated tasks.

4. Just finish, which means run off the end of the subprogram code,
but without actually terminating the task. The environment task will
never terminate anyway as it will implicitly wait for all other tasks
(which will not terminate either, but there it is a clear outcome of
their design).

I find the last option the most clean, although it needs documenting
that in fact the program is not going to terminate due to other tasks
being still alive. What is your opinion about it?

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Database Access Library for Ada: www.inspirel.com/soci-ada

Re: No_Task_Termination and the main subprogram

[Martin]

Option 4. This is what the main procedure has done on every system
I've ever worked on in the last >15 years. Never a problem. I can't
even remember it even being commented on that the environment task
might still be executing and waiting on all the other tasks to
complete - it's just never an issue, as they aren't expected to
complete!

Cheers
-- Martin