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内核会在内核代码持有自旋锁时禁用内核抢占?
解决方法 你的第一个问题的答案是你的第二个问题背后的原因.内核获取的自旋锁可以通过关闭抢占来实现,因为这可以确保内核在没有其他进程干扰的情况下完成其关键部分.整个问题是,在内核释放锁之前,另一个进程将无法运行.
没有理由必须以这种方式实施;它只是一种实现它的简单方法,可以防止任何进程在内核持有的锁上旋转.但是这个技巧只适用于内核获得锁定的情况:用户进程无法关闭抢占,如果内核正在旋转(即它试图获取自旋锁,但另一个进程已经拥有它),最好先放弃抢占上!否则系统将挂起,因为内核正在等待一个不会被释放的锁,因为持有它的进程无法释放它.
内核获取自旋锁是一种特殊情况.如果用户级程序获取螺旋锁,则不会禁用抢占.
总结以上是内存溢出为你收集整理的为什么linux在内核代码持有自旋锁后禁用内核抢占?全部内容,希望文章能够帮你解决为什么linux在内核代码持有自旋锁后禁用内核抢占?所遇到的程序开发问题。
如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)