TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

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
Subject:
From:
Samuel Mize <[log in to unmask]>
Reply To:
Samuel Mize <[log in to unmask]>
Date:
Thu, 22 Apr 1999 11:16:19 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (122 lines)
> Ada 95 introduced protected types, and
> information on the new concurrent standard, which I
> heard was the thing most changed from 83,

It sounds as if you may not have the best information available.

You'll find a lot of info about Ada at http://www.adahome.com and
http://www.acm.org/sigada, and those have pointers to other web sites.

You may also want to look at the Ada 95 Rationale, which explains a
lot of the design decisions that went into Ada 95.  You can get an
electronic copy at either of those sites.

- - - - - - - - - -

> One
> issue I had, was that I read somewhere that protected
> procedures and so forth, when executed, will run until
> completed, and not be interrupted by time slicing and
> so forth.

Well, this is confused.

I'll answer you publicly so others can correct any mis-statements,
if any.  I don't want to leave you MORE confused!

- - - - - - - - - -

Perhaps your source meant that operations that can CHANGE the
protected object are serialized.  Several tasks may have concurrent
read access to the object, or one task may have exclusive write
access (no reads during a write access).

Or, your source may have confounded together the following:

1) It is an error for a protected action to wait for another task to
   do something, as this could cause deadlock.  (That's a VERY loose
   statement of the formal language rule:  "During a protected action,
   it is a bounded error to invoke an operation that is potentially
   blocking."  (Ada Reference Manual, 9.5.1 paragraph 8.)

   In other words, once a task gets hold of the protected object, it
   shouldn't just hang on indefinitely -- it should do its job and get
   out, so other tasks can get at the resource.  If the resource needs
   processing that is extended or involves several tasks at once, it's
   too big for a simple critical region -- it should be protected by
   its own task.

2) Annex D of the Reference Manual says that, once a task gets the
   CPU, it runs until it hits a "task dispatching point."  These are
   points where the task may be expected to give up the CPU, for
   example when it is waiting to synchronize with another task.

   But conformance to Annex D is NOT required.  It's an optional set
   of constraints for compilers aimed at a real-time environment, and
   it describes one well-defined, predictable task scheduling method.

   A given compiler may provide Annex-D-style task scheduling, or it
   may not.  It may give you a choice between that and other
   scheduling methods like time-slicing.

   The core Ada 95 standard sets no task scheduling policy at all.

- - - - - - - - - -

> Is there a specific way [time slicing] happens in the
> 95 standard, or is it implementation dependent?

If the compiler supports another scheduling discipline, it's
specified with a "pragma" statement.

> I'm also curious if there is a compiler out there
> which does enforce consistant time slicing, since Gnat
> supposedly doesn't.

I don't know which (if any) compilers support time-slicing.

However, GNAT should, with a manual trick.

A task can give up the CPU by executing a "delay" statement.  If I
recall correctly, using a compiler that offers compliance with Annex
D -- like GNAT -- a higher-priority task that is in a delay will take
the CPU back from a lower-priority task as soon as the delay expires.

So, make a highest-priority task that repeatedly delays for a
time-slice, then executes a task dispatching point.  It looks like:

    task body Slicer is
    begin
        loop
            delay 0.01; -- seconds
        end loop;
    end Slicer;

(which I expect you can read even if you're unfamiliar with Ada.)

A delay statement IS a dispatching point.  The other tasks, if they
are of equal priority, will round-robin share the processor.

(Strictly speaking, if one of the tasks gives up the CPU early by
executing a dispatching point, the next one won't get a full slice --
just the rest of the current slice.  But this guarantees that all
tasks will periodically get SOME CPU cycles, which is usually the
point of time slicing.)

- - - - - - - - - -

I hope you found this to be of interest.  I urge you to look at the
web sites, and follow their pointers to the available books and
on-line tutorials.  I think you'll find Ada to be very effective for
multitasking and multiprocessing systems.

> -Matt Goulet
> aka The Mildly Infamous Blue Herring

Best,
Sam Mize

--
Samuel Mize -- [log in to unmask] (home email) -- Team Ada
Fight Spam: see http://www.cauce.org/ \\\ Smert Spamonam

ATOM RSS1 RSS2