This is the mail archive of the 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] posix time functions

Nick Garnett wrote:

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

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