Ada Tasks vs Linux processes

Ada Tasks vs Linux processes

[Frank]

Hi!

I have made a package with a task type, I instanciate this task "as a
variable" in a test program.
It compiles ok.

When I perform "ps -ef" while this program runs, I find three processes
named "mytest".

I have preconceived idea :-) that I should have only two processes. Have I
done something in my code that causes this behaviour, or is this the way it
is?


I'm using the "select ..or ..or delay n" statement below, and I have choosen
to use "delay 0.0" to make the process continue with the business logic
below without any waiting for any rendezvous. Does delay 0.0 have a
predefined behaviour?


Source code supplied below
Frank

-----------
package PA_TEST is

  task type TTSK_TEST is
    entry INIT;
    entry DO_STUFF;
    entry DIE;
  end;

end PA_TEST;
---------
with TEXT_IO;
package body PA_TEST is

  task body TTSK_TEST
  is
    RUNNING : BOOLEAN := FALSE;
  begin

    accept INIT do
      TEXT_IO.PUT_LINE ("TTSK_TEST.INIT");
      RUNNING := TRUE;
    end INIT;

    while RUNNING  loop
      select
        accept DO_STUFF do
          TEXT_IO.PUT_LINE ("TTSK_TEST.DO_STUFF");
        end DO_STUFF;

      or
        accept DIE do
          TEXT_IO.PUT_LINE("TTSK_TEST.DIE");
          RUNNING := FALSE;
        end DIE;

      or
        delay 0.0; -- In order to "fall through" select statement.

      end select;

--   Business logic
--   ----"--------
--   ----"--------

    end loop;

    TEXT_IO.PUT_LINE("PA_TEST(Terminates)");
  end;
begin
  TEXT_IO.PUT_LINE("PA_TEST(MAIN)");
end PA_TEST;
---------
with PA_TEST, TEXT_IO;
procedure MYTEST is
  A_TASK : PA_TEST.TTSK_TEST;
  WAIT : STRING(1..1);
begin
  TEXT_IO.PUT_LINE("TEST");

  A_TASK.INIT;

  TEXT_IO.PUT_LINE ("Enter a character and press ENTER, please");
  TEXT_IO.GET(WAIT);

  A_TASK.DIE;

end MYTEST;
-------

Re: Ada Tasks vs Linux processes

[David C. Hoos, Sr.]

The behavior is as expected.  The three processes you see are the manager
thread, the initial thread (i.e.,  the main program), and your task object.

You will note that the PGIDs for all three processes are identical -- i.e.,
they
are all members of the same shared process group -- in other words, the
additional processes are so-called "lightweight" processes, sharing by and
large, all of the resources of the parent process.

By being distinct OS processes, the scheduling of the tasks is done by
the OS instead of the Ada runtime, and one task (process) can block
(e.g., waiting for IO) without blocking the others.

As far as delay 0.0 is concerned, it should yield the CPU to another
task, if there's one ready to run.  Generally, though, I use
delay Duration'Small instead of delay 0.0;


