On Tue, May 19, 2009 at 12:33 AM, Ole Loots <ole@xxxxxxxxxxxxx> 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 ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
