Task question

Task question

[Larry Coon]

I'm having a problem getting a task body to work
the way I want it to.  Here's a contrived example
showing (with illegal syntax) what I want to do:

task body x is
begin
   loop
      select
         accept my_rendezvous (some_data: some_data_type) do
            -- Rendezvous stuff
         end my_rendezvous;
      or
         exit;  -- This is illegal
      end select;
   end loop;
   -- Now do more stuff.
end x;

The idea is that this task serves as a collector.
Another task continually initiates rendezvous (what
is plural for rendezvous?), with this task, and this
tasks collects the information that is sent.  When the
"calling" task is done it terminates.  Since the select
statement is smart, it knows it can't be called any
more and invokes the exit, which terminates the loop
so the rest of the task body executes, and it does
more stuff.  That's how I want it to work, anyway.

If I do:

   or
      terminate;

in place of the exit then it knows when the "calling"
task is done and will terminate the task, but this isn't
what I want -- the "other stuff" never gets executed.

I've also tried adding another accept as a signal for
when the "calling" task is done:

task body x is
begin
   loop
      select
         accept my_rendezvous (some_data: some_data_type) do
            -- Rendezvous stuff
         end my_rendezvous;
      or
         accept done do
            exit;
         end done;
      end select;
   end loop;
   -- Now do more stuff.
end x;

Now the "calling" task keeps initiating a my_rendezvous,
but when it's finished it inititates a done to let this
task know it can proceed.  This doesn't work either -- it
doesn't let an exit transfer control out of the accept
statement.

Am I missing an obvious way to do what I want?

Larry Coon
University of California
larry@fs2.assist.uci.edu
and lmcoom@home.com

Re: Task question

[David C. Hoos, Sr.]

Larry Coon wrote in message <3439D647.7C43@home.com>...
>I'm having a problem getting a task body to work
......... <snip> ........
>Am I missing an obvious way to do what I want?
>
>Larry Coon
>University of California
>larry@fs2.assist.uci.edu
>and lmcoom@home.com

Yes.  Make your task body look like:

task body x is
  Finished : Boolean := False
begin
   loop
      select
         accept my_rendezvous (some_data: some_data_type) do
            -- Rendezvous stuff
         end my_rendezvous;
      or
         accept done do
            Finished := True;
         end done;
      end select;
      exit when Finished;
   end loop;
   -- Now do more stuff.
end x;

David C. Hoos, Sr.,
david.c.hoos.sr@ada95.com

Re: Task question

[Larry Coon]

David C. Hoos, Sr. wrote:

> Yes.  Make your task body look like:

[code snipped]

Thanks -- that's exactly how I eventually ended up
doing it (my excuse for not seeing it immediately is
that it was late).  But I was still wondering if there
was a more direct (not using a flag) way of doing it.
I guess not.  Thanks for your reply.

Larry Coon
University of California
larry@fs2.assist.uci.edu
and lmcoon@home.com

Re: Task question