"Frank" <franjoe@frisurf.no> wrote in message
news:2OHx6.4154$NR.335287@news3.oke.nextra.no...
> Hi!
>
> I have made a package with a task type, I instanciate this task "as a
> variable" in a test program.
> It compiles ok.
>
> When I perform "ps -ef" while this program runs, I find three processes
> named "mytest".
>
> I have preconceived idea :-) that I should have only two processes. Have I
> done something in my code that causes this behaviour, or is this the way
it
> is?
>
>
> I'm using the "select ..or ..or delay n" statement below, and I have
choosen
> to use "delay 0.0" to make the process continue with the business logic
> below without any waiting for any rendezvous. Does delay 0.0 have a
> predefined behaviour?
>
>
> Source code supplied below
> Frank
>
> -----------
> package PA_TEST is
>
>   task type TTSK_TEST is
>     entry INIT;
>     entry DO_STUFF;
>     entry DIE;
>   end;
>
> end PA_TEST;
> ---------
> with TEXT_IO;
> package body PA_TEST is
>
>   task body TTSK_TEST
>   is
>     RUNNING : BOOLEAN := FALSE;
>   begin
>
>     accept INIT do
>       TEXT_IO.PUT_LINE ("TTSK_TEST.INIT");
>       RUNNING := TRUE;
>     end INIT;
>
>     while RUNNING  loop
>       select
>         accept DO_STUFF do
>           TEXT_IO.PUT_LINE ("TTSK_TEST.DO_STUFF");
>         end DO_STUFF;
>
>       or
>         accept DIE do
>           TEXT_IO.PUT_LINE("TTSK_TEST.DIE");
>           RUNNING := FALSE;
>         end DIE;
>
>       or
>         delay 0.0; -- In order to "fall through" select statement.
>
>       end select;
>
> --   Business logic
> --   ----"--------
> --   ----"--------
>
>     end loop;
>
>     TEXT_IO.PUT_LINE("PA_TEST(Terminates)");
>   end;
> begin
>   TEXT_IO.PUT_LINE("PA_TEST(MAIN)");
> end PA_TEST;
> ---------
> with PA_TEST, TEXT_IO;
> procedure MYTEST is
>   A_TASK : PA_TEST.TTSK_TEST;
>   WAIT : STRING(1..1);
> begin
>   TEXT_IO.PUT_LINE("TEST");
>
>   A_TASK.INIT;
>
>   TEXT_IO.PUT_LINE ("Enter a character and press ENTER, please");
>   TEXT_IO.GET(WAIT);
>
>   A_TASK.DIE;
>
> end MYTEST;
> -------
>
>
>

Re: Ada Tasks vs Linux processes

[tmoran]

>As far as delay 0.0 is concerned, it should yield the CPU to another
>task, if there's one ready to run.  Generally, though, I use
>delay Duration'Small instead of delay 0.0;
  LRM D.9(7) says the implementation must document the minimum delay
value that actually causes the task to block, while D.9(5) says a
delay of zero does not block, but is only "potentially blocking".
Even among compilers that don't implement Annex D, delay 0.0 usually
does not unnecessarily block, while any positive delay usually blocks
for two clock ticks, which on some systems can be a surprisingly long
time.

Re: Ada Tasks vs Linux processes

[Robert A Duff]

tmoran@acm.org writes:

>   LRM D.9(7) says the implementation must document the minimum delay
> value that actually causes the task to block, while D.9(5) says a
> delay of zero does not block, but is only "potentially blocking".
> Even among compilers that don't implement Annex D, delay 0.0 usually
> does not unnecessarily block, while any positive delay usually blocks
> for two clock ticks, which on some systems can be a surprisingly long
> time.

Right, but "delay 0.0;" will cause the task to go to the end of its
ready queue, so if there's any other task of the same priority waiting
to run, it will run.  So "delay 0.0;" does what some systems call
"yield".  (Assuming Annex D.)

- Bob

Re: Ada Tasks vs Linux processes

[Ehud Lamm]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 529 bytes --]


> Right, but "delay 0.0;" will cause the task to go to the end of its
> ready queue, so if there's any other task of the same priority waiting
> to run, it will run.  So "delay 0.0;" does what some systems call
> "yield".  (Assuming Annex D.)
>


To quote the LRM:
The execution time of a delay_statement that does not cause the task to be
blocked (e.g. �delay 0.0;� ) is of interest in situations where delays are
used to achieve voluntary round-robin task dispatching among equal-priority
tasks. (D.9 (14))

Ehud Lamm

Re: Ada Tasks vs Linux processes

[Frank]

Hi!

It seems to me (after some more searching in select -statement variations)
that the I should use the construction select...or.._else_ to achieve what I
intended.

But this disussion brings another question to my mind; from some e-threads I
read here I have got the impression that I _have_ to perform delay n; in the
code so that all tasks get a slice of the execution (perhaps this goes for
OS or CPU that does not handle HW multitasking or something?) Is this a
true, or can I assume that Ada (and/or the OS it is running in) slices
executions on every platform it is implemented?
I can understand that a delay n; makes good sense if a task does not have to
execute continously and a delay therefore can give execution slices to other
tasks instead.

Frank

Re: Ada Tasks vs Linux processes

[Jeffrey Carter]

tmoran@acm.org wrote:
> 
> >As far as delay 0.0 is concerned, it should yield the CPU to another
> >task, if there's one ready to run.  Generally, though, I use
> >delay Duration'Small instead of delay 0.0;
>   LRM D.9(7) says the implementation must document the minimum delay
> value that actually causes the task to block, while D.9(5) says a
> delay of zero does not block, but is only "potentially blocking".
> Even among compilers that don't implement Annex D, delay 0.0 usually
> does not unnecessarily block, while any positive delay usually blocks
> for two clock ticks, which on some systems can be a surprisingly long
> time.

Indeed. The Verdix compiler for SCO UNIX responded to "delay
Duration'Small;" by delaying until the next clock tick. Since the clock
ticked at 1 Hz, this corresponded to an average delay of 0.5 seconds. I
saw some very slow code that resulted from the GRACE components using
"delay Duration'Small;" to obtain a unique timestamp.

Jeffrey Carter

Re: Ada Tasks vs Linux processes

[Matthias Kretschmer]

Frank wrote:

> Hi!
>
> It seems to me (after some more searching in select -statement variations)
> that the I should use the construction select...or.._else_ to achieve what I
> intended.
>
> But this disussion brings another question to my mind; from some e-threads I
> read here I have got the impression that I _have_ to perform delay n; in the
> code so that all tasks get a slice of the execution (perhaps this goes for
> OS or CPU that does not handle HW multitasking or something?) Is this a
> true, or can I assume that Ada (and/or the OS it is running in) slices
> executions on every platform it is implemented?
> I can understand that a delay n; makes good sense if a task does not have to
> execute continously and a delay therefore can give execution slices to other
> tasks instead.
>

It is true, that on systems which do not support preemptive multitasking or on
which you ada-compiler doesn't support this, you need delay statements to switch
between threads. (e.g. the gnat on FreeBSD (from ports-collection 4.2-stable)
doesn't support the os-implementation of threads and simulates non-preemptive -
without delay statements on this system with this compiler your active thread
won't change)

>
> Frank

Re: Ada Tasks vs Linux processes

[tmoran]

> ... by delaying until the next clock tick.
 Note this is a change from Ada 83, where the delay had to be "at
least" that specified.  Suppose there's a piece of hardware that
needs 500 mics to settle after some operation, before it can next
be accessed.  Given a Duration'small of 10*mics, the unsuspecting
programmer might write "delay 500*mics;".  With a System.Tick of
1000 mics, that would delay somewhere between 1 and 2 ms, a safe
time for the hardware to settle down, when compiled with Ada 83.
In Ada 95 it need only take a single tick, which might happen
within a few mics of reaching the "delay" statement and thus long
before the hardware is ready.  Crash and burn.

Re: Ada Tasks vs Linux processes

[Gary Scott]

A more fundamental issue would be why would hardware be designed that
did not provide a positive status indication that it was "ready" for
further access.  Using delays to handle interface issues with slow,
poorly designed hardware has caused a huge number of anomalies in
avionic systems that I've dealt with over the last 20 years. It's really
tiring...

tmoran@acm.org wrote:
> 
> > ... by delaying until the next clock tick.
>  Note this is a change from Ada 83, where the delay had to be "at
> least" that specified.  Suppose there's a piece of hardware that
> needs 500 mics to settle after some operation, before it can next
> be accessed.  Given a Duration'small of 10*mics, the unsuspecting
> programmer might write "delay 500*mics;".  With a System.Tick of
> 1000 mics, that would delay somewhere between 1 and 2 ms, a safe
> time for the hardware to settle down, when compiled with Ada 83.
> In Ada 95 it need only take a single tick, which might happen
> within a few mics of reaching the "delay" statement and thus long
> before the hardware is ready.  Crash and burn.

Re: Ada Tasks vs Linux processes

[tmoran]

>A more fundamental issue would be why would hardware be designed that...
  You will have to ask the hardware guys.  I presume the answer has
to do with cheapness.