Ada Tasking problem

Ada Tasking problem

[Eric E. Mays 52202]

Info-Ada Folks,

   I am currently taking a computer aided Ada course developed by 
keesler afb.  The last topic in this course involves tasking.  I am
trying to solve the following problem using tasking with entry point.

   The output i'm trying to display is the following:

           1          5
           2          4
           3          3
           4          2
           5          1

    I'm assuming these are to be printed concurrently.  The results i'm
displaying are:   

                      5
                      4
                      3
                      2
                      1
           1
           2
           3
           4
           5

   Here is my code, am I missing something?

with TEXT_IO;

procedure MAIN_TW1 is

   package MY_INT_IO is new TEXT_IO.INTEGER_IO (INTEGER);

   LAST_NUMBER : INTEGER;

   task REV_NUM_OUT is
      entry RECEIVE_NUM (MAX_NUMBER : in INTEGER);
   end REV_NUM_OUT;

   task body REV_NUM_OUT is

      MAX_NUM : INTEGER;

   begin

      accept RECEIVE_NUM (MAX_NUMBER : in INTEGER) do

         MAX_NUM := MAX_NUMBER;

         for I in reverse 1 .. MAX_NUM loop

             TEXT_IO.SET_COL (35);
             MY_INT_IO.PUT (I,WIDTH=>1); 
             text_io.new_line;

         end loop;

      end RECEIVE_NUM;

   end REV_NUM_OUT;


begin

   TEXT_IO.PUT ("Enter an integer number: ");
   MY_INT_IO.GET (LAST_NUMBER);
   TEXT_IO.NEW_PAGE;

   REV_NUM_OUT.RECEIVE_NUM (LAST_NUMBER);

   for J in 1 .. LAST_NUMBER loop

      TEXT_IO.SET_COL (1);
      MY_INT_IO.PUT (J);

   end loop;

end MAIN_TW1; 

   Any helpful hints or comments would be appreciated.

Thanks,

Eric Mays
maysee@m11.sews.wpafb.af.mil

Re: Ada Tasking problem

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!usen]

In article <9111211304.AA10751@m11.sews.wpafb.af.mil> maysee@M11.SEWS.WPAFB.AF.
MIL (Eric E. Mays 52202) writes:
>Info-Ada Folks,
>
>   I am currently taking a computer aided Ada course developed by 
>keesler afb.  The last topic in this course involves tasking.  I am
>trying to solve the following problem using tasking with entry point.
>
>   The output i'm trying to display is the following:
>
>           1          5
>           2          4
>           3          3
>           4          2
>           5          1
>
  [stuff deleted]
>   Here is my code, am I missing something?
>
>with TEXT_IO;
>
>procedure MAIN_TW1 is
>
>   package MY_INT_IO is new TEXT_IO.INTEGER_IO (INTEGER);
>
>   LAST_NUMBER : INTEGER;
>
>   task REV_NUM_OUT is
>      entry RECEIVE_NUM (MAX_NUMBER : in INTEGER);
>   end REV_NUM_OUT;
>
>   task body REV_NUM_OUT is
>
>      MAX_NUM : INTEGER;
>
>   begin
>
>      accept RECEIVE_NUM (MAX_NUMBER : in INTEGER) do
>
>         MAX_NUM := MAX_NUMBER;
>
>         for I in reverse 1 .. MAX_NUM loop
>
>             TEXT_IO.SET_COL (35);
>             MY_INT_IO.PUT (I,WIDTH=>1); 
>             text_io.new_line;
>
>         end loop;
>
>      end RECEIVE_NUM;
>
>   end REV_NUM_OUT;
>
>
>begin
>
>   TEXT_IO.PUT ("Enter an integer number: ");
>   MY_INT_IO.GET (LAST_NUMBER);
>   TEXT_IO.NEW_PAGE;
>
>   REV_NUM_OUT.RECEIVE_NUM (LAST_NUMBER);
>
>   for J in 1 .. LAST_NUMBER loop
>
>      TEXT_IO.SET_COL (1);
>      MY_INT_IO.PUT (J);
>
>   end loop;
>
>end MAIN_TW1; 
>
>   Any helpful hints or comments would be appreciated.
>
Aha! This is nearly an FAQ, that could be phrased "how does the Ada
runtime decide when to switch among tasks?"

