Messages in this thread | | | From | Ken Pizzini <> | Subject | Re: How to wait while polling | Date | Sun, 22 Aug 1999 21:22:15 -0700 |
| |
On linux-kernel message <Pine.PMDF.3.96.990822142935.49005A-100000@ic3.ithaca.edu>, <kbaker3@ic3.ithaca.edu> wrote:
> How do I wait in a >multitasking friendly method?
Use schedule_timout(). Parameter is the number of ticks (1/HZ second intervals) before you wish to be given control again.
>while ((count<3000) and (data!=BUSY)){ >parport_read_status(parport,data); >} > >but that is really nasty obviously. From looking around I have seen >udelay() and mdelay() whats the diff and how do I use them.
udelay() takes a microsecond argument, mdelay() takes a millisecond argument. udelay() operates in a tight loop, and so is quite multitasking-hostile for large delays (but essential for small delays). mdelay() actually calls udelay() in its own loop, because udelay() might fail due to overflowing its counter on very fast machines; thus it too is not friendly to other tasks wishing to run.
> I think I need around 1/200th of a second delay
How precisely? And how bad is it if the delay is a bit off (in each direction)?
Since HZ is only 100 on most systems, schedule_timeout() won't quite get you where you want to be --- you can either schedule_timeout(HZ/100), which probably delays too long (0.01 s, typically), or schedule_timeout(HZ/200), which probably doesn't delay long enough (~0 s typical, though it does allow other tasks to be scheduled before returning control to your driver).
Basically your choices for a 1/200 s delay are to hog the CPU and be precise with mdelay(5), or to be generous to other tasks but sloppy in your delay with schedule_timeout(0) (and a (limited) retry loop, since if you are the only runnable task you will regain the CPU quite rapidly).
--Ken Pizzini
- 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/
| |