Why can not processes switch in atomic context?

弋天 卜 buyit at live.cn
Wed Jul 4 06:44:04 EDT 2012



在 2012-7-3,22:26,"Parmenides" <mobile.parmenides at gmail.com> 写道:

> Hi,
> 
>    It is said that kernel can not be preempted in interrupt context
> and when it is in a critical section protected by a spin lock.
> 
> 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 think disable preemption in spinlock is not for safe, it is 
For efficiency. Spinlock should exit as soon as possible. 
If tank1 get spinlock and goto sleep for 100 seconds before 
Release spinlock, task2 which requests the same spinlock 
Should wait for 100 seconds, for this example, mutex should be used instead of spinlock.


> 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?

You are right, kernel can schedule in interrupt context, but that will delay the completion of interrupt, which does not make sense, so kernel will not do like this.
Note! Kernel can, but should not schedule in interrupt 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?
> 

Kernel developer can do anything they want to.
You are right, this can be done, but should not happen at all.


> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


More information about the Kernelnewbies mailing list