This is the mail archive of the ecos-devel@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ECOS] periodic threads with kapi?


On Mon, Aug 18, 2003 at 09:53:18AM +0100, Bart Veer wrote:
>     >> void
>     >> my_thread_delay_absolute(cyg_tick_count_t abs_time)
>     >> {
>     >>     cyg_tick_count_t delay = abs_time - cyg_current_time();
>     >>     if (delay > 0) {
>     >>         cyg_thread_delay(delay);
>     >>     }
>     >> }
>     >> 
>     >> There is a possible problem if the current thread gets descheduled
>     >> between the cyg_current_time() and cyg_thread_delay() calls, causing
>     >> the thread to get delayed for longer than intended. You could avoid
>     >> that by e.g. temporarily boosting the current thread's priority.
> 
>     Ryan> The problem still exists doing it that way. In fact that
>     Ryan> would even make it worse.
> 
>     Ryan> The point is that I don't want to read the current time each
>     Ryan> period in my thread. That causes drift.
> 
> There is no drift. The calling code should calculate the new value of
> abs_time by adding the appropriate number of ticks to the previous
> value of abs_time, thus moving from one absolute time to the next. For
> example adding 100 each time will give absolute intervals of 1 second
> (assuming the usual 10ms clock).

What if a timer interrupt happens between the delay calculation and the time
the timer is actually set? I think that would cause drift. Am I wrong? The
delay would be one tick off in the same direction every time that happens.

Cyg_Thread::delay calls Cyg_Thread::set_timer passing an absolute time. An
absolute delay function would be better if it's argument was unchanged
before it got passed to Cyg_Thread::set_timer. The function you suggested
subtracts the current time and then adds the current time back in later.

I do see that Cyg_Thread::delay calls Cyg_Scheduler::lock before doing the
abs time calculation. Does locking the scheduler prevent timer interrupts?
If it does then I suppose the suggested function would work as long as the
scheduler were locked for the whole thing.

But wouldn't it be better to just pass the absolute time unchanged? It's
fine to implement relative time in terms of absolute time, but it seems like
a bad idea to try and implement absolute time in terms of relative time.


> If instead the calling code calculated the new value of abs_time by
> adding 100 to cyg_current_time() rather than to the previous value of
> abs_time then you would get drift - that would be equivalent to
> calling cyg_thread_delay().

That would cause lots of drift. I am talking about the very little drift
that occurs if the current time changes between the delay calculation and
the setting of the timer.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]