TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy


Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sun, 15 Aug 1999 15:32:51 EDT
text/plain (74 lines)
[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
is VMS where there may be a wider set of controls available.

Given that an implementation chooses to map Ada tasks onto separate OS
(processes, threads, fibres, etc.) the ability to lower priority of those
(and, I presume, to raise it back to no higher than where it had been)
allow an implementor to provide whatever behavior is desired.  (Obviously
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

Larry Kilgallen