[log in to unmask] (Roger Racine) quoted and then wrote:

>At 01:37 PM 8/12/1999 , Tucker Taft wrote:
>>Roger Racine wrote:
>>> ...
>>
>>Note that in Ada 83, there were no guarantees about the number of
>>priorities, and that is why we moved the entire priority model
>>to the RT Annex, while at the same time imposing additional requirements,
>>such as a minimum of 30 priority levels.
>>
>>> ... For a very clear
>>> example, we used to be able to run multitasking programs in application
>>> mode on every platform (Ada83).  Now, for GNAT using Linux threads (not
>>> validated for Annex D), one must be in supervisor mode.
>>
>>I don't think these two things are directly related.
>>
>
>Here is how they are related.  For most implementations of Ada83, tasking
>was implemented by the runtime system, using one OS process.  It did not
>matter what the OS did with priorities (such as changing them to guarantee
>service).  With Ada95, it appears that implementers have said: "Well, if
>the user wants Annex D, they must want real-time performance.  That is the
>whole point of the annex.  If they want real-time performance, they must be
>in supervisor mode.  So if they are not in supervisor mode, anything can
>happen, since we will not validate Annex D in user mode."  For example, on
>Linux if you are in user mode, you are not allowed to change your priority,
>except downward.  So an Ada runtime implemented using Linux Threads must be
>in supervisor mode to even get priorities set up correctly.
>
>>You may need to be in supervisor mode to disable time-slicing and get
>>true "real-time" behavior.  However, you should certainly be able
>>to "run multitasking programs" on all Ada 95 platforms without being
>>in supervisor mode.  It is possible that you won't get the same guranatees
>>about priority-based preemption, but that is presumably because those
>>guarantees can't be provided without being in supervisor mode.
>>I presume that if you run in non-supervisor mode, the Ada run-time
>>does the best it can.  If not, that sounds like an implementation bug,
>>not a language bug.
>>
>
>When not in supervisor mode, the implementation supplies the core language
>behavior (i.e. no priorities).  Not a bug.  In Ada83, the core language
>included priorities.  This behavior would have been a bug.  OK, an
>implementor could say they were only providing one priority, but I never
>saw that implementation.
>
>You say that "guarantees can't be provided", which needs expansion.  They
>can be provided, just not if one implements tasking using services of the
>OS that require supervisor mode.  For example, many Ada83 vendors had their
>own implementation of tasking.  This was because A) OSs did not support
>multiple tasks in the early 80s; or B) those OSs that did support multiple
>tasks did not support Ada semantics well enough.

I don't understand the part about Supervisor Mode at all, but my
background
is VMS where there may be a wider set of controls available.

Given that an implementation chooses to map Ada tasks onto separate OS
constructs
(processes, threads, fibres, etc.) the ability to lower priority of those
entities
(and, I presume, to raise it back to no higher than where it had been)
should
allow an implementor to provide whatever behavior is desired.  (Obviously
there
is nothing that can be done about non-Ada code running at high priority,
but that
seems a matter of system management and what projects get put on what
computers.)

Larry Kilgallen