Hi Rajat,
Thanks for your simple and clear explanation.
> > If so, How? How is it different from irqsave call?
>
> It will work only if you are absolutely sure that interrupts will be enabled when this code gets executed. If you are not sure about the current state of interrupts when you are trying to grab a spinlock, use spin_lock_irqsave(). This will be more clearer below:
I understand that all interrupts for that perticular processor will be
disable/enabled.
What do you mean by current state of interrupts?
> >> Suppose 2 writers are contending for spinlock. and if the code is as
> >> follows:
> >>
> >> write() {
> >> spin_lock_irqsave() /*critical lock */
> >> x++; spin_unlock_irqsave() /*critical unlock */ }
> >>
> >> If the second writen tries to acquire the lock, when the first writer
> >> is already holding it, how are flags managed. Will they not get
> >> overwitten by the second write. when happens when restoring?
>
> The "flags" is going to be a local / automatic variable (i.e. stored on the stack). And hence each of the writer threads will have its own copy. Even though an interrupt handler shares the stack with the process it interrupts, each of these will have its own copy of flags.
>
When releasing, it will release the spinlock and then restore the flags using
stored 'flags' and reenable the interrupts.
In this case, will there not be a problem of ISR not getting a chance
when there are continous reads happening.
>
> Thanks,
>
> Rajat
>
Thanks n Regards,
Bhanu J
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
