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 15:04:38 GMT From: cis.ohio-state.edu!news.sei.cmu.edu!jldh@ucbvax.Berkeley.EDU (Jorge Luis Diaz-Herrera) Subject: Re: Ada delay Message-ID: <1992Sep17.150438.23030@sei.cmu.edu> List-Id: In article <1992Sep17.142643.21378@sei.cmu.edu>, firth@sei.cmu.edu (Robert Firt h) writes: |> In article amichail@plg.uwaterloo.ca (Amir Mi chail) writes: |> |> >How is the Ada delay statement implemented? I suppose it uses a hardware |> >timer coupled with a clock server, but this would mean that the time |> >taken for a delay is unbounded (since we have to search an ordered list |> >of tasks). |> |> Either a list is ordered or you have to search it, but not both, surely, |> else somebody has it in the wrong order. |> ... We implemented (see ref.) simple delays using an ARRAY [1..MaxTasks] of Time. The task name serves as the array index; the array entry is the task release time (release time = current time + delaytime.) The array is searched at every context switch and all tasks whose release time is less than or equal to the current time are inserted in the corresponding ready queue (priority). This is consistent with the LRM which requires delays to be "at least" the duration specified. Linear search is used since the number of delayed tasks will probably be small. In addition to timing through tick counting, using the timer interrupt trapped, a variation was developed using calls to the system clock. This technique while inherently more efficient, can be highly inaccurate since in our RTK time is updated only upon entry to the dispatcher. For more information refer to: "ARTK-M2:A Kernel for Ada Tasking Requirements: an implementation and an Automatic Generator" J.L.Diaz-Herrera et al, Software Practice and Experience, vol. 22(4) 317-348 (April 1992).