【问题标题】:How does linux synchronize preempt countlinux如何同步抢占计数
【发布时间】:2013-06-03 09:51:16
【问题描述】:

http://lxr.linux.no/linux+v2.6.35/include/linux/preempt.h#L21

我只是想获取 linux 源代码。我看到了这个抢占计数,linux如何确保抢占计数是原子的?代码只是增加值。

我还有一个问题。为什么中断句柄需要保持互斥。因为一次只能执行一个对吗?

此外,当中断被禁用时,操作系统会做什么?忽略中断或保持队列?

【问题讨论】:

    标签: c linux-kernel


    【解决方案1】:

    它递增preempt_count() - 注意() - 这是一个宏定义为:

    #define preempt_count() (current_thread_info()->preempt_count)
    

    所以它增加了一个每个线程的变量,它不需要任何锁定并且是安全的。


    最好将多个问题作为单独的问题提出,但要简短:

    • 中断处理程序通常可以被其他中断处理程序中断;
    • 中断处理程序可以在一个 CPU 内核上运行,而其他内核代码在另一个内核上运行;
    • 通常使用硬件机制禁用中断。这些往往会记住挂起的中断,但每个中断向量最多只能记住一个。

    【讨论】:

    • 非常感谢。请你也回答我的下一个问题。
    • @caf 和 mousey:如果故障处理程序或中断处理程序也调用 inc/dec,它是否安全?还是有什么规定说不能做?想法?
    • @minghua:不允许在中断上下文中访问它——无论如何这样做是没有意义的。
    • @caf:这也是我的理解。但是看看“netif_rx()”,最后它调用了“put_cpu()”,而后者又调用了“preempt_enable()”。此外,“spin_unlock_irqrestore()”通常用于中断处理程序,它确实增加了 preempt_count。我读的代码对吗?我正在查看何时启用 CONFIG_PREEMPT。
    • 环顾四周,我相信计数也是由故障处理程序和中断处理程序操作的。由于故障处理程序和中断处理程序在设计上是严格嵌套的,因此它们不会导致计数值损坏。中断上下文中的处理程序只使用当前线程的计数,只要在处理程序全部返回之前无法切换当前线程即可。鉴于此,读-修改-写操作并不是真正的原子操作。它保证在 R-M-W 完成后不会再发生上下文切换,直到配对“preempt_disable()”并且计数达到零。
    【解决方案2】:

    对 preempt_count 变量的操作不是原子的。线程的 preempt_count 的 inc 和 dec 之间的代码区域保证不会被调度程序切换出去。此代码区域中当前线程的上下文切换只能在进一步嵌入的异常或中断中发生。在第一个 inc 操作完成后,进一步的处理程序将看到变量非零,因此不会导致上下文切换。在 inc 完成之前,可以关闭线程,但这没关系,因为代码尚未到达受保护区域。

    一些细节:原子变量的定义应该类似于"Atomic variables are the ones on whom the read modify write operation is done as one instruction with out any interruption"。 preempt_count 上的“Read-Modify-Write”操作可以被另一个异常处理程序或中断处理程序中断,但只能以严格的嵌入式方式,即内核设计。由于这些嵌入式操作是成对的,因此 preempt_count 的值最终不会被破坏。尽管可以中断 R-M-W 操作并且可以切换出当前线程(仅当多个嵌入式 inc 均未完成时),但这没关系,因为代码尚未到达受保护区域。一旦线程切换回来,它将继续完成 R-M-W 操作,并且从那时起,当前线程将不会被切换出去,直到所有配对的 dec(s) 都完成。

    【讨论】:

      【解决方案3】:

      每个现代处理器都有一些原子test-and-set 指令的变体。

      【讨论】:

      • 检查来源。它不使用任何系统特定的指令。它只是增加
      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2013-11-13
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2018-09-16
      • 2014-08-25
      • 1970-01-01
      相关资源
      最近更新 更多