Messages in this thread | | | From | Russell King <> | Subject | Re: gettimeofday question | Date | Mon, 19 Mar 2001 23:44:06 +0000 (GMT) |
| |
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 (rmk@arm.linux.org.uk) 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |