> From: Robert Love [mailto:[email protected]]
>
> And we can prevent starvation just by running the kernel thread at
> FIFO/99, because then it will never be starved by a higher priority
> task. If the RT task being starved is also at priority 99, it will
> eventually block (as in our example, on console I/O) and let the kernel
> thread run. If the RT task being starved is lower priority, then there
> is nothing to worry about.
/me is quite uneasy with that assumption; not that it is not
correct (it should), but I can think of cases where that does
not need to happen (for example, if you have another FIFO/99
task B after your user task A that depends on kernel task K0),
and that task B happens to hold it for too long for A to miss
deadlines.
> I guess a real deadlock could only occur if the FIFO/99 task does not
> block on the resource the kernel thread is providing but busy loops
> waiting for it.
I can think of a OpenOffice + sched_yield() style or a brain-damaged
poll for previous art. It would screw the whole equation.
Another example, I changed NGPT to do spin+futex for spinlocks,
but then it was changed back by someone to spinning again --
performance reasons [they said] - of course, Thou Shall Not
Use NGPT + Real-Time (tm). But how many of these are left? I am
so scared of JVMs...
This is even more prone to happen when you have priority
inheritance ... been there, done that, SysRq+E was my friend.
It gets uncomfortably close to the "not my problem if you don't
know to set up your system" area, but I would really prefer that
safeguard that then I can disable manually (by prioritizing down)
if I know where to push.
I?aky P?rez-Gonz?lez -- Not speaking for Intel -- all opinions are my own
(and my fault)