为什么在内核代码持有自旋锁之后linux禁用内核抢占? [英] Why linux disables kernel preemption after the kernel code holds a spinlock?

问题描述

我是Linux的新手，正在阅读Rubini& amp;的Linux设备驱动程序书. Corbet.我对与spinlocks有关的一种说法感到困惑；这本书说

I am new to Linux and am reading Linux device drivers book by Rubini & Corbet. I am confused at one statement related to spinlocks; the book states

如果非抢占式单处理器系统曾经进入过 旋转锁，它将永远旋转；没有其他线程能够获得 CPU释放锁.因此，单处理器系统上的自旋锁操作 没有启用抢占功能的情况下，除以下情况外，优化后不执行任何操作: 更改IRQ屏蔽状态的代码.

If a nonpreemptive uniprocessor system ever went into a spin on a lock, it would spin forever; no other thread would ever be able to obtain the CPU to release the lock. For this reason, spinlock operations on uniprocessor systems without preemption enabled are optimized to do nothing, with the exception of the ones that change the IRQ masking status.

进一步说明

内核抢占情况由自旋锁代码本身处理.随时内核 代码具有自旋锁，在相关处理器上禁用了抢占.即使是单处理器 系统必须以这种方式禁用抢占以避免竞争状况.

The kernel preemption case is handled by the spinlock code itself. Any time kernel code holds a spinlock, preemption is disabled on the relevant processor. Even uniprocessor systems must disable preemption in this way to avoid race conditions.

问题:在单处理器系统上，如果每当一个内核代码(代表用户进程执行)持有自旋锁时，内核抢占就被禁用，那么另一个进程怎么会有机会运行并因此尝试获取自旋锁?为什么每当内核代码持有自旋锁时，Linux内核都会禁用内核抢占?

Question : On a uniprocessor system, if kernel preemption is disabled whenever a kernel code (executing on behalf of the user process) holds the spinlock, then how could another process ever get a chance to run and hence try at acquring the spinlock ? Why does Linux Kernel disables kernel preemption whenever kernel code holds a spinlock?

推荐答案

第一个问题的答案就是第二个问题的原因.

The answer to your first question is the reasoning behind your second.

内核获取的自旋锁可以通过关闭抢占来实现，因为这可以确保内核在不干扰其他进程的情况下完成其关键部分.整个问题是，直到内核释放锁，其他进程才能运行.

Spinlocks acquired by the kernel may be implemented by turning off preemption, because this ensures that the kernel will complete its critical section without another process interfering. The entire point is that another process will not be able to run until the kernel releases the lock.

没有理由必须采用这种方式实施；这只是实现它的一种简单方法，它可以防止任何进程在内核持有的锁上旋转.但这仅适用于内核已获得锁的情况:用户进程无法关闭抢占，并且如果内核正在旋转(即，它试图获取自旋锁，但另一个进程已经持有该锁)，则最好保留抢占状态在！否则，系统将挂起，因为内核正在等待一个不会被释放的锁，因为持有它的进程无法释放它.

There is no reason that it has to be implemented this way; it is just a simple way to implement it and prevents any process from spinning on the lock that the kernel holds. But this trick only works for the case in which the kernel has acquired the lock: user processes can not turn off preemption, and if the kernel is spinning (i.e. it tries to acquire a spinlock but another process already holds it) it better leave preemption on! Otherwise the system will hang since the kernel is waiting for a lock that will not be released because the process holding it can not release it.

获得自旋锁的内核是一个特例.如果用户级别的程序获得了自旋锁，则抢占不会被禁用.

The kernel acquiring a spinlock is a special case. If a user level program acquires a spinlock, preemption will not be disabled.

这篇关于为什么在内核代码持有自旋锁之后linux禁用内核抢占?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！