Hi,
>> 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?
Current state of interrupts mean whether the interrupts are enabled or disabled at the time this code gets executed.
>>>> 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.
Are you talking about a single processor machine here? If yes, then the second writer will not get a chance to run untill the first writer completes its critical section. This is because if the first writer grabs the spinlock, the irqs are disabled and so is preemption. And so the writer will continue till spin_unlock_irqrestore()
Thanks,
Rajat
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
