Re: Why time() and gettimeofday() can return different values

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi :)

On Fri, Nov 19, 2010 at 10:00, Adrian Cornish <adrianc@xxxxxxx> wrote:
> Hi Mulyadi,
>
> What worries me is that sequence of calling gettimeofday() and then
> time(), the value returned by gettimeofday() is in the future and in
> front of time()'s return value by more than 1,000,000 microseconds. To
> me this is unexpected, return value of time() should always equal tv_sec
> value from gettimeofday(). Ok I know there is no spec that says that -
> just what I would expect.

Perhaps there is something in POSIX specs regarding those functions
that I don't really know. But Linux doesn't always follow POSIX after
all, in few cases...

> Ok 1st time here, so here we are trying to get a read-lock on xtime
> using the
>  221                seq = read_seqbegin(&xtime_lock);
>  222
>
> So here we copy xtime to ts which cannot be atomic due to the size of
> xtime (on x86)
> No care is taken if xtime is currrently being update, so in theory ts
> could be junk
>  223                *ts = xtime;
>
> Work out how many nanoseconds has passed since (guessing) xtime was
> update but also
> include any ntp clock drift corrections (so nsecs > 1 second)
>  224                nsecs = timekeeping_get_ns();
>  225
>
> This does nothing on Intel
>  226                /* If arch requires, add in gettimeoffset() */
>  227                nsecs += arch_gettimeoffset();
>  228
>
> [Guessing] If xtime did not change by now - then we are good to break
> out the loop
> But if it did then lets go round again.
>  229        } while (read_seqretry(&xtime_lock, seq));
>  230
>
> Since it could have taken "some" time to get a good complete read of
> xtime, we better adjust
> it for how long we think it took (also applying any NTP movements). So
> now we could return a time
> that is greater the xtime's actual value by over a second.
>  231        timespec_add_ns(ts, nsecs);
>  232}


I am fairly agree with your above code commenting.

In fact, I suggest you to send a patch, simply to add commentaries
among those codes to LKML. Who knows, it helps lots of other people to
understand that function too? And it might invite further comments,
hopefully to optimize the function....

-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com

--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ




[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux