在单处理器系统中, 关掉中断不关抢占意味着不存在竟态?

[dyron]

最近在看关于spin_lock这方面的一些代码, 翻了翻书, 看到之前的经典描述,有几点疑问, 请教一下.

1. 在<深入理解linux内核>中,有这么一个描述, 在单处理器系统中, spin_lock仅仅禁止和启用内核抢占, 请注意, 在自旋锁忙等期间, 内核抢占还是有效的, 等待锁释放的进程有可能被更高优先级
的进行抢占.
static inline void spin_lock(spinlock_t *lock)
{ raw_spin_lock(&lock->rlock);
}
#define raw_spin_lock(lock) _raw_spin_lock(lock)

#define _raw_spin_lock(lock) __LOCK(lock)

#define __LOCK(lock) \
do { preempt_disable(); __acquire(lock); (void)(lock); } while (0)

在上边的定义中发现, 在一进入到锁的情况下, 是先关抢占, 再进行忙等的, 所以认为上边所述的这个观点不正确, 也可能是版本存在的差异.

2. 在单CPU情况下, 关掉中断, 开内核抢占, 似乎也没有人可以打断当前内核的执行路径.
内核抢占点只有几个地方:

. 中断返回时
. 自动放弃CPU
. 异常/系统调用返回时
. 内核再次具有可抢占性的时候.

在上边的条件中, 1,3,4都不存在,2自己又不做, 所以认为内核的执行路径关掉中断, 也不会产
生抢占的可能性, 还请教大家论一论.

[小陆zi]

最近也在研究中断的事情。 谈谈个人看法，（可能不正确） 判断是否抢占的时候，一定是1234中情况之一。 除了2以外，其他的三种情况一定是判断是否需要抢占的环境。

[dyron]

引用 1 楼 edwardlulinux 的回复:

最近也在研究中断的事情。 谈谈个人看法，（可能不正确） 判断是否抢占的时候，一定是1234中情况之一。 除了2以外，其他的三种情况一定是判断是否需要抢占的环境。

你也认为单处理器系统中, 关掉中断, 就不会产生抢占了?

[猪头三小队长]

关掉中断，自己又不主动调度，schedule程序就没有机会执行了，当然就不存在抢占。

[猪头三小队长]

在没有中断没有抢占的情况下，竟态也就没有什么意义了（这样的情况下操作系统的调度没有办法可靠有效地进行，连操作系统都没有意义了），但是如果你只是短暂关闭就还是有竟态。

[jacob]

引用 楼主 dyron 的回复:

在上边的定义中发现, 在一进入到锁的情况下, 是先关抢占, 再进行忙等的, 所以认为上边所述的这个观点不正确, 也可能是版本存在的差异. 2. 在单CPU情况下, 关掉中断, 开内核抢占, 似乎也没有人可以打断当前内核的执行路径.

对单处理器中，自旋锁只针对一般的进程，关抢占之后其它一般进程都不可中断该进程，唯一可以中断该进程的是中断程序了。

[dyron]

抢占的四个时间点是否齐全 . 中断返回时 . 自动放弃CPU . 异常/系统调用返回时 . 内核再次具有可抢占性的时候. 如果齐全, 在单处理器中, 关了中断, 但并没有关抢占, 岂不是在内核调用锁,释放锁的时候 又具备抢占性时, 会发生抢占?

[小陆zi]

你也认为单处理器系统中, 关掉中断, 就不会产生抢占了? 我的回答是：关中断，也可能会有抢占。（有可能不对） 原因： 关闭中断，只是不再相应新的中断。否则中断会嵌套或者其他情况。但是在关闭中断的过程中，本判断的时机点肯定是在中断中，那么一定是在系统空间（调度发生的情况一定是在系统空间中），不会在用户层关闭中断，也不可能在用户空间中调用schedule这个函数主动让渡cpu。 举例： 假设现在在中断中，那么抢占又是另外个一个概念，中断返回之前ret to usr 会进一步去判断到底那个process的优先级高 那个process更加适合运行。如果发现了另外一个进程比现在这个进程更加适合运行，那么会switch to到那个更紧急的进程。 不知道我这么理解对吗，反正我是这样想的。 希望你给你帮助。

[小陆zi]

我完全同意你的这张假设。应为没有中断根本进入不了系统空间中，除非系统调用的时候，在ret from sys call的时候判断，但是要是没有中断的话，时间片也无法更新。因此也不会有抢占的说法。

[dyron]

引用 8 楼 edwardlulinux 的回复:

你也认为单处理器系统中, 关掉中断, 就不会产生抢占了? 我的回答是：关中断，也可能会有抢占。（有可能不对） 原因： 关闭中断，只是不再相应新的中断。否则中断会嵌套或者其他情况。但是在关闭中断的过程中，本判断的时机点肯定是在中断中，那么一定是在系统空间（调度发生的情况一定是在系统空间中），不会在用户层关闭中断，也不可能在用户空间中调用schedule这个函数主动让渡cpu。 举例： 假设现在在中断中，那么抢占又是另外个一个概念，中断返回之前ret to usr 会进一步去判断到底那个process的优先级高 那个process更加适合运行。如果发现了另外一个进程比现在这个进程更加适合运行，那么会switch to到那个更紧急的进程。 不知道我这么理解对吗，反正我是这样想的。 希望你给你帮助。

我有点懂你的意思了, 你是说如果关中断的动作在中断中, 那么中断返回的时候就有可能会产生 重新调度, 这种情况下只发生在内核抢占打开的情况下是吧. 如果关中断的动作不发生在中断中, 那么就算内核抢占打开,也不会发生抢占了. 我理解的对吗?