[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Date: Tue, 05 Oct 1999 09:04:09 -0600
- From: eric at cls.usask.ca (Eric Norum)
- Subject: Timed routines
Joel Sherrill wrote:
> 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
I agree. That's why I proposed making the change to
and not to rtems_clock_tick.
> 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.
(2) sounds good to me. When would the decision be made? At
or at rtems_time_fire..()? As far as I can tell, either call would have
expanded to have another argument -- which implies that (1) may be
maintain compatability with existing application code.
> 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.
I suggested the count/event because I thought it would impose less
A lightweight counting semaphore would probably be a better way to go.
An `immediate action item' should be to add a note in the documentation
callbacks may run in the context of the clock interrupt handler and thus
subject to all the limitations on calls that can be made from an
Eric Norum eric at cls.usask.ca
Canadian Light Source Phone: (306) 966-6308
University of Saskatchewan FAX: (306) 966-6058