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: 17 Sep 92 17:45:09 GMT
From: visicom!amstel!rlk@nosc.mil  (Bob Kitzberger)
Subject: Re: Ada delay
Message-ID: <rlk.716751909@amstel>
List-Id: <comp.lang.ada>

firth@sei.cmu.edu (Robert Firth) writes:

>In article <Buq4Mr.D7H@math.uwaterloo.ca> amichail@plg.uwaterloo.ca (Amir Mich
ail) writes:

>For Ada, you need three efficient primitives
>
>. insert in correct place in ordered list
>
>. remove first in list
>
>. remove named task from list (for conditional entry and accept)
>
>Not hard.

The algorithm is easy -- the 'hard' part is implementing the lower-level
grunge  (myriad target boards, with myriad hardware timers [none worth the
silicon they're made of], mapping to type Duration without loss of
accuracy drift, etc., and making it easy to adapt from target to target 
system).  All of these are important when you want to implement
high-resolution periodic scheduling operations like Delay_Until and periodic
soft interrupts, which developers find out are necessary once they butt 
up against the delay statement's limitations.

Give me a 64-bit monotonic timer, incrementing once per CPU cycle, 
atomic CPU instructions to read the clock and set a single 64-bit
wake-up-time, and a cold Watney's and I'd be a happy Ada delay
implementor.  

	.Bob.
----------------
Bob Kitzberger          VisiCom Laboratories, Inc.
rlk@visicom.com         10052 Mesa Ridge Court, San Diego CA 92121 USA
                        +1 619 457 2111    FAX +1 619 457 0888