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,e52294beeef18a74
X-Google-Attributes: gid103376,public
From: "Samuel T. Harris" <s_harris@hso.link.com>
Subject: Re: GNAT DOS Delay Problems
Date: 1997/09/29
Message-ID: <342FDB25.E86EF7A9@hso.link.com>#1/1
X-Deja-AN: 276473902
References: <01bcca6e$e2e4f3c0$1601030a@lovina.cri.dk>
Organization: Hughes Training Inc. - Houston Operations
Newsgroups: comp.lang.ada
Date: 1997-09-29T00:00:00+00:00
List-Id: <comp.lang.ada>


Gert Caspersen wrote:
> 
> When running the below program, no context switch takes place. Task T1 with
> the low priority is starved by task T2 with the high priority.
> 
> In my opinion, T1 should be scheduled when T2 executes delay 10.0. However,
> this appears never to happen. Rather, the entire program is suspended for
> ten seconds.
> 
> I am using GNAT version 3.07 for DOS.
> 
> Any ideas of the cause would be appreciated....
> 
> with Ada.Text_IO;
> procedure Dims is
> 
>    task T1 is
>       pragma Priority (2);
>    end T1;
> 
>    task T2 is
>       pragma Priority (3);
>    end T2;
> 
>    task body T1 is
>    begin  -- T1
>       loop
>          Ada.Text_IO.Put_Line("Task 1");
>          delay (1.0);
>       end loop;
>    exception
>       when others =>
>          Ada.Text_IO.Put_Line("Task 1 got exception");
>    end T1;
> 
>    task body T2 is
>    begin  -- T2
>       loop
>          Ada.Text_IO.Put_Line("Task 2");
>          delay (10.0);
>       end loop;
>    exception
>       when others =>
>          Ada.Text_IO.Put_Line("Task 2 got exception");
>    end T2;
> 
> begin  -- Dims
>    null;
> end Dims;

I remember using both Janus and Alsys Ada on PC before
they implementing time-slicing. Once a task took over,
it had control until it terminated or initiated a
rendevous. The run-time scheduler NEVER interrupted
the running task and only "scheduled" the next task
when a task terminated or a rendevous occured.

To get around that problem, I used a nil_task with
a single accept which basically did nothing. I then
"spinkled" the actual tasks and the main program with
entry calls to that do_nothing entry. This gave the
scheduler a chance to switch amoung the various tasks
in the system. Placement of these "scheduler" rendevous
was a black art and some playing around was needed to
get the desired behavior.

-- 
Samuel T. Harris, Senior Engineer
Hughes Training, Inc. - Houston Operations
2224 Bay Area Blvd. Houston, TX 77058-2099
"If you can make it, We can fake it!"