Why can not processes switch in atomic context?

anish singh anish198519851985 at gmail.com
Wed Jul 4 01:07:22 EDT 2012


Always CC Kernelnewbies.

On Wed, Jul 4, 2012 at 12:52 AM, Parmenides <mobile.parmenides at gmail.com> wrote:
>>> 1. For the spinlock case, it is easy to get if preemption is allowed
>>> in critical section, the purpose of protection provided by spinlock
>>> can not be achieved readily.
>> I don't know what you mean here.Please clarify.
>>>
>
> Sorry, this is not a problem really. :-)  A critical section protected
> by a spinlock is atomic. So, preemption is prohibited when kernel
> enter this kind of critical section. I just want make sure it is the
> case.
>
>
>>> 2. For the interrupt context case, I think when processing interrupt,
>>> kernel can be preempted in principle. But, this really increases the
>>> interrupt processing time which further cause longer response time and
>>> data missing in device. Except that, is there any other reasons?
>> data missing in device.Can you elaborate that?
>> Stack space is pretty limited in ISR context.Does that give you a clue?
>>>
>
> data missing: For example, if a interrupt sent by Ether card can not
> processed for a long time, some frames received from the cable might
> be discarded owing to its limit buffer on card.
> Actually, every process has its kernel stack. If a preemption occurs
> during interrupt processing, the stack of another process is used. So,
> I think stack space is not a problem at all.
https://lkml.org/lkml/2007/8/3/2 this thinks otherwise.Please read this as
stack space is one of the reasons why sleeping is not allowed in ISR context.
>
>
>>> 3. Kernel is responsible for prohibiiting passive process switches,
>>> namely preemption, in the above cases. But, It seems that it does not
>>> take care of active process swtiches, namely yield. For example, some
>>> code in a critical section protected by a spinlock can invoke
>>> schedule() to switch process passively. Is this the case?
>> I don't understand this question but we don't switch when we are holding
>> spinlock as that will jeopardize the integrity of the system i.e.
>> suppose you slept while holding spinlock.What would happen?
>
> So, kernel maintains its integrity relying on that we don't yield
> while in interrupt handler or critical section protected by a
> spinlock. If we do so, kernel do nothing at all. Why doesn't it refuse
> schedule when it finds out that we yield in a improper context.
AFAIK it prints some kind of warning message.Why don't you try this?
Call schedule in ISR context(try in threaded ISR) and share with us the results.



More information about the Kernelnewbies mailing list