Eli Carter writes:
> And you described (in much better detail) the same problem I was talking
> about in the first email I sent today.
Ok, at least we've got the same picture that we're working from now.
> Yes, but it digs another to get the dirt to fill the first one. :/ for
> instance:
>
> >
> > read_lock_xtime_and_ints();
> > jiffies_1 = jiffies;
> > counter_1 = counter;
> > read_unlock_xtime_and_ints();
>
> Time passes due to an interrupt handler.... but not a full jiffy, so
> jiffies hasn't changed.
> Also, what if this function is called with interrupts disabled? (Is
> that legal?) If so, we've broken the locking expected by the caller.
The calling function does indeed do the read_lock_xtime_and_ints() bit
for us. However, we can always do a read_unlock(); sti(); read_lock_irq();
in do_gettimeofday(). Whether we want to or not is another matter,
especially as its not nice for a called function to explicitly enable
interrupts.
As for timer interrupts taking more than 10ms, yes, that is another
problem. ;(
> Comments?
This problem has a non-trivial solution, and I think whoever originally
wrote the x86 do_gettimeofday code decided that it wasn't worth finding
a solution to it.
--
Russell King ([EMAIL PROTECTED]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