Nothing in the LRM requires time-slicing, though of course many
compilers implement it (sometimes making it optional via a pragma 
or whatever). It is quite legal to schedule tasks of equal
priority (which yours are - MAIN is treated as a task) in
"run-till-blocked" fashion, meaning that the first task to
get control keeps it until it gives it up voluntarily.

Once your main program called the task's entry, causing the
task to get control, it simply kept it, finished its loop,
then gave the CPU back to MAIN. The standard Ada recommendation
to prevent this from happening is to put a brief DELAY in each loop
iteration, forcing (in your case) MAIN and the task to ping-pong 
control. You need to add, say, DELAY 0.1 just before both END LOOP
statements.

This is a portable solution: it forces the processor
to be shared even in the absence of time-slicing.

Mike

-------------------------------------------------------------------------------
Michael B. Feldman                       Co-chair, SIGAda Education Committee

Visiting Professor 1991-92               Professor
Dept. of Comp. Sci. and Engrg.           Dept. of Elect. Engrg. and Comp. Sci.
University of Washington FR-35           The George Washington University
Seattle, WA 98105                        Washington, DC 20052

mfeldman@cs.washington.edu               mfeldman@seas.gwu.edu
(206) 632-3794 (voice)                   (202) 994-5253 (voice)
(206) 543-2969 (fax)                     (202) 994-5296 (fax)
-------------------------------------------------------------------------------

Re: Ada Tasking problem

[Bob Kitzberger]

mfeldman@milton.u.washington.edu (Michael Feldman) writes:

>Once your main program called the task's entry, causing the
>task to get control, it simply kept it, finished its loop,
>then gave the CPU back to MAIN. The standard Ada recommendation
>to prevent this from happening is to put a brief DELAY in each loop
>iteration, forcing (in your case) MAIN and the task to ping-pong 
>control. You need to add, say, DELAY 0.1 just before both END LOOP
>statements.
>>
>This is a portable solution: it forces the processor
>to be shared even in the absence of time-slicing.

Many Ada runtimes will 'special case' a delay of 0.0, resulting in an
immediate context switch to another task of equal priority (i.e. round-robin
to the next available task in the same priority slot in the ready queue.)
Of course, this is not very portable, but it doesn't have the overhead of
delay queue insertion and expiry.  Your tradeoff mileage may vary ;-)

	.Bob.

Re: Ada Tasking problem

[cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!uwm.edu!ogicse!milton]

In article <25883@sdcc6.ucsd.edu> cs171wag@sdcc5.ucsd.edu (Bob Kitzberger) writ
es:
>mfeldman@milton.u.washington.edu (Michael Feldman) writes:
>
>>Once your main program called the task's entry, causing the
>>task to get control, it simply kept it, finished its loop,
>>then gave the CPU back to MAIN. The standard Ada recommendation
>>to prevent this from happening is to put a brief DELAY in each loop
>>iteration, forcing (in your case) MAIN and the task to ping-pong 
>>control. You need to add, say, DELAY 0.1 just before both END LOOP
>>statements.
>>>
>>This is a portable solution: it forces the processor
>>to be shared even in the absence of time-slicing.
>
>Many Ada runtimes will 'special case' a delay of 0.0, resulting in an
>immediate context switch to another task of equal priority (i.e. round-robin
>to the next available task in the same priority slot in the ready queue.)
>Of course, this is not very portable, but it doesn't have the overhead of
>delay queue insertion and expiry.  Your tradeoff mileage may vary ;-)
>
You bet it's not portable. There are (or were, at least) runtimes that
optimized away DELAY 0.0 altogether, "no-op"-ed it, so there'd be no
context switch at all. That would, of course, defeat the purpose.
Are there any runtimes that still do that? That's where the "small delay" 
rather than "zero delay" originated, if my recollection of history is correct.

Tell the truth, Bob - just how much overhead is involved in the short
delay described above (on a typical processor)? Is this a micro-efficiency
concern that's big enough to trade for non-portable behavior?

