TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Robert I. Eachus" <[log in to unmask]>
Reply To:
Robert I. Eachus
Date:
Wed, 29 Sep 1999 21:32:34 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (20 lines)
At 09:58 PM 9/28/1999 +0200, hlund Magnus wrote:

>Maybe the delay until statement is a part of the solution, but how can I be
>sure that the ACC will deactivate CONSENT directly after those 800 ms ?

   There are two cases.  The first is that you need to deactivate a method of
object ACC.  This is not really a hard-real-time issue at all, you just have to avoid race conditions.

   The other is a misunderstanding that I feel personally responsible for.  I had about three pages of replacement text for the Ada 83 standard during the development process that Jean Ichbiah shortened to about three sentences.  The sentences were correct then, but the the most confusing part of the behavior is a characteristic of any digital implementation, and has nothing to do with Ada.

   Given a digital clock and a requested delay, in this case 800 ms, you can either take a best guess at when the delay expires, or guarentee that the timing bias is in one direction or the other.  Ada basically requires that with say a 1 ms clock and a delay request of 800 ms, the run-time requests a delay of 801 ticks.  (Assuming a very fast implementation and no other issues, waiting for 800 clock ticks will provide a delay between 799 and 800 ms.  The Ada standard requires that the delay always be greater than or equal to 800 ms if that is what you specify.  If the specifications say 800 ms with no error bound, get it fixed.  That is an untestable, and unmeetable requirement.

   The other issue is that if a higher priority task needs some of the same resources so that both cannot run at the same time, the Ada 83 standard required that the lower priority task wait, forever if necessary.  (With Ada 95 it is possible to provide other policies.  However, for hard real-time you almost always want a policy that can starve low priority tasks.)  So in this case, you can either ensure that, if your target has N processors, that there are at most N-1 higher priority tasks, or that you can accept the maximum possible delay.  How to do this type of analysis for real-time systems is a facinating area of study, you'll want to look at the body of literature on hard deadline scheduling methods.

                                        Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

ATOM RSS1 RSS2