Re: [ECOS] periodic threads with kapi?

[Nick Garnett <nickg at ecoscentric dot com>]

Ryan Boder <icanoop@bitwiser.org> writes:

> 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.

It is there mainly as a convenience. Many programs just need to delay
"for a bit" without having to do any calculations. The function was
inspired by the POSIX sleep() and nanosleep() functions.

It was always expected that more sophisiticated timing activity would
be handled by creating alarms.

> 
> 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.
>

The simplest modification would be along the lines suggested earlier:
lock the scheduler, calculate a relative delay and call
cyg_thread_delay(). Anything else would require more substantial
changes in the kernel, for which you would almost certainly need an
assignment.

> 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.

Go ahead, I see no reason not to include an absolute delay
function. Remember to include a ChangeLog entry, and if you can face
hacking the SGML, an update to the documentation.

Also I suspect that the new function should be called
cyg_thread_delay_absolute() or maybe cyg_thread_delay_until() to be
more consistent with the naming convention.



-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com      The eCos and RedBoot experts