Re: scheduling with spinlocks held ?

[Muthian Sivathanu]

thanks for the pointers !

in general, would it make sense to explicitly
distinguish between mutex semaphores and others (maybe
for producer consumer queues), i.e. have a separate
structure mutex_semaphore with its own up() and down()
 -- this will probably facilitate more fine grained
handling of such priority inversion problems since one
can accurately track the number of mutexes, if any,
that a process is holding at any given point ?

Muthian.

--- Robert Love <[e-mail]> wrote:
> On Tue, 2003-07-01 at 17:10, Muthian Sivathanu
> wrote:
> 
> > Is it safe to assume that the kernel will not
> preempt
> > a process when its holding a spinlock ?  I know
> most
> > parts of the code make sure they dont yield the
> cpu
> > when they are holding spinlocks, but I was just
> > curious if there is any place that does that.
> 
> Correct.
> 
> > Basically, the context is, I need to change the
> > scheduler a bit to implement "perfect nice -19"
> > semantics, i.e. give cpu to nice 19 process only
> if no
> > other normal process is ready to run.  I am
> wondering
> > if there is a possibility of priority inversion if
> the
> > nice-d process happens to yield the cpu and then
> never
> > get scheduled because a normal process is spinning
> on
> > the lock.
> 
> You will hit priority inversion... not with
> spinlocks but with
> semaphores (and possibly more subtle issues).
> 
> The only safe way to do this safely is to boost the
> task's priority out
> of the "idle" class when the task is inside the
> kernel.
> 
> It is nontrivial to juggle user vs. kernel returns
> such as that. Google
> for Ingo Molnar's SCHED_BATCH addition to the O(1)
> scheduler.
> 
> 	Robert Love
> 
> 

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com