Re: Ichbiah 2022 compiler mode

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message
news:lkg1vvF1tp6U1@mid.individual.net...
...

Priorities are just optimization on how to manage cores when there are
not enough of them.

>
In some contexts it could be optimization -- for example, to increase
throughput in a soft real-time system -- but in hard real-time systems
priorities (or deadlines) are needed for correctness, not just for
optimizatiion.

This I don't buy: priorities never help for correctness. At least not
without extensive static analysis, but if you can do that, you almost
certainly can do the correctness without depending upon priorities.

I view priorities as similar to floating point accuracy: most people use
them and get the results they want, but the reason for that is that they got
lucky, and not because of anything intrinsic. Unless you do a lot of
detailed analysis, you don't know if priorities really are helping or not
(and similarly, whether your results actually are meaningful in the case of
floating point).

Anyway, I don't see any such changes coming to Ada, but rather to some
separate follow-on language (which necessarily needs to be simpler), and
thus some things that are sometimes useful would get dropped.

(Different message)
...

Ok, I understand. In that case, what "parallel" adds to the current
tasking feature is an easy way to create a largish and perhaps dynamically
defined number of concurrent threads from a "parallel" loop, where the
threads are automatically created when the loop is started and
automatically "joined" and destroyed when the loop completes.

I think the parallel block is more useful for general tasking. The advantage
of using parallel structures is that they look very similar to sequential
structures, and one lets the system do the scheduling (rather than trying to
figure out an organization manually).

One of the advantages of the model I'm thinking about is that it separates
concerns such as parallel execution, mutual exclusion, inheritance,
organization (privacy, type grouping), and so on into separate (mostly)
non-overlapping constructs. Ada started this process by having tagged types
a separate construct from packages; you need both to get traditional OOP,
but you can also construct many structures that are quite hard in
traditional "one construct" OOP. I think that ought to be done for all
constructs, and thus the special task and protected constructs ought to go.
We already know that protected types cause problems with privacy of
implementation and with inheritance. Tasks have similar issues (admittedly
less encountered), so splitting them into a set of constructs would fit the
model.

In any case, this is still a thought experiment at this time, whether
anything ever comes of it is unknown.

                Randy.




               Randy.