lkml.org 
[lkml]   [1999]   [Dec]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: gettimeofday() a special case : why?
On 13 Dec 1999, Eric W. Biederman wrote:

>Dosemu does this now on single cpu systems.

Are you sure it's 100% reliable over the time, monotone and with a
picosecond precision and that such way can be extended to SMP?

>gettimeofday always returns a time recently in the past.

It's not a matter of recently in the past, but it must be _monotone_. If
you only lose coherency between tv_sec and tv_usec you can just have a TOD
that goes back instead of forward or equal sometime.

>And having an atomic variable by which keeps a generation number
>for (xtime & other magic constants should be trivial).
>
>Take one snapshot of the generation # at the start of gettimeofday,
>another snapshot at the end of gettimeofday. If the snapshots
>don't match take the slow path, because you've had a race.

read generation (= 1)
rmb()
read rdtsc-ref
read xtime-ref
rmb()
read generation (= 1)

ok now you are happy and you trust the rdtsc-ref and xtime-ref to be
coherent.

But look what was going on in the other CPU0.

CPU0 CPU1
------------------ ---------------------
++generation (= 1)
mb()
write rdtsc-ref
read generation (= 1)
rmb()
read rdtsc-ref
read xtime-ref
rmb()
read generation (= 1)
you are happy but you read a not coherent
value
++generation (= 2)
mb()
write xtime-ref

Maybe there's a trival way to implement the lock-less critical section and
I am missing it...

Andrea


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.694 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site