TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy


Options: Use Forum View

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

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

Print Reply
Mark Lundquist <[log in to unmask]>
Reply To:
Mark Lundquist <[log in to unmask]>
Wed, 18 Aug 1999 14:49:08 -0700
text/plain (87 lines)
From:  Simon Wright <[log in to unmask]>

> 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 applicatio
> > > >> mode on every platform (Ada83).  Now, for GNAT using Linux threads (no
> > > >> 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 guarante
> > > service).  With Ada95, it appears that implementers have said: "Well, if
> > > the user wants Annex D, they must want real-time performance.  That is th
> > > whole point of the annex.  If they want real-time performance, they must
> > > 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).

Hmmm... I'm looking at the pthread_setschedparam(3) manpage on Solaris
2.6.  It doesn't mention root privileges, that I can see.

The POSIX standard does say that the implementation _may_ require
special priveleges for pthread_setschedparam().  It doesn't have to...

The thread scheduler runs in user space on Solaris.  The contention
scope of an "unbound" thread is intra-process.  pthread_setschedparam()
is only used on unbound threads -- it has no effect on a thread that is
bound to an LWP.  Scheduling parameters for LWPs are manipulated using
priocntl(2) on Solaris -- and there, there are indeed rules about
priority changes that require super-user privileges.

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

The scheduling policy classes on Solaris -- realtime and time-sharing
-- have to do with LWPs, not threads.  Your comments suggest that maybe
what GNAT has done is to exclusively use bound threads (and create one
LWP to serve each thread?)

Anyway... these pthreads details are parenthetical.  (If I hadn't
overreached in my reply to Roger, saying that I couldn't even _believe_
you had to be root to change a thread priority, it wouldn't have come
up :-)


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