On Tue, May 19, 2009 at 12:33 AM, Ole Loots <[email protected]> wrote: > Hello to the list, > > I got a question about spinlocks. Here is some pseudo-code: > > my_external_int_handler(...) > { > spin_lock(&my_lock); > // do things... > spin_unlock(&my_lock); > } > > my_ioctl_handler(ioctl_value) > { > switch(ioctl_value) > { > case xy: > spin_lock_irqsave(&my_lock, flags); > // do stuff > spin_unlock_irqsave(&my_lock, flags); > break; > } > } > > I just wan't to ensure that the interrupt is finished before I handle the > IOCTL request, so that I'm not running into a race condition that would a > affect an ring buffer. > But what happens when an interrupt signal is triggered at the external > interrupt pin, does spin_lock_irqsave que the interrupt? Or does it dismiss > the interrupt? Does spinlock_irqsave mean I would miss an interrupt? If so, > spinlock won't be the right thing to do... > > What I need is something like: > while(interrupt_working){ sleep(); } > > How to do right?
i think spinlock_irqsave means it disables the interrupt pins temporarily but not nullifying the queued interrupts. Once it is enabled again, it would fire the handler again. However, IIRC too, spin_lock_irqsave is disabling per CPU interrupt line. So if you run your code in SMP or multicore, there is a chance of both interrupt and ioctl handlers try to access the data. Although it is expected, perhaps you could consider using per CPU data ? regards, Mulyadi. -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to [email protected] Please read the FAQ at http://kernelnewbies.org/FAQ
