All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Darren Jenkins <darrenrjenkins@gmail.com>
Cc: torvalds@osdl.org, Zed 0xff <zed.0xff@gmail.com>,
	kernel-janitors@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [KJ] [patch] fix common mistake in polling loops
Date: Tue, 08 Aug 2006 09:19:11 +0000	[thread overview]
Message-ID: <20060808091911.GA4245@elf.ucw.cz> (raw)
In-Reply-To: <82faac5b0608071753q71050d72uadcf55bc1e54f30e@mail.gmail.com>

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
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors

WARNING: multiple messages have this Message-ID (diff)
From: Pavel Machek <pavel@ucw.cz>
To: Darren Jenkins <darrenrjenkins@gmail.com>
Cc: torvalds@osdl.org, Zed 0xff <zed.0xff@gmail.com>,
	kernel-janitors@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [KJ] [patch] fix common mistake in polling loops
Date: Tue, 8 Aug 2006 11:19:11 +0200	[thread overview]
Message-ID: <20060808091911.GA4245@elf.ucw.cz> (raw)
In-Reply-To: <82faac5b0608071753q71050d72uadcf55bc1e54f30e@mail.gmail.com>

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

  parent reply	other threads:[~2006-08-08  9:19 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-28  8:28 [KJ] [patch] fix common mistake in polling loops Zed 0xff
2006-07-28  8:28 ` Zed 0xff
2006-07-28  8:51 ` [KJ] " Jeff Garzik
2006-07-28  8:51   ` Jeff Garzik
2006-07-28 12:43 ` [KJ] " Dmitry Torokhov
2006-07-28 12:43   ` Dmitry Torokhov
2006-08-05 11:40 ` [KJ] " Pavel Machek
2006-08-05 11:40   ` Pavel Machek
2006-08-05 11:45   ` [KJ] " Pavel Machek
2006-08-05 11:45     ` Pavel Machek
2006-08-06 23:39     ` [KJ] " Darren Jenkins
2006-08-06 23:39       ` Darren Jenkins
2006-08-07 23:34       ` Pavel Machek
2006-08-07 23:34         ` Pavel Machek
2006-08-08  0:53         ` Darren Jenkins
2006-08-08  0:53           ` Darren Jenkins
2006-08-08  2:53           ` Om N.
2006-08-08  2:53             ` Om N.
2006-08-10  0:25             ` Andrew James Wade
2006-08-10  0:25               ` Andrew James Wade
2006-08-10  1:11               ` Darren Jenkins
2006-08-10  1:11                 ` Darren Jenkins
2006-08-08  9:19           ` Pavel Machek [this message]
2006-08-08  9:19             ` Pavel Machek
2006-08-09 22:48 ` Darren Jenkins
2006-08-10 12:16 ` Alexey Dobriyan
2006-08-12  4:26 ` Darren Jenkins
     [not found] <6DvTu-6tk-17@gated-at.bofh.it>
     [not found] ` <6Ho72-7do-3@gated-at.bofh.it>
     [not found]   ` <6HpZd-1vB-19@gated-at.bofh.it>
     [not found]     ` <6I6B4-72S-7@gated-at.bofh.it>
     [not found]       ` <6I7np-8bD-11@gated-at.bofh.it>
2006-08-10 11:58         ` Bodo Eggert
2006-08-10 11:58           ` Bodo Eggert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060808091911.GA4245@elf.ucw.cz \
    --to=pavel@ucw.cz \
    --cc=darrenrjenkins@gmail.com \
    --cc=kernel-janitors@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.org \
    --cc=zed.0xff@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.