| |
Iain McInnes wrote:
[snip]
>
> The timers are stored in a linked list by the timer module.
> The reason that the per-tick overhead is so low, is that only the timer at the
> front of the list is decremented, on each tick. The timers are stored in order:
> First one to time out will always be at the front. So we only have to decrement
> its counter. Once it expires, it is removed from the list, and its handler
> called. In order to preserve the proper time relationships, the timers further
> back in the list have the times of the timers in front of them subtracted in
> advance, since this much time has already expired once they get to the front.
> So every timer on the list other than the first one stores a ‘delta’ time value.
Great idea!
> This approach requires some additional work when the timer is started, since the
> timer must be inserted in sorted order.
> All of this is invisible, of course, to clients.
> The current implementation requires client routines to allocate the client
> structs. This is intentional, since I feel that low level services such as
> these should be independent of memory management policy (such as malloc). The
> timers can be made easier to use for those who want it by providing a wrapper
> that does the malloc and free operations. I haven’t implemented these.
In your implementation, would it be possible for the client task to be
killed (in the case of a run-away task)... causing the struct to be
deallocated... while the struct is still in the linked list?
[snip]
>
> Reentrancy: The routines that need to be are reentrant. Especially the
> timer_start() routine. The routines that manipulate the timer list protect the
> list from corruption by disabling interrupts. The timer_tick () routine is not
> re-entrant, since it expects that interrupts are already disabled when it is
> called.
Which version of BrickOS are you working with?
You may be able to use:
ENTER_KERNEL_CRITICAL_SECTION();
LEAVE_KERNEL_CRITICAL_SECTION();
instead of disabling interrupts.
[snip]
> I am happy to make my code available for ppl to inspect, and try out. I welcome
> feedback on design and implementation correctness, and coding style. I believe
> that you will find the code to be easy to read, and I’ve tried hard to make it
> bullet proof (I do this kind of stuff for a living).
I would be interested in taking a look.
// Joe
|
|
Message has 1 Reply:
 | | Re: Implementation of Installable Timers
|
| (...) You are right. I found in an app that I was using that if I pressed the run / stop button, my task would be killed, and leave a dangling timer - which would usually blow the little brick into the weeds :o) I 'solved' it in a crude way by (...) (20 years ago, 9-Jan-04, to lugnet.robotics.rcx.legos)
|
Message is in Reply To:
| | Implementation of Installable Timers
|
| Hello everybody. I have an implementation of installable timer handlers, and I’d like to solicit some feedback. This is definitely a facility that I’d like to see in BrickOS. The implementation doesn’t have to be my one. But I thought that I’d just (...) (20 years ago, 8-Jan-04, to lugnet.robotics.rcx)
|
5 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
