RE: Why can not processes switch in atomic context?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




 
> 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.
>
 
yes, i think you are right, suppose task1 use spin_lock_irqsave() to get a spinlock,
then call schedule() to sleep for a long time, the interrupt on this cpu core will be
enabled by kernel, and if there is an interrupt triggered on the same cpu and
get the same spinlock, deadlock will happen.
 

 
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux