Re: [2.4.17/18pre] VM and swap - it's really unusable

[george anzinger]

Oliver Neukum wrote:
> 
> > Well, semaphores block.  And we have these races right now with
> > SCHED_FIFO tasks.  I still contend preempt does not change the nature of
> > the problem and it certainly doesn't introduce a new one.
> 
> But it does:
> 
> down(&sem);
> do_something_that_cannot_block();
> up(&sem);
> 
> Will stop a SCHED_FIFO task for a definite amount of time. Only
> until it returns from the kernel to user space at worst.
> 
> If do_something_that_cannot_block() can be preempted, a SCHED_FIFO
> task can block indefinitely long on the semaphore, because you have
> no guarantee that the scheduler will ever again select the the preempted task.
> In fact it must never again select the preempted task as long as there's
> another runnable SCHED_FIFO task.
> 
This is not true, and if it is is a scheduler bug.  When a task (any
task) gets preempted it is not moved from the front of its queue, thus,
in this case, the FIFO task will still be the fitst task at its prioity
to run.  Also, it can only be preempted by another real time task of
higher priority.  Now it is possible that that task may block on the
same sem, but this is simple priority inversion and has nothing to do
with the sem holder being FIFO, RR or any thing else.  In other words
preemption does NOT change a FIFO (or any other) task's position in the
dispatch queue.

-- 
George           [e-mail]
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Real time sched: http://sourceforge.net/projects/rtsched/