Re: [ECOS] posix time functions

[David Brennan <eCos at brennanhome dot com>]

Nick Garnett wrote:

> David Brennan <david@brennanhome.com> writes:
>
>  
>
> > I was also wavering if the new term needed to be protected by a
> > semaphore. I decided against it. (Due to the fact that an invalid
> > gettime would have relatively low risk of creating problems combined
> > with relative number of times that the time will be set within an
> > application.) However, if you feel it is necessary, I will add one.
> >
> >    
>
> This is good as far as it goes. However, you still need to make some
> changes in timer_settime() and timer_gettime(). These need to add or
> subtract the real_time_offset as appropriate. Consider the following
> code for example:
>
>    clock_gettime(CLOCK_REALTIME, &ts.it_value);
>    ts.it_value.tv_sec += 5;
>    timer_settime( timer, TIMER_ABSTIME, &ts, NULL );
>
>  
Hmmm, I did not think of people accessing it that way, I assumed that 
clock_gettime would only be used to get a calendar time. I had assumed 
(probably incorrectly) that to get the current real-time, one would use 
something like cyg_current_time(). Solving it like you suggest is only 
going to bring back the problem that I initially had. I haven't looked 
at the API closely, would it be safe to assume the code written above 
could be written using timer_gettime first?  The idea was that if you 
change the calendar time, you do not want all of the absolute timers to 
change their alarm times. In my application, I will set the time using a 
pseudo NTP type function about once an hour. Due to the timing 
resolution of the i386 platform with a base clock frequency of 1 kHz, I 
will set the time backwards about 200 mSec each hour.  This causes all 
of my alarms to get delayed by an extra 200 mSec. Therefore, I want to 
be able to change the time that posix thinks it is without affecting any 
"real" real-time timers, none of which are set from the clock_gettime 
function.
.

> I suspect that some changes will also need to be made in
> pthread_cond_timedwait() and similar functions, so that the following
> would work:
>
>    clock_gettime(CLOCK_REALTIME, &ts);
>    ts.tv_sec += 5;
>    rc = 0;
>    while (! mypredicate(&t) && rc == 0)
>        rc = pthread_cond_timedwait(&cond, &mutex, &ts);
>
>
> To avoid planting ifdefs all over the code I think that the offset
> adjustment should be done in macros. These can be defined to do
> nothing in the case where the option is disabled.
>
> Strictly, each time the clock is changed, all timers, delays and
> timeouts based upon it should be re-evaluated. However, this is
> complicated and we don't currently preserve all the information
> necessary to do this. 
>
>  
I think my comment above applies to this also.

> The patch seems to have been corrupted a little, sending it as an
> attachment should solve this.
>
>  
I can resend it as an attachment when we get this figured out. (Is it 
readable?)

David Brennan

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