Messages in this thread | | | Date | Mon, 13 Dec 1999 18:34:26 +0100 (CET) | From | Andrea Arcangeli <> | Subject | Re: 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/
| |