<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:΢ÈíÑźÚ
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>
<BR> <BR>
<DIV id=SkyDrivePlaceholder></DIV>
<DIV>> Date: Wed, 4 Jul 2012 08:12:25 -0700<BR>> Subject: Re: Why can not processes switch in atomic context?<BR>> From: dhylands@gmail.com<BR>> To: buyit@live.cn<BR>> CC: mobile.parmenides@gmail.com; kernelnewbies@kernelnewbies.org<BR>> <BR>> Hi,<BR>> <BR>> On Wed, Jul 4, 2012 at 3:44 AM, ß®Ìì ²· <buyit@live.cn> wrote:<BR>> ><BR>> ><BR>> > ÔÚ 2012-7-3£¬22:26£¬"Parmenides" <mobile.parmenides@gmail.com> дµÀ£º<BR>> ><BR>> ...snip...<BR>> >> 1. For the spinlock case, it is easy to get if preemption is allowed<BR>> >> in critical section, the purpose of protection provided by spinlock<BR>> >> can not be achieved readily.<BR>> >><BR>> > i think disable preemption in spinlock is not for safe, it is<BR>> > For efficiency. Spinlock should exit as soon as possible.<BR>> > If tank1 get spinlock and goto sleep for 100 seconds before<BR>> > Release spinlock, task2 which requests the same spinlock<BR>> > Should wait for 100 seconds, for this example, mutex should be used instead of spinlock.<BR>> <BR>> Unless, of course, the interrupt that fired tried to acquire the<BR>> spinlock it preempted, in which case you would have deadlock, even on<BR>> an SMP system, if the same processor happened to be used for both.<BR>> </DIV>
<DIV> </DIV>
<DIV> we are talking about schedule in spinlock, but not the synchronization between</DIV>
<DIV>normal process and interrupt.</DIV>
<DIV> in your example, it is kernel developer's responsibility to make this correct, this is</DIV>
<DIV>why kernel give us the API spin_lock_irqsave(). if normal process and interrupt handler</DIV>
<DIV>will acquire the same spinlock, please use spin_lock_irqsave() instead of spin_lock().</DIV>
<DIV> </DIV>
<DIV><BR>> >> 2. For the interrupt context case, I think when processing interrupt,<BR>> >> kernel can be preempted in principle. But, this really increases the<BR>> >> interrupt processing time which further cause longer response time and<BR>> >> data missing in device. Except that, is there any other reasons?<BR>> ><BR>> > 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.<BR>> > Note! Kernel can, but should not schedule in interrupt context.<BR>> <BR>> Scheduling in an interrupt can hang the system. Lets suppose that A<BR>> acquires a resource, disabled interrupts and calls schedule. Then B<BR>> gets scheduled and wants the resource that A is holding so it blocks.<BR>> But since interrupts were disabled, the timer tick will never fire and<BR>> you're back into a deadlock situation again.<BR>> </DIV>
<DIV> </DIV>
<DIV> in your example here, i think A is the interrupt handler, rather than a normal</DIV>
<DIV>task, because we are talking about scheduleing in interrupt handler. if A</DIV>
<DIV>calls schedule, the interrupted task, let's suppose it is usb task, will go</DIV>
<DIV>to sleep. let's suppose cpu0 handles the interrupt handler A, and usb task runs</DIV>
<DIV>on cpu0 also. after A go to sleep, which equals the usb task go to sleep, there </DIV>
<DIV>must be another new task will be waked up by function switch_to(), let's suppose</DIV>
<DIV>this lucky guy is BT task, the interrupt on cpu0 could be re-enalbed by function svc_exit() </DIV>
<DIV>before BT task(or some other tasks) runs. </DIV>
<DIV> </DIV>
<DIV> i think disable interrupt on cpu0 inside A does not mean the interrupt can only be re-enabled by A. </DIV>
<DIV> </DIV>
<DIV> i am not saying it is good to schedule inside interrupt handler, i just want to make it clear that</DIV>
<DIV>this can be done, but is not a good behavior and make no sense.</DIV>
<DIV> </DIV>
<DIV><BR>> -- <BR>> Dave Hylands<BR>> Shuswap, BC, Canada<BR>> http://www.davehylands.com<BR>> <BR>> _______________________________________________<BR>> Kernelnewbies mailing list<BR>> Kernelnewbies@kernelnewbies.org<BR>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies<BR></DIV> </div></body>
</html>