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
Condense Mail Headers

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

Print Reply
Sender: "Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
From: Simon Wright <[log in to unmask]>
Date: Tue, 17 Aug 1999 21:19:26 +0100
In-Reply-To: <[log in to unmask]> (message from Mark Lundquist on Mon, 16 Aug 1999 17:14:25 -0700)
Reply-To: Simon Wright <[log in to unmask]>
Parts/Attachments: text/plain (56 lines)
Mark Lundquist <[log in to unmask]> wrote
> > 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...?).

No, it's not the mapping onto threads, it's the way the OS (POSIX, I
believe) treats thread priorities.

And it's not just Linux; Solaris (2.6, anyway) behaves exactly the
same way.

Solaris has various dispatching classes (real time, time sharing ..)
which Linux doesn't but the behaviour to the naive user (eg me) is the
same.

If you are not root you can't alter thread priorities[1]; see
pthread_setschedparam(3).

The way GNAT works is that if you aren't root then your tasks' OS
priorities are normal (on Solaris, in the time sharing class); if you
/are/ root then your tasks' OS priorities are real-time (in the real
time dispatching class). So, if your Ada program [that initiates
tasking support] gets into a tight loop it's likely to be Big Red
Switch time if you ran it as root ..

[1] for SCHED_FIFO, SCHED_RR

--
Simon Wright                        Work Email: [log in to unmask]
Alenia Marconi Systems                         Voice: +44(0)1705-701778
Integrated Systems Division                      FAX: +44(0)1705-701800

ATOM RSS1 RSS2