On Fri, Aug 27, 2010 at 11:59 AM, Peter Teoh <htmldeveloper@xxxxxxxxx> wrote:
On Wed, Aug 25, 2010 at 1:18 PM, Lal <learner.kernel@xxxxxxxxx> wrote:
Is below code race free?
the answer (I suspect) is - yes....both SMP and UP. Conventional wisedom always say used the irqsave version, to protect against use of the spin locks inside the interrupt handler. And after reading all the posters, it is amply summarized in this doc as well:
But it is exactly the same concerns which Linus mentioned inside - the spinlocks occuring in the same CPU that give rise to deadlock - which is addressed by the use of trylock()!!! Correct? To rephrase my (mis)understanding again:
If the spinlock happened on different CPU - no deadlock, as after some time the owner will complete the job, and the waiter takes over.
If the spinlock happened on the same CPU - the interrupt-handler's issued a trylock first, so if it is in use.....no problem...it will not spinlock. but if the spinlock is not in use, then the interrupt handler will spinlock and unlock - and even if assuming in between intercepted by another interrupt (embedded interrupt - Intel x86 allowed up to 2 level)...still no problem......
So ultimately I really cannot see any problem arising from your implementation. Against conventional wisedom....but it works ..... or am I wrong? Please correct my misunderstanding....and thank you in advance.
--void process_context_function(void)
{
/* interrupts enabled here */
spin_lock(&lock);
modify_critical_section_list();
spin_unlock(&lock);
}
irqreturn_t a2091_intr (int irq, void *_instance)
{
if(spin_trylock(&lock)) {
modify_critical_section_list();
spin_unlock(&lock);
}
else {
/* skip */
}
return IRQ_HANDLED;
}
More specifically, can spin_lock & spin_trylock have race?
Regards
Lal
Have u ever considered mutex? Spinlocks are fast and efficient, but anything after the spinlock MUST NOT SLEEP, but, or risk being scheduled OUT of being processed by the CPU. Generally, in my present understanding, any locks inside the interrupt context should use spinlocks, and process context should use mutex locks, and race condition always appeared whenever the one running in process context is competing for resources with those in interrupt context - ie, avoid having locks that is cross-used in both context.Sorry if I am wrong, comment welcomed :-).
Regards,
Peter Teoh
--
Regards,
Peter Teoh
