Re: Question regarding spinlock

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

 





On Tue, May 19, 2009 at 10:52 PM, Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx> wrote:
Hi...

Sorry if my earlier post confused some people. What I wanted to say
was actually that spinlock is SMP safe, however, in multicore it makes
code running on a cpu might spin to wait for other code running on
different cpu.

       If the data is unique to each processor, there may be no need to protect it with a lock because only that one processor can access the data. In this case we need to use preempt_disable() and preempt_enable() to protect data from concurrent access by multiple processes. 


Thanks 
Shyam
 


so, to avoid this, perhaps the original poster could gain better
scalability by adopting per CPU data structure. Therefore, spin lock
usage is reduced only on cases e.g data must be global across CPU or
blocking wait is not an option

regards,

Mulyadi.


On 5/19/09, Shyam Burkule <shyam.burkule@xxxxxxxxx> wrote:
> All,
>
> On Tue, May 19, 2009 at 3:33 AM, raz ben yehuda <raziebe@xxxxxxxxx> wrote:
>
>>
>> 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 ?
>
>
>
> Spinlock are meant to write SMP safe routines. On UP, using spinlock get
> compiled to disable/enable of kernel preemption.
>
>     spinlock_t xxx_lock = SPIN_LOCK_UNLOCKED;
>     unsigned long flags;
>
>
> spin_lock_irqsave(&xxx_lock, flags);
>          /* Critical Section*/
>       spin_unlock_irqrestore(&xxx_lock, flags);
>
> Above code is always safe. It disable interrupts *locally* but the
> spinlock guarantee
> the global lock.
>
>
>
>
>
>
>
>>
>> > 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
>>
>>
>


[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