Re: Timers in application (again)

["Robert I. Eachus" <rieachus@earthlink.net>]

Simon Wright wrote:
> 
> "Robert I. Eachus" <rieachus@earthlink.net> writes:
...
> >    Assuming Ada.Real_Time.Time_Span is greater than the time required to
> > execute the loop,
> > and that any higher priority tasks don't eat up too much wall clock
> > time, Action should take place at intervals of one tick, not two.  This
> > is one of the reasons that delay until was added to the language.  (The
> > same idiom can be used with Calendar, but there are a few more
> > required caveats.
> 
> On Linux, this results in delays of 0. Even trying Ada.Real_Time.Tick
> (10 uS) was the same. At some higher value the behaviour changes so
> that you do actually get a delay: I tried
> 
>   Next := Next + Ada.Real_Time.Milliseconds (2);
> 
> for example, but all that happens is that you get one interval of 20
> mS and 9 intervals of 0 ms which of course averages to the 2 mS but
> isn't what we had in mind ..
 
    This is a horrible Unixism that you have to beware of.  Many Unix
systems
(and for that matter some other non-real-time OSs) have a fairly coarse
clock,
but successive calls to the clock are guarenteed to return different
values.  
For example, if the actual clock ticks at every 200 microseconds. the
first of
several successive clock calls will return an even multiple of 200
microseconds,
the next call will return immediately with a value incremented by one
microsecond,
etc.  Only when 200 clock calls have returned will the next clock call
wait for
the "real" clock tick.  Totally useless for real-time scheduling.  So
you both
need to know what the actual clock tick is, and which call gets to a
clock
that doesn't lie.  This is one of the reasons why Ada 95 added the
Ada.Real_Time
package--to provide access to an honest clock.

> I suppose things may be different over an RTOS.

   Depends on your definition of an RTOS.  Sun will tell you that
Solaris is an
RTOS, and if you know how to set it up, you may even get the correct
behavior,
depending on which Solaris version you have.  But from experience, do
not believe
anyone from the OS vendor, no matter how competant they seem.  The
heartstone tests
do a very good job of separating the sheep from the goats.  There are
implementations
out there which will do what you want, but among other things, you have
to read the
documentation carefully.  For example, you can produce a real-time
executable for
Solaris which, if run as root, will produce correct results.  But run it
as a user
process, and you won't get error messages, just incorrrect operation. 
(For example,
setting priority will "succeed" i.e., not raise a signal or return an
error code, but
it will not change the priority...)