[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Timed routines

Jake Janovetz wrote:
> We had some discussion of this sometime ago.  I actually like
> the proposed method since this is how most of my TSRs get
> written anyhow.  I write some new task and have it wait for
> evens from a timer task.  The timer task just sends an event
> to the waiting task.
> For some reason, Joel was opposed to the change, I think.  Joel?

Resistance to change I suppose. :)

Now that some time has passed and I don't remember what I said, let's
start again.  You can't completely eliminate the need to run the
chain of subroutines at each clock time.  That mechanism is used
by RTEMS for timeouts, etc.  But this is OK because RTEMS handlers are 
very small.  The TSR support just opened this up to user routines.

The current TSR support is good for small things and when used in
But the other approach is better for more general, higher functionality 

Is it possible to support both?  All (I think) it would take is either
(1) a 
new timer manager routine to create a "task level" TSR or (2) a
to the API of the current timer_create to add an attribute that
task level or clock tick level.

Eric .. rather than a count and events, isn't it more natural to use a
semaphore?  This may lead into putting together the "light semaphore" we
talked about periodically as a side-effect.

>     Cheers,
>     Jake
> On Mon, Oct 04, 1999 at 08:34:55AM -0600, Eric Norum wrote:
> > I'd like to propose a change to the way RTEMS handles timers.
> >
> > Although it's not really mentioned in the documentation (at least not
> > anywhere that I could find), timed routines run in the context of the
> > clock interrupt service routine.  I propose changing this so that timed
> > routines run in the context of a timer task.  The clock interrupt
> > handler (rtems_tick_handler) would then update the time value and send
> > an event to the timer task which would do the callouts to the timed
> > entries.
> >
> > For example, the _Watchdog_Tickle_ticks routine could decrement a
> > `ticks-till-next-timed-entry' counter and send an event to the timer
> > task when the counter reached 0.  The timer task would then reset the
> > `ticks-till-next-timed-entry' counter and perform the required
> > callbacks.
> >
> > There would be two more configuration parameters associated with the new
> > scheme.
> > 1) The priority at which the timer task would run (perhaps 1 or 2 by
> > default)
> > 2) The stack size of the timer task.
> >
> > Good things resulting from the change:
> >         Interrupt latency would be reduced since the processor would
> >         spend less time in the clock interrupt handler.
> >         Timed routines would be able to call on any service, including
> >       network I/O.
> >
> > Bad things:
> >       Somewhat more overhead in processing timed routines.  The overhead
> > wouldn't
> >       be that high, though, since the event would be sent to activate the
> > timer
> >       task only when a callout was due.
> >
> > --
> > Eric Norum                                 eric at cls.usask.ca
> > Canadian Light Source                      Phone: (306) 966-6308
> > University of Saskatchewan                 FAX:   (306) 966-6058
> > Saskatoon, Canada.
> --
>    janovetz at uiuc.edu    | Once you have flown, you will walk the earth with
>  University of Illinois | your eyes turned skyward, for there you have been,
>                         | there you long to return.     -- da Vinci
>         PP-ASEL         | http://www.ews.uiuc.edu/~janovetz/index.html

Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985