Tasks in ADA

Tasks in ADA

[bmk Bradley Kuhn]

   Is there a way to find out how a particular implimentation of ADA deals
w/ tasks (i.e. time slicing or genuine multi-tasking).  I have read in ada
manuals that in fact most ADA impimentations do time slicing, but I would 
like to know for certian how our implimentation does it.  We are running
ADA under VAX/VMS.  If anyone has any information I would greatly
appreciate it.  (I would RTFM on VAX/VMS's manual for ADA, but at
Loyola College in MD, the computer manuals are mostly not readily available
to students).  Thanks.

 -- Brad Kuhn  Computer Systems Development, Inc
     INTERNET: rhlab\!bkuhn@uunet.uu.net OR bkuhn@loyola.edu
     BITNET:   bkuhn@loyvax.BITNET
     UUCP:     ...uunet!rhlab!bkuhn

Re: Tasks in ADA

[news.u.washington.edu!milton.u.washington.edu!mfeldman]

In article <463@rhlab.UUCP> bkuhn@rhlab.UUCP (bmk Bradley Kuhn) writes:
>
>   Is there a way to find out how a particular implimentation of ADA deals
>w/ tasks (i.e. time slicing or genuine multi-tasking).  I have read in ada
>manuals that in fact most ADA impimentations do time slicing, but I would 
>like to know for certian how our implimentation does it.  We are running
>ADA under VAX/VMS.  If anyone has any information I would greatly
>appreciate it.  (I would RTFM on VAX/VMS's manual for ADA, but at
>Loyola College in MD, the computer manuals are mostly not readily available
>to students).  Thanks.
>
Another writer may answer you for the specific case of VAX/VMS, but in the
general case, RTFM is really the only way to go. There's no requirement to
report this in a standardized fashion. Sufficient pressure on the lab
manager at Loyola should produce the manual. Get your prof behind you.

Time-slicing is not required, but preemption is required for tasks of
differing priority. That is to say that e.g. if a high-priority task goes
to sleep on a delay statement, giving the CPU to a lower-priority one,
the higher-priority task _must_ preempt the lower one upon expiration
of its delay. This requirement has always existed in theory, but it was
not graven in stone until an official interpretation promulgated in 1986,
and was not enforced by the validation suite until the current version,
1.11, which did not go into effect until 12/1/89.

Janus-Ada's tasking system is conforming by default, as they do not
support priorities. They say they'll do it "right" Real Soon Now.

Mike Feldman

-------------------------------------------------------------------------------
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: Tasks in ADA

[rlk]

> Date: 18 Apr 92 01:31:21 GMT
> From: rhlab!bkuhn@uunet.uu.net  (bmk Bradley Kuhn)
> Subject: Tasks in ADA
> Message-ID: <463@rhlab.UUCP>
> 
>    Is there a way to find out how a particular implimentation of ADA deals
> w/ tasks (i.e. time slicing or genuine multi-tasking).


Of course, RTFM if you can.  But another way of determining it is
like so:

(this should be target-independent, but was compiled with TeleSoft's
RISCAda v1a host system, which does support time slicing)

-----------------------------------
with Text_IO;
with System;

