On Tue, 2009-05-19 at 00:49 +0700, Mulyadi Santosa wrote:
> 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
please fix me if i am wrong.
what spinlock_irqsave does is:
1. saves current of local interrupts.
2. disables local interrupts
3. acquires a lock
any other context tries to to access the protected data will spin. else,
how would you protect the data in SMP ?
> 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
>
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
