Re: What is a sleeping spin locks?

[Rene Herman <rene.herman@xxxxxxxxxxxx>]

On 05-08-08 17:55, Peter Teoh wrote:

> On Tue, Aug 5, 2008 at 2:02 AM, Rene Herman <rene.herman@xxxxxxxxxxxx> wrote:

> > On 04-08-08 17:36, Peter Teoh wrote:

> > > I don't quite understand.   Normal spin lock is poll-based, but 
> > > sleeping spin lock is not, then how does it differed from mutex 
> > > then?
> >
> > In principle, they do not. I've never looked at the RT stuff in
> > detail but I believe that in practice, it's specifically an _RT_
> > mutex, which features priority inversion avoidance over regular
> > mutexes.
>
> With ref to Thomas Gleixner presentation:
>
> http://www.kernel.org/pub/linux/kernel/people/tglx/preempt-rt/rtlws2006.pdf

I hate those damn bullet point sheets everyone just dumps on the web and 
pretends are useful as anything other than a personal talk-guide.

Come to think of it, I also hate talks...

> page 8:
>
> a.   What is the difference between rtmutex and normal mutex? 
> Basically the features of these mutex is just an atomic check on some
>  variables, and followed by looking the scheduling queues for any 
> runnable tasks, correct?   As for the difference, I suspect it is
> just to make mutex more preemptible, so as to reduce latency (at the
> cost of slower performance).   Correct?

As stated, PI is the big difference. There was a thread on PI on this 
list not long ago.

> So the reason why spinlock have to disable interrupt, are reasons as
> given above.

Note -- not all spinlocks need to disable interrups. Only spinlocks that 
are taken also from interrupt context.

> But if now without interrupt disabled on the same CPU, then the 
> scenario as described above will not happen as well, because, the 2nd
> spinlock processing in interrupt mode, will itself be interrupted, 
> and CPU execution returned back to the process context.
>
> So no problem right? Just want to know if my logic has any bugs,
> thanks.

Yes. Interrupt handlers are themselves schedulable entities under RT and 
 anything of higher priority (don't know if that can only be a 
different interrupt that has been marked as higher priority or something 
else as well -- too much RT detail) will interrupt them same as a 
regular process would be under a normal kernel.

Ofcourse, that's the kind of thing you need to be able to live up to RT 
guarantees.

Rene.

--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