From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 26 Nov 91 09:10:43 GMT
From: mcsun!uknet!stl!crosfield!pdg@uunet.uu.net  (paul goffin)
Subject: Re: Ada Tasking problem
Message-ID: <11973@suns3.crosfield.co.uk>
List-Id: <comp.lang.ada>

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. +
+-------------+------------------------------------------------------+