TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Classic View

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

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

Print Reply
Mark Lundquist <[log in to unmask]>
Mon, 16 Aug 1999 17:14:25 -0700
text/plain (75 lines)
From:  Roger Racine <[log in to unmask]>

> At 01:37 PM 8/12/1999 , Tucker Taft wrote:
> >Roger Racine wrote:
> >> ... 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."

I don't know if it's fair to infer that from the single example of
GNAT/Lunix-threads.  I think what implementors everywhere really said
was "Finally, some threads.  Now blocking OS services can work right
instead of blocking the whole program".  In the case of Linux, maybe
Linux threads has a bogus design, so that some operation the Ada RTS has
to do in order to map tasks onto threads can only be done in supervisor
mode (it's incredible that changing _thread_ priorities would require
you to be in supervisor mode, since threads share an address space which
is defined by the process -- it must be something else...?).  Maybe the
implementors thought that the benefits of a threads-based implementation
of Ada tasking outweighed the impact on programs that dependend on task
priorities to execute correctly, especially if there is the hope of a
fix to Linux threads in the future.  I'm just speculating here... I
really don't know.  But I doubt the decision had anything to do with a
presupposed link between "real-time performance" and supervisor mode
(for one thing, that would be a very sketchy leap of logic...).

> 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.

I'll bet you would have seen that exact implementation had Linux threads
been around when GNAT Ada83 was ported to Linux!

> >Ada 95 certainly doesn't require run-till-blocked semantics.  That
> >is only required in the presence of the Task_Dispatching_Policy pragma
> >specifying FIFO_Within_Priorities.  In the absence of that pragma,
> >any scheduling of same-priority tasks is permitted.
>
> How many vendors provide more than one policy?  I admit I have limited
> experience with Ada95 compilers (GNAT), but it would be a pain to support
> more than one, and the vendors haven't changed that much from Ada83, and
> they have never liked pain. :-)

Rational's Ada product has two implementations you can choose from on
hosts that support POSIX threads.  There's an implementation that uses
threads, and an implementation that doesn't.  For the implementation
that doesn't (it has a microkernel that handles Ada task scheduling),
you can turn time slicing on or off, and tweak the time slice interval.
The default is to have time-slicing on (i.e., not "run-till-blocked").

Best regards,

--

Mark Lundquist
Senior Software Engineer
Rational Software
Development Solutions Business Unit
UNIX Suites Group
Aloha, OR, USA

ATOM RSS1 RSS2