I'd feel more comfortable if there were an AI (Ada Interpretation)
that _recommended_ the optimization you describe. Or if it were widely-
enough adopted by implementers to be "quasi"-portable. Is this the case?

Mike

Re: Ada Tasking problem

[agate!spool.mu.edu!wupost!zaphod.mps.ohio-state.edu!ub!dsinc!gvlf3.gvl.un]

Humble suggestion:

  Why not treat your output console as a shared device and write a
  standard interface to the device?  Write a package specification
  that provides all the operations you require (locking the device,
  time sharing, type and format of output, whatever).  Hide the exact 
  method of implementation of output and locking of the device in 
  the body of a package.  The body of the package will probably require
  another task be added.

  I have found that it can be unwise to let tasks use an output device
  in an uncontrolled/unsynchronized manner.  Putting the control of 
  the synchronization in a single package keeps the code in the package
  instead of every task that might want to access a device (text_IO
  console).  The body may have to be implemented in a target dependant 
  manner but the other code remains more or less portable.

Robert Parkhill

Re: Ada Tasking problem

[paul goffin]

In article <1991Nov23.000353.1643@milton.u.washington.edu>, mfeldman@milton.u.w
ashington.edu (Michael Feldman) writes:
> In article <9111211304.AA10751@m11.sews.wpafb.af.mil> maysee@M11.SEWS.WPAFB.A
F.MIL (Eric E. Mays 52202) writes:
> >Info-Ada Folks,
> >
> >   I am currently taking a computer aided Ada course developed by 
> >keesler afb.  The last topic in this course involves tasking.  I am
> >trying to solve the following problem using tasking with entry point.
> >
> >   The output i'm trying to display is the following:
> >
> >           1          5
> >           2          4
> >           3          3
> >           4          2
> >           5          1
> >
[code deleted]

Mike> Aha! This is nearly an FAQ, that could be phrased "how does the Ada
Mike> runtime decide when to switch among tasks?"
Mike> 
Mike> Nothing in the LRM requires time-slicing, though of course many
Mike> compilers implement it (sometimes making it optional via a pragma 
Mike> or whatever). It is quite legal to schedule tasks of equal
Mike> priority (which yours are - MAIN is treated as a task) in
Mike> "run-till-blocked" fashion, meaning that the first task to
Mike> get control keeps it until it gives it up voluntarily.
Mike> 
Mike> Once your main program called the task's entry, causing the
Mike> task to get control, it simply kept it, finished its loop,
Mike> then gave the CPU back to MAIN. The standard Ada recommendation
Mike> to prevent this from happening is to put a brief DELAY in each loop
Mike> iteration, forcing (in your case) MAIN and the task to ping-pong 
Mike> control. You need to add, say, DELAY 0.1 just before both END LOOP
Mike> statements.
Mike> 
Mike> This is a portable solution: it forces the processor
Mike> to be shared even in the absence of time-slicing.

Yes, I agree, but perhaps the delay should be

	delay DURATION'SMALL;  -- smallest time slice possible

or 

	delay 0.0;             -- (I think) forces a scheduling event


Actualy, the origional question reveals a possible misunderstanding
of multi-task systems in general.  Even if the Ada run time system
does support time-slicing, there is still no guarantee of the origional
desired output.  The time slices may be long enough for each task to
run to conclusion.  (In fact, with the small tasks in the question, it
would be a very inefficient processor/compiler combination indeed which
would not complete each task in, say, 10ms.)

The only way to guarantee the required output is for the tasks to
rendezvous and 'agree' the output.  - Preferably with a third task
which manages the output only.

i.e. Task1 - counts up 
     Task2 - counts down
     Task3 - receives data from 1 and 2 and prints it in the required
             format.

Task3 acts as a server (or spooler).
The various rendezvous required would force the context switches, and
so the DELAY's would no longer be necessary.

The use of server (or spooler or 'resource manager') tasks is quite
important in avoiding both deadlock and garbeled output when
multi-tasking.

Of course, you could just forget multi-tasking and use a single thread.

Paul.

-- 
+-------------+------------------------------------------------------+
+ Paul Goffin +  Crosfield Electronics Ltd.                          +
+             +  U.K.   +44 442 230000    -  My opinions are my OWN. +
+-------------+------------------------------------------------------+