1, the function that prohibits kernel preemption is preempt_disable (), the method that allows kernel preemption is preempt_enable ()
2, why call Preempt_disable () to close the preemption case before the real lock
http://blog.csdn.net/kasalyn/article/details/11473885
[CPP]View Plaincopy
- static inline void Raw_spin_lock (raw_spinlock_t *lock)
- {
- Preempt_disable ();
- Do_raw_spin_lock (lock);
- }
Why call Preempt_disable () to close preemption before a real lock is locked?
Related Data structures:
in struct thread_info
{
unisgned int preempt_count;-----(preempt 0-7-bit indicates a kernel state prohibit preemption counter, SOFTIRQ 8-15 indicates a soft interrupt suppression counter, HARDIRQ 16-27 indicates the depth of the interrupt nesting)
}
Kernel-State preemption is allowed only if preempt is 0 o'clock.
= = "
1. If the kernel can be preempted, a single CPU
Process1 enters the kernel state through the system call, if it needs access to the critical section, it gets locked, locked, v=1 before entering the critical section, then enters the critical section
If an external interrupt occurs while the PROCESS1 is executing a critical section code in the kernel state, when the interrupt handler returns, because the kernel is preemptive, a dispatch point will appear, If there is a process process2 in the CPU's running queue that is higher than the currently interrupted process Process1, then the interrupted process will be swapped out of the processor, even if it is running in the kernel state at this time.
If the PROCESS2 also enters the kernel state through system calls and accesses the same critical section, a deadlock is formed (because the PROCESS1 with the lock will never be able to run again to release the lock)
2. If the kernel can be preempted, multi-CPU
CPU1 on the PROCESS1 through the system call into the kernel state, if it needs to access the critical section, before entering the critical section to obtain a lock, locked, v=1, and then enter the critical section
If an external interrupt occurs while the PROCESS1 is executing a critical section code in the kernel state, when the interrupt handler returns, because the kernel is preemptive, a dispatch point will appear, If a process process2 with a higher priority than the currently interrupted process Process1 in the CPU1 's running queue, the interrupted process Process1 will be swapped out of the processor, even if it is running in the kernel state at this time.
If the PROCESS3 on the CPU2 also enters the kernel state through the system call and accesses the same critical section, the deadlock is also formed
3, Memory barrier related
http://blog.csdn.net/joker0910/article/details/7782765
[CPP]View Plaincopy
- #define PREEMPT_DISABLE () \
- do{\
- Inc_preempt_count (); \
- Barrier (); \
- } while(0)
Memory barrier to force the instructions before and after the statement to complete in the correct order, in fact, in the instruction sequence to put a wmb effect is to make the instruction execution to that place, all the cached data is written to where it is written,
At the same time, the WMB in front of the written instruction must be executed before the WMB write instruction. RMB (read memory barrier) ensures that the read operation before the barrier will be completed before the subsequent read operation is performed. WMB to ensure that the writing exercise
Do not mess up, the MB directive guarantees that neither will. These functions are a superset of the barrier function.
[Linux kernel] [Linux interrupt]--kernel preemption