What you are generally speaking of is real-time
scheduling, where the name of the game is to control the latency,
or response-time, of a particular thread or task. It may also be necessary to guarantee a minimum amount of CPU-time per second to a particular thread, so that it cannot be crowded-out by another thread of greater or equal priority. So-called embedded systems,
where Linux is used to control a hardware device, place a high degree of importance on these issues.
"Turn it off! TURN IT OFF! Aaaiieeee....!"
--early experiment with a robotic arm, gone terribly wrong...
Linux is not a true RTOS (real-time operating system), although there are third-party improvements (from TimeSys and other vendors) which make it very close to one. The 2.6 scheduler does make a lot of improvements in that regard, with the so-called "pre-emptible kernel" and a faster, fairer scheduler. But, at least as far as I know, the "stock" kernel does not yet allow you to "reserve" a guaranteed-minimum block of CPU time to any one thread.
The scheduler attempts to allocate CPU-time fairly among the competing tasks, respecting both their activity-patterns (I/O vs.
CPU-bound, for example) and their user-set "priority" (nice
ness). It seeks to provide prompt (but not guaranteed) response to interrupts, respectful scheduling that also does not "starve" lower-priority threads, and a good balance among the various CPUs. But if two threads are both running at high priority, one of them can
crowd-out the other such that latency or CPU-share requirements are not