Re: Xterm Hangs - Possible scheduler defect?

[Ingo Oeser <ioe-lkml@axxeo.de>]

Chris Friesen wrote:
> Ingo Oeser wrote:
> > Stupid applications can starve other applications for a while, but not
> > forever, because the kernel is still running and deciding.
>
> Not so.
>
>
>
> task 1: sched_rr, priority 1, takes mutex
> task 2: sched_rr, priority 2, cpu hog, infinite loop
> task 3: sched_rr, priority 99, tries to get mutex
>
> And now tasks 1 and 3 are starved forever.  Arguably bad application
> design, but it demonstrates a case where applications can starve other
> applications.

You are right.
 
In "If a SCHED_RR process has been running for a time period  equal  to  or 
longer  than  the  time quantum,  it  will  be  put at the end of the list for
its priority" I missed the "for its priority" part.

You would need to change the priority of task 1 until it releases the
mutex. Ideally the owner gets the maximum priority of
his and all the waiters on it, until it releases his mutex, where he regains
its old priority after release of mutex. But this priority elevation happens
only, if he is runnable. If not, he gets his old priority back, until he is 
runnable.

But then again you just need to grab a mutex shared with a high priority
task and consume CPU.

Since this behavior is not defined in POSIX AFAIK, you just have
to write your applications properly or use SCHED_OTHER for CPU hogging.


Regards

Ingo Oeser