On 4/4/07, Rajat Jain <rajat.noida.india@xxxxxxxxx> wrote: > > > We often have a case where a driver wants to access its data structure > > > in process context as well as in interrupt context (in its ISR). In > > > such scenarios, we generally use spin_lock_irqsave() to grab the lock > > > as well as disable all the local interrupts. AFAIK, disabling of local > > > interrupts is required so as to avoid running your ISR (which needs > > > the lock) while process context is holding the lock. However, this > > > also disables any other ISRs (which DO NOT need the lock) on the local > > > processor. > > > > > > Isn't this sub-optimal? Shouldn't there be a finer grained locking? > > > > actually it's optimal. > > It's fastest to delay the interrupts a little and be done with what you > > want to do under the lock quickly, and THEN take the interrupt. This > > means the lock hold time is short, which significantly reduces > > contention on this lock... > > So on the same lines, if a data structure is accessed in both process > context and in a (single) driver ISR, should a driver use > spin_lock_irqsave() to get the lock in ISR? Or will a simple > spin_lock() suffice?
a simple spin_lock() should do,as in Linux the ISR's are not recursive,and you just need protection in a single ISR. Anubhav Rakshit -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
