About the difference between these two locks, some data just describe the differences in the mechanism, the scene did not introduce the use of, for example, why sometimes you have to use spin lock it?
1, look at the spin-lock feature: If the lock is already occupied by another execution unit, then lock operation would have been dead over there and so on.
2, if the holding lock time is very short, then choose the spin lock, primarily to prevent the execution units sleep on such high efficiency. If a long time to read and write select signals and the amount of the semaphore.
You must use spin lock it and under what circumstances?
The answer is: kernel preemption or the case of SMP, cpu and not in single preemptive kernel, does not require spin lock. If not what will happen then? A deadlock occurs. Not occupied a release, a dead so on.
spin lock associated implementation there are several, which depends primarily on the use of the critical area of resource sharing entities.
1, for single core cpu is preempted, if the sharing of resources between the different processes that occur in a spin lock on the line; If you interrupt also access a critical section, then they would have a spin lock irq
2, the same as for multi-cpu, regardless of preemption preemption, use the spin lock, if interrupts have access to a critical section, then use the spin lock irq
So, interrupt access to use spin lcok irq, there is no interruption to participate with spin lock, or have access to the lower half, with a spin lock bh
More often refer to here:
http://m.blog.chinaunix.net/uid-9620812-id-1643085.html , it is part of the Link to the content.
Obtain spin locks and releases the spin lock There are several versions, so let readers know what version of obtain and release the lock under what circumstances macro is very necessary.
If the shared resource to be protected and accessible only to the context of the visit in the context of soft interrupt the process, then when in the context of the process to access shared resources, may be soft interrupt interrupted, which may enter the soft interrupt context access to shared resources to be protected, and therefore in this case, access to shared resources must be used to protect spin_lock_bh and spin_unlock_bh.
Of course, the use of spin_lock_irq and spin_unlock_irq and spin_lock_irqsave and spin_unlock_irqrestore also be, they fail the local hardware interrupt, hardware interrupt failure implicitly also ineffective soft interrupt. But using spin_lock_bh and spin_unlock_bh is the most appropriate, it is faster than the other two.
If the shared resource to be protected just context and tasklet or timer context of access in the process, you should use the same situation as above to obtain and release the lock macro because tasklet and soft interrupt timer is implemented.
If the shared resource protected access only in the context of a tasklet or timer, you do not need any spin lock protection, because the same tasklet or timer can only run on a CPU, even if the same is true in an SMP environment. In fact tasklet when calling tasklet_schedule mark it need to be scheduled to have the tasklet bound to the current CPU, so the same tasklet never be run on a different CPU.
timer is in use add_timer it is added to the queue when the timer has been set to help the current CPU, it will never be run on other CPU with a timer. Of course, there are two instances of the same tasklet less likely to run in the same CPU.
If the shared resource protected access only in two or more tasklet or timer context, and then only use spin_lock spin_unlock to protect access to shared resources, do not use _bh version, because when tasklet or timer is running, it is impossible there are other tasklet or timer running on the current CPU.
If the shared resource to be protected only in a soft interrupt (tasklet and timer except) the context of access, then the need to share resources and spin_lock spin_unlock to protect, because the same software interrupt can run on different CPU.
If the protection of shared resources in two or more soft interrupt context access, then of course this sharing of resources needed to protect spin_lock and spin_unlock, different soft interrupt can run simultaneously on different CPU.
If the shared resource to be protected in soft interrupt (including tasklet and timer) or process context and interrupt context access to hard, then soft interrupt or process context during the visit, it may be interrupted interrupted hard to enter the hardware interrupt context of shared resources access, therefore, need to use the context spin_lock_irq and spin_unlock_irq to secure access to shared resources in the process or soft interrupt.
And what version of the interrupt handler, the need to depend on the circumstances, if there is only one interrupt handler to access the shared resource, you need to interrupt handler only spin_lock and spin_unlock to secure access to shared resources on it.
Because during the execution of an interrupt handler, the process can not be interrupted or interrupting soft on the same CPU. But if there are different interrupt handler to access the shared resource, you need to interrupt handler used spin_lock_irq and spin_unlock_irq to secure access to shared resources.
In the case of spin_lock_irq and spin_unlock_irq, you can use spin_lock_irqsave and spin_unlock_irqrestore replace that concrete should be used which also requires the case may be, if you can be sure that the interrupt is enabled before access to shared resources, then better use spin_lock_irq some.
Because it is faster than the spin_lock_irqsave, but if you are not sure whether the interrupt is enabled, then the use of spin_lock_irqsave and spin_unlock_irqrestore better, because it will restore the interrupt flag before accessing a shared resource rather than directly to enable interrupts.
Of course, you need to have to interrupt failure when accessing a shared resource, in some cases, but after the visit must interrupt enable, such a situation and use spin_lock_irq spin_unlock_irq best.
spin_lock for blocking on different CPU's execution units to simultaneously access a shared resource and a different process context compete with each other unsynchronized access to shared resources caused by the interrupt soft interrupt failure and failure is to prevent soft interrupt on the same CPU interruption or unsynchronized access to shared resources.
Personally, I think: kernel control path (kernel mode access processes, hardware interrupts, lower half) exclusive key issue is to understand the nature of the use of critical sections is to see those paths to access shared resources:
1 to see if the multi-CPU access to shared resources: if so, to apply spin_lock or semaphore, semaphore process context switch can happen in the case of multi-CPU, multi-CPU also rely spin_lock mutually exclusive.
Of course, if we can determine the critical area in interrupt context sure to use spin_lock.
a) to see whether the hardware interrupt access to critical areas: if so, use spin_lock_irq () / spin_unlock_irq, to save the flag register to use spin_lock_irqsave () / spin_unlock_irqrestrore ().
b) If the critical region could have access to the lower half (timer_list, tasklet also belong here, because they rely on to achieve the lower half), and if so, will have to spin_lock_bh () / spin_unlock_bh
2 If not affected by the multi-CPU, hard look at the interruption, the impact of the lower half, using the corresponding hardware interrupt or shut down a local BH
local_irq_disable/local_irq_enable
local_bh_disable/local_bh_enable
In short: is more CPU, kernel preemption, hardware interrupt, half of the small problems, spin_lock handle multiple CPU mutex, local issues and local hard interrupt the lower half of the
complete local_irq_disable local_bh_disable.