[Steve O'Neill]

David C. Hoos, Sr. wrote:
> Yes.  Make your task body look like:

or this
> 
> task body x is
> begin
>    loop
>       select
>          accept my_rendezvous (some_data: some_data_type) do
>             -- Rendezvous stuff
>          end my_rendezvous;
>       or
>          accept done;
           exit
>       end select;
>    end loop;
>    -- Now do more stuff.
> end x;

Re: Task question

[Matthew Heaney]

In article <61d2bf$f0n$1@polo.advicom.net>, "David C. Hoos, Sr."
<david.c.hoos.sr@ada95.com> wrote:


>Yes.  Make your task body look like:
>
>task body x is
>  Finished : Boolean := False
>begin
>   loop
>      select
>         accept my_rendezvous (some_data: some_data_type) do
>            -- Rendezvous stuff
>         end my_rendezvous;
>      or
>         accept done do
>            Finished := True;
>         end done;
>      end select;
>      exit when Finished;
>   end loop;
>   -- Now do more stuff.
>end x;

How about

task body x is
begin
   loop
      select
         accept my_rendezvous (some_data: some_data_type) do
            -- Rendezvous stuff
         end my_rendezvous;

      or
         accept done;
         exit;

      end select;

   end loop;

   -- Now do more stuff.

end x;

I don't think the flag is required.

This is similar to the idiom for shutting down a task:

task body T is 
begin
   Main:
   loop
      select
         accept E;

         <do some work>

      or
         accept Shutdown;
         exit Main;

      end select;
   end loop Main;

   <perform cleanup>
end T;

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Task question

[Tom Moran]

Setting Finished on the 'accept done' is certainly the best solution.
Another way to get 'last wishes' performed after a 'terminate'
alternative is to have some Controlled type declared - it's Finalize
routine will be called after the terminate and can do some cleanup or
whatever.

Re: Task question

[Matthew Heaney]

In article <3439D647.7C43@home.com>, lmcoon@home.com wrote:

>I'm having a problem getting a task body to work
>the way I want it to.  Here's a contrived example
>showing (with illegal syntax) what I want to do:
>
>task body x is
>begin
>   loop
>      select
>         accept my_rendezvous (some_data: some_data_type) do
>            -- Rendezvous stuff
>         end my_rendezvous;
>      or
>         exit;  -- This is illegal
>      end select;
>   end loop;
>   -- Now do more stuff.
>end x;

task body x is
begin
   loop
      select
         accept my_rendezvous (some_data: some_data_type) do
            -- Rendezvous stuff
         end my_rendezvous;
      else
         exit;
      end select;
   end loop;
   -- Now do more stuff.
end x;

Just change the or to an else.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Task question

[Larry Coon]

Matthew Heaney wrote:

> Just change the or to an else.

My understanding of else is that it won't do what I want --
it won't wait for a rendezvous on my_rendezvous to occur,
it'll just exit immediately if one isn't queued up.  I
ended up coding it the way David Hoos suggested, and it
does what I want.  Thanks for replying.

Larry Coon
University of California
larry@fs2.assist.uci.edu
and lmcoon@home.com

Re: Task question

[Robert A Duff]

In article <3439D647.7C43@home.com>, Larry Coon  <lmcoon@home.com> wrote:
>If I do:
>
>   or
>      terminate;
>
>in place of the exit then it knows when the "calling"
>task is done and will terminate the task, but this isn't
>what I want -- the "other stuff" never gets executed.

When a terminate alternative is selected, the task will finalize all its
local variables before actually becoming terminated.  So you can put the
"other stuff" in a Finalize procedure, and have it executed that way.
If the "other stuff" needs access to local data inside the task, you can
put that data inside the Limited_Controlled object, or you can get at it
via an access discriminant.

>I've also tried adding another accept as a signal for
>when the "calling" task is done:
>
>task body x is
>begin
>   loop
>      select
>         accept my_rendezvous (some_data: some_data_type) do
>            -- Rendezvous stuff
>         end my_rendezvous;
>      or
>         accept done do
>            exit;
>         end done;

If you willing to have the extra entry, then do this:
          accept done;
          exit;
So the exit statement comes *after* the accept statement, not inside
it.

>      end select;
>   end loop;
>   -- Now do more stuff.
>end x;

- Bob

Re: Task question

[Larry Coon]

Robert A Duff wrote:

[your reply rearranged slightly]

> If you willing to have the extra entry, then do this:
>           accept done;
>           exit;
> So the exit statement comes *after* the accept statement, not inside
> it.

Yes, I figured it out myself using a flag, but switched
to this solution when others suggested it....
 
> When a terminate alternative is selected, the task will finalize all its
> local variables before actually becoming terminated.  So you can put the
> "other stuff" in a Finalize procedure, and have it executed that way.
> If the "other stuff" needs access to local data inside the task, you can
> put that data inside the Limited_Controlled object, or you can get at it
> via an access discriminant.
 
...but since this is a learning experience for me (I've
never worked with tasks before), I'll be sure to check
out these suggestions -- thanks.

Larry Coon
University of California
larry@assist.org  <= Note new address
and lmcoon@home.com

Re: Task question

[Balmacara9]

>Subject: Task question
>From: Larry Coon <lmcoon@home.com>
>Date: Tue, Oct 7, 1997 02:27 EDT
>Message-id: <3439D647.7C43@home.com>
>
>I'm having a problem getting a task body to work
>the way I want it to.  Here's a contrived example
>showing (with illegal syntax) what I want to do:
>
>task body x is
>begin
>   loop
>      select
>         accept my_rendezvous (some_data: some_data_type) do
>            -- Rendezvous stuff
>         end my_rendezvous;
>      or
>         exit;  -- This is illegal
>      end select;
>   end loop;
>   -- Now do more stuff.
>end x;
>
>The idea is that this task serves as a collector.
>Another task continually initiates rendezvous (what
>is plural for rendezvous?), with this task, and this
>tasks collects the information that is sent.  When the
>"calling" task is done it terminates.  Since the select
>statement is smart, it knows it can't be called any
>more and invokes the exit, which terminates the loop
>so the rest of the task body executes, and it does
>more stuff.  That's how I want it to work, anyway.
>
>If I do:
>
>   or
>      terminate;
>
>in place of the exit then it knows when the "calling"
>task is done and will terminate the task, but this isn't
>what I want -- the "other stuff" never gets executed.
>
>I've also tried adding another accept as a signal for
>when the "calling" task is done:
>
>task body x is
>begin
>   loop
>      select
>         accept my_rendezvous (some_data: some_data_type) do
>            -- Rendezvous stuff
>         end my_rendezvous;
>      or
>         accept done do
>            exit;
>         end done;
>      end select;
>   end loop;
>   -- Now do more stuff.
>end x;
>
>Now the "calling" task keeps initiating a my_rendezvous,
>but when it's finished it inititates a done to let this
>task know it can proceed.  This doesn't work either -- it
>doesn't let an exit transfer control out of the accept
>statement.
>
>Am I missing an obvious way to do what I want?
>
>Larry Coon
>University of California
>larry@fs2.assist.uci.edu
>and lmcoom@home.com
>
>
>
>
>
>
>

Just change your task like so....


task body x is
begin
   loop
      select
         accept my_rendezvous (some_data: some_data_type) do
            -- Rendezvous stuff
         end my_rendezvous;
      or
         accept done;
            exit;
      end select;
   end loop;
   -- Now do more stuff.
end x;

You do not have to do all your work during the rendezvous, you can use the
 rendevous for pure synchronization and then perform the work after the
 rendezvous.

Between the "do" and "end" of a rendezvous, the calling task is blocked so you
 must release the calling task before exiting the loop.

Task question

[shaunpatterson]

Hey,

   What is the best / proper way to spawn a new task so that a
function call can
continue in the background.. like so:

procedure Test is
  begin

          -- Call a callback function that may take a long time
          FuncPtr.all


          -- Continue other processing here

  end Test;


Is there any way to encapsulate the callback function call in another
task WITHOUT making
the function -- the function called by funcptr.all -- a new task?

Thanks

--
Shaun

Re: Task question

[gpriv]

On Dec 10, 5:12 pm, shaunpatter...@gmail.com wrote:
> Hey,
>
>    What is the best / proper way to spawn a new task so that a
> function call can
> continue in the background.. like so:
>
> procedure Test is
>   begin
>
>           -- Call a callback function that may take a long time
>           FuncPtr.all
>
>           -- Continue other processing here
>
>   end Test;
>
> Is there any way to encapsulate the callback function call in another
> task WITHOUT making
> the function -- the function called by funcptr.all -- a new task?
>
> Thanks
>
> --
> Shaun

procedure test is



procedure Test is

   task Labor;
   task body Labor is
   begin
      select
         delay 10.0;    -- Give a timeout for your function to do the
job
      then abort
         FuncPtr.all;
      end select;
   end Labor;

begin
   null;
end Test;

Re: Task question

[shaunpatterson]

Does the function STOP working after 10 seconds or does it delay and
let other tasks process?

Re: Task question

[gpriv]

On Dec 10, 5:51 pm, shaunpatter...@gmail.com wrote:
> Does the function STOP working after 10 seconds or does it delay and
> let other tasks process?

It is going to be Killed (aborted) after 10 seconds unless funcPtr
will finish running before that.  I gave delay 10.0 as an example, you
can wait on any event there, including user provided semaphore.   Ada
tasking model is extremely flexible: all depends what you want it to
do for you.

George

Re: Task question

[Robert A Duff]

shaunpatterson@gmail.com writes:

> procedure Test is
>   begin
>
>           -- Call a callback function that may take a long time
>           FuncPtr.all
>
>
>           -- Continue other processing here
>
>   end Test;
>
>
> Is there any way to encapsulate the callback function call in another
> task WITHOUT making
> the function -- the function called by funcptr.all -- a new task?

The task can call the function (or more likely, procedure).

Here's one way:

    task type Call_Procedure (Action : not null access procedure);

(Or use whatever profile you want.)
    
    task body Call_Procedure is
    begin
        Action.all;
    end Call_Procedure;

Do you want Test to return while the procedure is still going?
If no, declare a local object of type Call_Procedure in Test
-- then Test will wait for the task to terminate before
returning.  If yes, declare an access-to-Call_Procedure
type outside Test, and allocate an object inside Test using "new".

- Bob

Re: Task question

[anon]

--
-- f_p.adb
--
with Ada.Text_IO ;

procedure F_P is

  task type Function_Task is
    entry Function_1 ( X : in Boolean ) ;
    entry Result_1 ( X : out Boolean ) ;
  end function_Task ;

  --
  -- This task uses two calls. One activate the function
  -- and the second returns the function value once valid.
  --
  -- Note: Delays are use to simulate the actual algorithm for 
  -- the function. Normally there are not needed.
  --
  task body Function_Task is

      W : Boolean ; -- Hold paramter and result value

    begin -- Function_Task
      -- Initial or setup functions
      loop
        select
          --
          -- Start execution of function
          --
          accept Function_1 ( X : in Boolean ) do
            W := X ;
          end Function_1 ;
          --
          -- Routine for function. It could be a function call
          -- Or code here
          --
          Delay 1.0 ; -- simulate a complex algorithm
          W := not W ;
        or
          --
          -- Retrieve function's result if needed wait until 
          -- result is valid
          --
          accept Result_1 ( X : out Boolean ) do
            X := W ; -- Retrive result.
          end Result_1 ;
        or
          --
          -- Allows the task to end, if the program exist
          --
          terminate ; 
        end select ;
      end loop ;
      -- shutdown function
  end function_Task ;

  procedure put ( V : boolean ) is
    begin
      if V then
        Ada.Text_IO.put ( Item => "True" ) ;
      else
        Ada.Text_IO.put ( Item => "False" ) ;
      end if ;              
    end ;

  Functions : function_Task ;
  Z : Boolean := True ;

begin -- F_P 

  Ada.Text_IO.put_line ( Item => "Excute Function 1" ) ;
  Functions.Function_1 ( Z ) ;  
  Put ( Z ) ;
  Ada.Text_IO.new_line ;

  Ada.Text_IO.put_line ( Item => "Excute Something Else" ) ;

  --
  -- Now we need the result from Function 1. So we may 
  -- need to wait until result of function is valid.
  --
  Ada.Text_IO.put_line ( Item => "Get Result for function 1" ) ;
  Functions.Result_1 ( Z ) ;  
  Put ( Z ) ;
  Ada.Text_IO.new_line ;

  Ada.Text_IO.put_line ( Item => "Exit Program" ) ;
  
end F_P ;

In <31235206-1025-467c-8444-07a8eacc9b48@e6g2000prf.googlegroups.com>, shaunpatterson@gmail.com writes:
>Hey,
>
>   What is the best / proper way to spawn a new task so that a
>function call can
>continue in the background.. like so:
>
>procedure Test is
>  begin
>
>          -- Call a callback function that may take a long time
>          FuncPtr.all
>
>
>          -- Continue other processing here
>
>  end Test;
>
>
>Is there any way to encapsulate the callback function call in another
>task WITHOUT making
>the function -- the function called by funcptr.all -- a new task?
>
>Thanks
>
>--
>Shaun

Task question...

[Paul Van Gorp]

Hi, I have this strange problem when using tasking in Ada95

compiler: GNAT 3.10p1
OS: micro$oft w95.

Im looking for a way to accomplish the following (im sure there exists a
simple soln!)

task type t1 is
	entry reply;
	...
end t1;

task type t2 is
	...
end t2;

task body t1 is
	T: t2;
begin
	loop
		select
			accept reply;
			T.do_something;
			...
		or
			...
			T.do_something_else;
			...
		end select;
	end loop;
end t1;

task body t2 is
begin
	loop
		select
			...
			-- what I want here, is to invoke t1.reply
			-- from within different instances of T1
			-- if you know what I mean
		end select;
	end loop;
end t2;

so, if I went something like...

taska, taskb: t1;

each taska and taskb would have its own instance of T, which they
could rendezvous with easily enough with T.whatever, but how could that
task T rendezvous with the task that called it ?

Thanks in advance..

Paul

	...

Re: Task question...

[elaine.waybright]

On Thu, 16 Oct 1997 12:50:34 +1000, Paul Van Gorp
<paulvg@eelab.su.oz.au> wrote:

>Hi, I have this strange problem when using tasking in Ada95
>
>compiler: GNAT 3.10p1
>OS: micro$oft w95.
>
>Im looking for a way to accomplish the following (im sure there exists a
>simple soln!)
>
>task type t1 is
>	entry reply;
>	...
>end t1;
>
>task type t2 is
>	...
>end t2;
>
>task body t1 is
>	T: t2;
>begin
>	loop
>		select
>			accept reply;
>			T.do_something;
>			...
>		or
>			...
>			T.do_something_else;
>			...
>		end select;
>	end loop;
>end t1;
>
>task body t2 is
>begin
>	loop
>		select
>			...
>			-- what I want here, is to invoke t1.reply
>			-- from within different instances of T1
>			-- if you know what I mean
>		end select;
>	end loop;
>end t2;
>
>so, if I went something like...
>
>taska, taskb: t1;
>
>each taska and taskb would have its own instance of T, which they
>could rendezvous with easily enough with T.whatever, but how could that
>task T rendezvous with the task that called it ?
>
>Thanks in advance..
>
>Paul
>
>	...
Perhaps you can turn things around and let t1 call an entry in t2
rather than t2 calling the reply entry of t1?

What exactly is the purpose of this? It sounds potentially
over-complicated.

Bo Sanden
Prof. Bo Sanden
Colorado Technical University 
4435 N. Chestnut Street
Colorado Springs, CO 80907-3896
Email: bsanden@acm.org
Http://www.isse.gmu.edu/faculty/bsanden

Re: Task question...

[Matthew Heaney]

In article <344a5b0e.102700339@news.pcisys.net>,
elaine.waybright@pcisys.net wrote:

>On Thu, 16 Oct 1997 12:50:34 +1000, Paul Van Gorp
><paulvg@eelab.su.oz.au> wrote:
>
>>Hi, I have this strange problem when using tasking in Ada95
>>
>>compiler: GNAT 3.10p1
>>OS: micro$oft w95.
>>
>>Im looking for a way to accomplish the following (im sure there exists a
>>simple soln!)
>>
>>task type t1 is
>>       entry reply;
>>       ...
>>end t1;
>>
>>task type t2 is
>>       ...
>>end t2;
>>
>>task body t1 is
>>       T: t2;
>>begin

>>each taska and taskb would have its own instance of T, which they
>>could rendezvous with easily enough with T.whatever, but how could that
>>task T rendezvous with the task that called it ?


Declare task T2 inside the declarative region of T1:

task body T1 is

   task T2 is
      entry E2;
   end;

   task body T2 is
   begin
       ...
   end;

begin

  T2.E2;

...
end;

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Task question...

[Robert A Duff]

In article <344580FA.478A@eelab.su.oz.au>,
Paul Van Gorp  <paulvg@eelab.su.oz.au> wrote:
>task type t1 is
>       entry reply;
>       ...
>end t1;
>
>task type t2 is
>       ...
>end t2;
>
>task body t1 is
>       T: t2;
>begin
>       loop
>               select
>                       accept reply;
>                       T.do_something;
>                       ...
>               or
>                       ...
>                       T.do_something_else;
>                       ...
>               end select;
>       end loop;
>end t1;
>
>task body t2 is
>begin
>       loop
>               select
>                       ...
>                       -- what I want here, is to invoke t1.reply
>                       -- from within different instances of T1
>                       -- if you know what I mean
>               end select;
>       end loop;
>end t2;

You can put t2 inside t1, like this:

task type t1 is
        entry reply;
        ...
end t1;

task body t1 is

        task t2 is -- Not "task type t2 is..."
                ...
        end t2;

        task body t2 is
        begin
                loop
                        select
                                reply; -- Or, if you prefer, "T1.reply;"
                        ...
                        end select;
                end loop;
        end t2;

begin
        loop
                select
                        accept reply;
                        T2.do_something;
                        ...
                or
                        ...
                        T2.do_something_else;
                        ...
                end select;
        end loop;
end t1;

Alternatively, you could use an access discriminant on T2 pointing to
T1.

- Bob

task question

[Nicolay Belofastow]

Hello,

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

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?

Thanks in advance, Nick.

--
-------------------------------------------------
Nickolay Belofastow
University of the Federal Armed Forces, Munich
e81bnick@rz.unibw-muenchen.de

Re: task question

[Matthew Heaney]

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

Re: Task question

[Matts_Kallioniemi_QZ]

You didn't mention what compiler You use. Task scheduling is implementation
dependent. VAX-Ada for example lets a task run as long it has demand on cpu,
which in Your case is forever for each task. The thing is to use
PRAGMA TIME_SLICE(0.01);
to force a rescheduling after every 0.01 seconds. This will naturally increase
the overhead when running the program.

Have a Nice Day!
---------------------------------------------------------------------------
BITNET:                 MATTS@SEARN.BITNET      (mail)
                        MATTS@SEQZ51.BITNET     (files, vax/vms-jnet)
MAILNET:                Matts_Kallioniemi_QZ@QZCOM.MAILNET
ARPA/CSNET:             Matts_Kallioniemi_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
JANET:                  Matts_Kallioniemi_QZ%QZCOM@UK.AC.YORK.KL
EAN:                    matts@QZ.sunet
PSI/VAX-Mail:           240200101915::MATTS
G3 fax:                 Nat: 08-675559  Int: +46 8 675559
Telephone:              Nat: 08-654550  Int: +46 8 654550
Telex:                  SWE/10366 FOAS
Reality-Mail:           QZ, Stockholm University Computing Center
                        Box 27322, Linnegatan 89
                        S-102 54  STOCKHOLM, Sweden
ICBM:                   N5920 E01806
---------------------------------------------------------------------------