Re: [ECOS] periodic threads with kapi?

[Ryan Boder <icanoop at bitwiser dot org>]

On Mon, Aug 18, 2003 at 07:00:41PM +0100, Bart Veer wrote:
> At time 401 the thread will call my_thread_delay_absolute(500), giving
> a calculated delay of 99. Assume we don't hit the window again, then
> the next wake up will occur at the desired time of 500. The code has
> compensated for the temporary drift and we are back to the desired
> periodic behaviour.
> 
> So there is no systematic drift, only occasional jitter.

Yes, I agree, I must have not been using my brain when I wrote that email.


> In the end it all depends on the application. Some applications can
> tolerate the occasional variation, and the original code will work
> just fine. Other applications need more accurate intervals, but
> achieving that accuracy requires extra code, affecting both code size
> and cpu cycles.

I still question the decision to make the delay function relative instead of
absolute. Especially when the underlying timer that implements the delay
already uses absolute time.

I think a better implementation would be to add a
cyg_thread_absolute_delay() and then change cyg_thread_delay() to do nothing
but call cyg_thread_absolute_delay(cyg_current_time() + delay). That would
remove an unnecessary calculation and function call for applications that
want periodic tasks, while not changing the way cyg_thread_delay() works.

That makes it easier for people who want periodic tasks as well as removes a
calculation for them.

I'll write a patch for this and if you want to apply it fine, if not, I'll
just apply it to my own applications. Unless someone can convince me that
it's better to do it another way.

-- 
Ryan Boder
http://www.bitwiser.org/icanoop