|
> Date: Wed, 4 Jul 2012 08:12:25 -0700
> Subject: Re: Why can not processes switch in atomic context? > From: dhylands@xxxxxxxxx > To: buyit@xxxxxxx > CC: mobile.parmenides@xxxxxxxxx; kernelnewbies@xxxxxxxxxxxxxxxxx > > Hi, > > On Wed, Jul 4, 2012 at 3:44 AM, 弋天 卜 <buyit@xxxxxxx> wrote: > > > > > > 在 2012-7-3，22:26，"Parmenides" <mobile.parmenides@xxxxxxxxx> 写道： > > > ...snip... > >> 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. > > Unless, of course, the interrupt that fired tried to acquire the > spinlock it preempted, in which case you would have deadlock, even on > an SMP system, if the same processor happened to be used for both. > we are talking about schedule in spinlock, but not the synchronization between
normal process and interrupt.
in your example, it is kernel developer's responsibility to make this correct, this is
why kernel give us the API spin_lock_irqsave(). if normal process and interrupt handler
will acquire the same spinlock, please use spin_lock_irqsave() instead of spin_lock().
> >> 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. > > Scheduling in an interrupt can hang the system. Lets suppose that A > acquires a resource, disabled interrupts and calls schedule. Then B > gets scheduled and wants the resource that A is holding so it blocks. > But since interrupts were disabled, the timer tick will never fire and > you're back into a deadlock situation again. > in your example here, i think A is the interrupt handler, rather than a normal
task, because we are talking about scheduleing in interrupt handler. if A
calls schedule, the interrupted task, let's suppose it is usb task, will go
to sleep. let's suppose cpu0 handles the interrupt handler A, and usb task runs
on cpu0 also. after A go to sleep, which equals the usb task go to sleep, there
must be another new task will be waked up by function switch_to(), let's suppose
this lucky guy is BT task, the interrupt on cpu0 could be re-enalbed by function svc_exit()
before BT task(or some other tasks) runs.
i think disable interrupt on cpu0 inside A does not mean the interrupt can only be re-enabled by A.
i am not saying it is good to schedule inside interrupt handler, i just want to make it clear that
this can be done, but is not a good behavior and make no sense.
> -- > Dave Hylands > Shuswap, BC, Canada > http://www.davehylands.com > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies@xxxxxxxxxxxxxxxxx > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies |
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
