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

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

[Nick Garnett]

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

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

[Nick Garnett]

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

> The pthread_cond_timedwait() function's 3rd parameter is a timespec
> structure containing absolute time. The clock_gettime() function does not
> support TIMER_ABSTIME. So how do I get hold of the absolute time that the
> pthread_cond_timedwait() function wants? I've tried to use the
> CLOCK_REALTIME id instead (and adding my delta time), but that doesn't work
> properly when used in the pthread_cond_timedwait() function?
> 

Looking at the code of both clock_gettime() and
pthread_cond_timedwait(), I cannot see anything obviously wrong with
either of them. In what way does pthread_cond_timedwait() not work
properly?

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

[ECOS] pthread_cond_timedwait() and absolute time?

[Carsten Andersen]

The pthread_cond_timedwait() function's 3rd parameter is a timespec
structure containing absolute time. The clock_gettime() function does not
support TIMER_ABSTIME. So how do I get hold of the absolute time that the
pthread_cond_timedwait() function wants? I've tried to use the
CLOCK_REALTIME id instead (and adding my delta time), but that doesn't work
properly when used in the pthread_cond_timedwait() function?


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

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