From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,613613e262e11a1d
X-Google-Attributes: gid103376,public
From: mheaney@ni.net (Matthew Heaney)
Subject: Re: task question
Date: 1996/09/23
Message-ID: <mheaney-ya023080002309961904030001@news.ni.net>#1/1
X-Deja-AN: 184957225
references: <51hg8f$1ei@infosrv.rz.unibw-muenchen.de>
content-type: text/plain; charset=ISO-8859-1
organization: Estormza Software
mime-version: 1.0
newsgroups: comp.lang.ada
Date: 1996-09-23T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <51hg8f$1ei@infosrv.rz.unibw-muenchen.de>,
e81bnick@kommsrv.rz.unibw-muenchen.de (Nicolay Belofastow) wrote:

>I am novice in ADA, and  have a question concerning operator
>ACCEPT:

FYI: Ada is not an acronym, it's the name of Ada Lovelace, Charles
Babbage's assistent and the world's first programmer.  In fact, the
original military standard, MIL-STD-1815, is named in honor of the year of
her birth.  So you don't capitalize Ada (or else I think it's a post about
the American Dental Association!).

Also, aviod all-uppercase keywords (and identifiers), as it's hard on the
eyes!  People that study these kinds of things (read Ben Schneiderman's
book) note that humans read mixed case type more easily than all-uppercase. 
It's best to use all-lowercase for keywords, and mixed-case for
identifiers.

Yes, it's true that early Ada textbooks (including the Ada83 LRM) used
all-uppercase type for identifiers, but the Ada community has forsworn that
use in favor of a different idiom.

>
>normal usage would be somewhere in the task body:
>
>accept Entry( Par1 : integer) do 
>  -- some actions here;
>end Entry;
>
>my program with accept, compiled by GNAT 3.04 shows, that body of
>the accept (commented as "some actions") looks like protected 
>section -- before "some action " is not finished, no other task 
>gets control. The question is -- is this standard feature of the
>ADA, or it is only belongs to GNAT or Windows 95?

It is not true that no other task gets control.  In other words, some other
task can get control.  This is  the legal Ada (note capitalization...)
behavior.

It's a common misunderstanding about Ada's tasking rules to think that
during a rendevous the task(s) can't get interrupted.  This is incorrect,
because the tasks participating in the rendevous *can* get interrupted by a
task of higher priority (for example, because an external interrupt occurs
on a task entry).

Of course, the rendevous is still a sort of critical region, and neither
task will handle other entry calls until the rendevous is finished.

I don't have my Ada95 LRM handy, but here's the applicable section of the
Ada83 LRM, section 9.8, paragraph 4:

"The effect of priorities on scheduling is defined by the following rule:

If two tasks with different priorities are both eligible for execution and
could sensibly be executed using the same physical processors and the same
other processing resources, then it cannot be the case that the task with
the lower priority is executing while the task with the higher priority is
not."

Here's what AI-00032 says:

"Preemptive scheduling is required.

If an implementation supports more than one priority level, or interrupts
[interrupts is called out explicitly because the LRM mandates that
interrupts occur at higher-than-normal priorities], then it must also
support a preemptive scheduling policy."

What this is all saying is that while the rendevous is executing, another
task can interrupt the rendevous and grab the CPU.

Try it:

with Text_IO;
procedure Rendevous_Interruptus is

  task P is
     entry E;
     pragma Priority (0);
   end P;

   task Q is
      pragma Priority (0);
   end;

   task High_Priority is
      pragma Priority (15);
   end High_Priority;
   

   task body P is
      Y : Boolean := False;
   begin
      Main:
      loop
         accept E do          
            loop
               Y := not Y;
            end loop;
          end E;
      end loop Main;
   end P;

   task body Q is
   begin
      P.E;
   end;

   task High_Priority is
   begin
      loop
         delay 1.0;
         Text_IO.Put_Line ("Hello!");
      end loop;
   end High_Priority;

begin
   null;
end Rendevous_Interruptus;

Task High_Priority should wake up once a second, interrupt the rendevous
between P and Q, and print the message "Hello!".

>Thanks in advance, Nick.

Your welcome!  Keep the posts a-comin', and let us know how you're doin'!

matt

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
mheaney@ni.net
(818) 985-1271