TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

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

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

Print Reply
Subject:
From:
Roger Racine <[log in to unmask]>
Reply To:
Roger Racine <[log in to unmask]>
Date:
Thu, 12 Aug 1999 08:43:46 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (74 lines)
At 02:56 PM 8/11/1999 , Tucker Taft wrote:
>When you say "the semantics are the same..." that really depends on
>the context.  In the "Ada" core, the semantics do not specify anything
>about scheduling of tasks, and doesn't even mention priorities.
>In the real-time annex, the semantics are much more specific, and provide
>additional guarantees.  These guarantees *are* dependent on the
>number of physical processors, so in that sense, the Annex semantics
>do depend on how same-priority tasks are scheduled.  In a sense, you
>could define a "real-time" system by one whose semantics do depend
>(at least potentially) on the details of the scheduling algorithms and
>policies.
>

In my opinion, the Ada95 design is much, much worse than the Ada83 design
in this area.

1) In Ada83, priorities were pretty much guaranteed to work.  Yes, I know
there was an AI that opened up the meaning of "sensibly", but the vast
majority of implementations, on a uniprocessor, did the right thing.  If a
high priority task became eligible for execution, it pre-empted a
lower-priority task.

In Ada95, priorities have no guarantees to work unless A) one uses a
specific pragma; and B) the compiler was validated for Annex D for that
particular OS and runtime system and pragma parameter.  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.  For the present we
are able to get around this limitation by using FSU threads, but I have
been told that this should not be a long-term solution, and that other
implementers also now require supervisor mode.  This is a major step
backwards for Ada.  I find it inconceivable that one would even consider
running a validation suite on a compiler in supervisor mode.  On multi-user
systems, we have very clear rules that supervisor mode will be limited to 1
or 2 people for specific purposes (installation of programs, etc.).  If it
is needed for high-performance processing (such as specifying processors
for tasks on a multiprocessor system), it is scheduled in advance and all
the other users are off the system (since the whole machine is being used
for a single application anyway).

I was quite surprised (unhappily) when a design that had worked for 15
years suddenly required supervisor mode.

2) In Ada83, tasks were very much defined to be concurrent processing
paths.  Problems occurred when calling system services (the whole program
blocked), but one got used to that and worked around it.  If a program
depended on different than concurrent behavior, it was erroneous.  It made
for quite portable applications and generally safe designs (i.e. if the
priority of a task changed, it did not affect data consistency).  We
typically made sure we tested our programs with time-slicing on to make
sure it was designed well.  Now it appears that Ada95 requires
run-till-blocked semantics, which will lead to designs depending on that
semantics.  This will lead to non-portable programs and programs that are
much less easy to mantain.  All for what?  So that time-slicing is
guaranteed not to exist, if the pragma is used and if the compiler is
validated for the pragma on the specific OS.  This was not a problem on any
target platform I used for Ada83, since it was always possible to turn off
time-slicing in the underlying operating system, or in the Ada runtime
environment on a bare machine.

It appears to me that 2 things occurred in the Ada95 design process.
First, some hard-real-time people insisted on fixing something that was not
a problem (time slicing).  And second, Ada vendors insisted on taking
priorities out of the core language so that it would be easier to implement
the core on top of existing threads-based operating systems.  These 2
decisions have made it actually harder to use Ada95, for no gain that I can
see.

Roger Racine
Draper Laboratory, MS 31
555 Technology Sq.
Cambridge, MA 02139, USA
617-258-2489

ATOM RSS1 RSS2