Re: tasking in Ada and Annex D question

[Niklas Holsti <nholsti@icon.fi>]

Markus Kuhn wrote:
> 
> In robert_dewar@my-dejanews.com writes:
> |> The FSU threads need supporting for at least a while for
> |> two reasons:
> |>
> |> [...]
> |> 2. They may well be far more efficient, that is true on
> |> many targets, did you experiment with this aspect. A lot
> |> of people do not need concurrency with system calls (indeed
> |> a properly written portable Ada program cannot rely on
> |> such concurrency, since it is not guaranteed by the Ada
> |> standard), and if FSU threads are more efficient, they
> |> may be preferable for many real applications.
> 
> What I have a bit of a problem to understand is, for what
> else apart from preemptive scheduling, concurrency when system
> calls block, and utilization of multiprocessor systems do I
> need tasks for (i.e., all the things FSU doesn't do)?

You need tasks to modularise your program's NON-synchronised
(i.e. logically concurrent) functions, while programming each
such function in an easy-to-understand sequential manner.

I do agree that for most Linux applications I can imagine, barring
really embedded stuff, the properties of native Linux threads
seem more suitable, especially for the system calls.

> I realize
> that tasks were the only real synchronization mechanism in Ada83,

For me the chief attribute of tasks is that they are logically
concurrent, not that they occasionally synchronise.

> but we now have protected objects to do this more efficiently
> without context switches. So I believe that in Ada95, the
> concurrency of tasks is much more important than the performance
> of task switches,

IMHO this was also the case in Ada 83 and all other multi-tasking
systems, too.

I don't have an opinion on which threads package to adopt for
GNAT on Linux, but wanted to butt in with the above.

- Niklas