procedure Slice_Test is

  pragma Priority(System.Priority'Last);

  task type Slicer is
    pragma Priority(System.Priority'First);
    entry start;
  end Slicer;

  Num_Tasks : constant := 10;
  type ID is range 1..Num_Tasks;

  type Count is range 0..System.Max_Int;

  Counts : array(ID) of Count := ( others => 0 );
  Slicers : array(ID) of Slicer;

  ID_finger : ID := 0;
  pragma Shared(ID_Finger);

  function Get_ID return ID is
  begin
    ID_Finger := ID_Finger + 1;
    return ID_Finger;
  end Get_ID;

  task body Slicer is
    Me : ID := Get_ID;
  begin
    accept start;
    text_io.put_line("Task " & ID'image(Me) & " up & running");
    loop
      Counts(Me) := Counts(Me) + 1;
    end loop;
  exception
    when others => 
      Text_IO.Put_Line("Exception in slicer " & ID'Image(Me));
  end Slicer;


begin
  for I in ID loop
    Slicers(I).Start;
  end loop;

  text_io.put_line("Main waiting 10 seconds");
  delay 10.0;

  text_io.put_line("Main killing off children");
  for I in ID loop
    abort Slicers(I);
  end loop;
  for I in ID loop
    text_io.put_line("Task " & ID'image(I) & 
		      " count is " & Count'image(Counts(I)));
  end loop;
end Slice_Test;
-----------------------------------


This test creates an array of 10 low-priority tasks, each of which
waits to be started by the main task.  Once started, they each 
enter an endless loop, incrementing a counter.

The main task wakes up after 10 seconds, and reports on the progress
each of the tasks has in incrementing their counter.

If time slicing is not supported, you'll see task 1 hogging all of the 
CPU:

      Main waiting 10 seconds
      Task  1 up & running
      Main killing off children
      Task  1 count is  12460460
      Task  2 count is  0
      Task  3 count is  0
      Task  4 count is  0
      Task  5 count is  0
      Task  6 count is  0
      Task  7 count is  0
      Task  8 count is  0
      Task  9 count is  0
      Task  10 count is  0


If time slicing is supported (and enabled!) then you'll get a more even
sharing of the CPU among the children.

      Main waiting 10 seconds
      Task  1 up & running
      Task  2 up & running
      Task  3 up & running
      Task  4 up & running
      Task  5 up & running
      Task  6 up & running
      Task  7 up & running
      Task  8 up & running
      Task  9 up & running
      Task  10 up & running
      Main killing off children
      Task  1 count is  1195902
      Task  2 count is  1193589
      Task  3 count is  1176106
      Task  4 count is  1200294
      Task  5 count is  1185150
      Task  6 count is  1210111
      Task  7 count is  1207654
      Task  8 count is  1189524
      Task  9 count is  1181912
      Task  10 count is  1230723


Please note that, depending on your runtime, this test may not terminate
after reporting the tenth task's count.  This depends on whether or not
your runtime supports asynchronous aborts.

	.Bob.


p.s. it's "Ada" (not an acronym)

Re: Tasks in Ada

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!l]

What happens if we have Tasks without any entries ?

The tasks are instanstiated when the task body
is elobrated .
If there are more then one tasks I think
the implementation decides which task starts first
and then the tasks are inter-leaved (including the implicit main task).

Is it possible to provide mutual exclusion and synchronization
to these tasks using pragma shared on a integer variable and
using it as a semaphore?
Would it depend on how implementation deals with tasks 
(multi-tasking or time-slicing)?

Jani

Re: Tasks in Ada

[rlk]

> What happens if we have Tasks without any entries ?
> 
> The tasks are instanstiated when the task body
> is elobrated .
> If there are more then one tasks I think
> the implementation decides which task starts first
> and then the tasks are inter-leaved (including the implicit main task).

Well, the startup-up of the tasks isn't quite interleaved. If you start
up a task without entries, and if your implementation does not time-slice, 
then you may end up with a task grabbing all of the CPU, preventing other
tasks from starting up.  Generally, it's a good idea to have 'startup'
entries on each of your tasks, and have a system controller start them
in the proper order, rather than relying on the tasks' elaboration and
startup ordering.

> Is it possible to provide mutual exclusion and synchronization
> to these tasks using pragma shared on a integer variable and
> using it as a semaphore?
> Would it depend on how implementation deals with tasks 
> (multi-tasking or time-slicing)?
> 
> Jani

Perhaps I'm missing something here, but the whole reason that the 
rendezvous was chosen as a synchronization mechanism was to get 
us away from low-level mechanisms such as semaphores, and towards 
more reliable mechanisms.  Why not just use a rendezvous?  You can 
write a semaphore task using rendezvous, but that's kind of like 
using a metal shop to build flint knives.

But if you're being pedantic... the answer is still 'no'.  For example,
How can you suspend a task that fails in its attempt to acquire a
semaphore?  The language provides no primitives to do this, and
attempting to do it on your own requires more knowledge about the
internals of the compilers runtime system (both code generator-wise and
kernel-wise) then is provided by vendors.

Many Ada development systems provide interfaces to real-time kernels
that underly their tasking systems.  Usually, more traditional (read:
non-portable, but sometimes necessary) synchronization primitives  are
provided in these kernels, such as semaphores, message passing, etc.
Personally, I think that these non-portable interfaces should be used
as a last resort, only when a pure tasking solution is either untenable
or too bulky.  The tasking mechanisms built into the language can solve
quite a few problems, in an elegant manner.

	.Bob.