Re: gettimeofday() a special case : why?

Keith Owens (kaos@ocs.com.au)
Tue, 14 Dec 1999 17:54:51 +1100

On Mon, 13 Dec 1999 18:34:26 +0100 (CET),
Andrea Arcangeli <andrea@suse.de> wrote:
> 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...

#define update_in_progress 0x80000000

Kernel code.

while (1) {
int oldgen = generation;
if (xchg(&generation, oldgen|update_in_progress) & update_in_progress)
continue; /* Other CPU is updating, spin */
mb();
write_rdtsc_ref();
write_xtime_ref();
xchg(&generation, (oldgen + 1) & ~update_in_progress);
mb();
break;
}

User code.

while (1) {
int oldgen = generation;
rmb();
if (oldgen & update_in_progress)
continue; /* Kernel is updating, spin */
read_rdtsc_ref();
read_xtime_ref();
rmb();
if (oldgen == generation)
break; /* Consistent results */
}

SMP and kernel/user code safe. Worst case is a brief spin in all but
one of the cpus. It is not interrupt safe, does that matter for
gettimeofday?

-
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/