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 [EMAIL PROTECTED]
Please read the FAQ at http://kernelnewbies.org/FAQ
