Re: [ECOS] pthread_cond_timedwait() and absolute time?

[Nick Garnett <nickg at calivar dot demon dot co dot uk>]

Carsten Andersen <Carsten.Andersen@csr.com> writes:

> Hi,
> 
> First of all: Thanks for the reply!

Please also rememeber to copy messages to ecos-discuss - that way
everyone gets to benefit, and the answers go into the archive.

> 
> The timing seems to be wrong. I believe that the time before return is too
> long? As I read it, the absolute time given to pthread_cond_timedwait()is
> really absolute time, hence "now" plus some delta? Does that also apply to
> eCos when TIMER_ABSTIME is not supported? Or is the absolute time only the
> delta? This may explain my problems.

Remember that time only advances in timer tick incerements, usually
10ms. Any time value smaller than that, or which falls between two
ticks will be rounded up to the next. Maybe that's what is happening
to you.

TIMER_ABSTIME has nothing to do with any of this, it is a flag passed
to timer_settime() to indicate how the it_value is
interpreted. Arguments to pthread_cond_timedwait() are always
absolute.

> 
> I'm running this on an ARM Evaluator7T platform with the default timing
> settings: clock resolution 10ms, CYGNUM_KERNEL_SCHED_TIMESLICE_TICKS 5
> (although I've tried to change this to 2).
>

The timeslice value should have no effect on any of this.

> I've attached the piece of code causing the problem.
> 
> --- sniplet begin ---
> 		timeUntilNextTimedEvent = ....
> 		pthread_mutex_lock(&mutex);
> 		if (timeUntilNextTimedEvent > 100 * MILLISECOND)
> 		{
> 			struct timespec absoluteTime;
> 			time_t sec;
> 
> 			clock_gettime(CLOCK_REALTIME, &absoluteTime);
> 
> 			sec = timeUntilNextTimedEvent / SECOND;
> 			absoluteTime.tv_sec += sec;
> 			absoluteTime.tv_nsec += (timeUntilNextTimedEvent -
> sec * SECOND);
> 			if (absoluteTime.tv_nsec >= 1000000000L)
> 			{
> 				absoluteTime.tv_nsec -= 1000000000L;
> 				absoluteTime.tv_sec++;
> 			}
> 
> 			pthread_cond_timedwait(&notIdleCondition, &mutex,
> &absoluteTime);
> 		}
> 		pthread_mutex_unlock(&mutex);
> --- sniplet ends ---
>

This looks OK. You could try adding some diag_printf()'s to report the
values of the timespecs to check that the right calculations are being
done. It may also be useful to trace with gdb/Insight through
pthread_cond_timedwait() and check that the right resulting ticks value
is being passed to cond->wait().

That's all I can really think of for now.

-- 
Nick Garnett - eCos Kernel Architect


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss