Messages in this thread | | | Date | Tue, 8 Aug 2006 11:19:11 +0200 | From | Pavel Machek <> | Subject | Re: [KJ] [patch] fix common mistake in polling loops |
| |
Hi!
> >> >> Well, whoever wrote thi has some serious problems (in attitude > >> >> department). *Any* loop you design may take half a minute under > >> >> streange circumstances. > >> > >> 6. > >> common mistake in polling loops [from Linus]: > > > >Yes, Linus was wrong here. Or more precisely, he's right original code > >is broken, but his suggested "fix" is worse than the original. > > > > unsigned long timeout = jiffies + HZ/2; > > for (;;) { > > if (ready()) > > return 0; > >[IMAGINE HALF A SECOND DELAY HERE] > > if (time_after(timeout, jiffies)) > > break; > > msleep(10); > > } > > > >Oops. > > > >> >Actually it may be broken, depending on use. In some cases this loop > >> >may want to poll the hardware 50 times, 10msec appart... and your loop > >> >can poll it only once in extreme conditions. > >> > > >> >Actually your loop is totally broken, and may poll only once (without > >> >any delay) and then directly timeout :-P -- that will break _any_ > >> >user. > >> > >> The Idea is that we are checking some event in external hardware that > >> we know will complete in a given time (This time is not dependant on > >> system activity but is fixed). After that time if the event has not > >> happened we know something has borked. > > > >But you have to make sure YOU CHECK READY AFTER THE TIMEOUT. Linus' > >code does not do that. > > Sorry I did not realise that was your problem with the code. > Would it help if we just explicitly added a > > if (ready()) > return 0; > > after the loop, in the example code? so people wont miss adding > something like that in?
Yes, that would do the trick. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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/
| |