Proactive-critical Zone interrupt handling

Proactive-critical zone interrupt handling

Hedgehog @http://blog.csdn.net/littlehedgehog

The problem with a lot of code in the Linux kernel to deal with race condition (competitive conditions) is to add a switch interrupt instruction such as the CLI STI, which seems like a little worth mentioning. In the Wait_on_buffer function (shown in the following code), the switch interrupt is simply to avoid the competition condition and interrupt the critical code interference?

static _inline void Wait_on_buffer (struct buffer_head * bh)

{

	cli ();		Off interrupt.

	while (bh->b_lock)	//If locked, the process goes to sleep, waiting for it to unlock.

		sleep_on (&bh->b_wait);

	STI ();		Open interrupt.

}

Let's take a look at Zhaobo's explanation:

when you enter a code area that may cause a competitive condition, the kernel uses CLI directives to turn off the response to an external interrupt, and the kernel executes the STI directive when the competition code area is executed to allow the CPU to respond to external interrupts.

Before continuing the discussion, I think it is necessary to reach a consensus on two issues, hehe, more serious.

1. In Wait_on_buffer (including other program code with the same switch interrupt instruction) They all belong to the kernel code, which means that the current process is running in the kernel state.

2, the kernel state of the process can not preempt.

On the 1th, it is very clear. Other than that, give two examples: first, we implement STI this privileged instruction, this can only be the kernel process execution, not the normal user rights can execute. If casually is a process to execute, may the system very early paralysis; second, that is, we read the code is the kernel code, so this is the kernel code, a bit of logic ...

On the 2nd, I want to say that if we are executing wait_on_buffer, we will not skip to other processes even if there is no interruption, and of course no other process is modifying the properties of this buffer exactly. Because the kernel is non preemption. Like the Do_timer here:

if (!cpl) return

		;			For Superuser programs, the counter value is not dependent on scheduling.

	schedule ();

You can see that if the kernel code executes Do_timer, he will return directly without performing a task switch.

So we can conclude that when the process executes wait_on_buffer, it is in the kernel state, even if there is no shutdown interrupt, it is not scheduled to be executed by another process. The only thing that can interfere with this "naked Wait" without a shutdown interruption is some other interruption. But to prevent these other interruptions from potentially changing some of the key variables in the critical section, we have to turn off the interruption just in case.

A comrade puzzled because he did not find the code in other interrupts that might modify the buffer to cause a critical zone exception, so it is not appropriate to write Linux. Or to explain it with a Zhaobo sentence:

in this regard can not be a matter-of-fact. If there is an interruption, it will be modified. Kernel programmers can't always be concerned about this.