[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Short sleeps.
On Sat, 12 Jan 2002, Steve Baker wrote:
> > > I don't see a 'udelay' in any modern Linux docs.
> > Its a kernel thing.
> > Please Steve, couldn't you explain a bit more about what you are trying to
> > do? I am really curious. It may even help me/someone to come up with a
> > solution.
> Well, I have a piece of hardware that has to be polled to see if it has
> some information for me. The main process is doing 'normal' computational
> gamesy things at 60Hz update rates - but the parallel thread needs to check
> the hardware every couple of milliseconds or so - continually.
> Hence, the hardware thread must not busy-wait because if it does, the main
> program won't run at all.
Hmm. Depends on the thread scheduling policy, doesn't it? It will be a
complete waste of CPU cycles in any case, however.
> Unfortunately, I cannot discuss the nature of the hardware that I'm polling.
No problem, the problem is a lot clearer now. Braindead non-buffering
hardware is a curse.
> Probably, what I'll have to do is just make the main thread do all the
> work, testing the clock during all the big loops to be sure I don't miss
> anything. That's just a really *ugly* solution and I'd prefer to use a
> short duration 'sleep'.
Yes, the first obvious solution is to "do your own scheduling". IIRC
Quadro (spelling? You know, the networked VGA tetris thing that runs
smootly on absurdly low end hardware) does this to great lengths. It is
cumbersome though, but has been done in a lot of DOS games and such.
The next thing I think of is the fact that if you want to use hardware
that is this silly, and, in reality needs a realtime kernel, use a
realtime kernel and write your own device driver. I know your scenario is
that no other important process is running, but sooner or later you will
miss your 1 ms deadline when some ignorant process insists on running
through the whole timeslice, unless you use a realtime kernel.
Using the sound hardware still poses problems, AFAICT, course some process
may still be using the full timeslice once in a while. But it may be the
best solution for you.
Good luck. I would say it is a problem that is very hard to solve in
Linux. Would be interessting to know how it turns out.
And thanks for elaborating.
Mads Bondo Dydensborg. email@example.com
If you aim the gun at your foot and pull the trigger, it's UNIX's job to
ensure reliable delivery of the bullet to where you aimed the gun (in
this case, Mr. Foot).
- Terry Lambert, FreeBSD-Hackers mailing list.