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
