Andrea Arcangeli replied:
> I am not sure we are talking about the same thing, but time_t is a 32bit
> on i386. While xtime is a 64 bit (it has both time_t and the suseconds_t).
> If I remeber well only movq (MMX) can move 64 bit at once on i386. But I
> don't think the 64 bit thing is the issue.
> I think the issue is timer_reg. What is timer_reg? To avoid a xtime_lock
> we must make sure that the other CPU is not in the middle of the xtime
> updating (so that only half of the xtime struct is been updated).
Umm if you can write to it atomically, that solves everything.
And I think I have the (x86) solution.... cmpxchg8b.
It's only an issue on SMP, which means it only matters on Pentium
and up (linux deosn't support SMP 486's, right?), so we have cmpxchg8b.
It's kind of kludgey, but you can use it to write (as long as you know
the old value and allow for the possibility of looping if there may be
concurrent writers), and to read. Just load all 4 registers with 0,
and when you're done, the value is in EDX:EAX. If it was 0, it got
rewritten, but as long as %edx == %ecx and %eax == %ebx, the written value
won't actually change anything.
Of course, it means that either you have some ugly code or you have to choose
betweeen SMP support and being able to boot on a 486, but isn't that the
case anyway?
-- -Colin- 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/