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: 25 Nov 91 00:04:26 GMT
From: sdcc6!sdcc5!cs171wag@ucsd.edu  (Bob Kitzberger)
Subject: Re: Ada Tasking problem
Message-ID: <25883@sdcc6.ucsd.edu>
List-Id: <comp.lang.ada>

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.