【问题标题】:Purpose of wake_up_sync/wake_up_interruptible_sync in the Linux kernelLinux内核中wake_up_sync/wake_up_interruptible_sync的用途
【发布时间】:2013-04-24 20:23:55
【问题描述】:

我正在关注Linux Device Drivers 3rd Edition 书中的一个示例:

if (temp =  = 0)
    wake_up_interruptible_sync(&scull_w_wait); /* awake other uid's */
return 0;

作者说:

这里是调用wake_up_interruptible_sync 有意义的示例。当我们这样做 唤醒,我们正要返回用户空间,这是一个自然的调度 系统的点。当我们进行唤醒时,它不会潜在地重新安排,而是 最好只调用“同步”版本并完成我们的工作。

我不明白为什么在这种情况下使用 wake_up_interruptible_sync 会更好。作者暗示这个调用将阻止重新调度——它确实在调用中阻止了——但是在wake_up_interruptible_sync返回之后,另一个线程不能在return 0行之前控制CPU吗?

如果线程在每次调用后都可以控制 CPU,那么调用 wake_up_interruptible_sync 与典型的 wake_up_interruptible 有什么区别?

【问题讨论】:

    标签: c linux multithreading linux-kernel linux-device-driver


    【解决方案1】:

    使用_sync 的原因是我们知道调度器会在短时间内运行,所以我们不需要再次运行它。 然而,这只是一个优化;如果调度器确实再次运行,则不会发生任何不好的事情。

    定时器中断确实可以在任何时候发生,但只有当调度程序最近由于某些其他原因没有运行时才需要它。

    【讨论】:

    • 那么reschedule是在wake_up函数内部调用的,也是在函数返回之后调用的?
    • 不是在任何函数返回后,返回用户空间时。
    • 我明白了,所以我们不想在wake_up 函数中调用reschedule,因为无论如何都会在返回用户空间时调用它。通过在wake_up_sync 中延迟它,我们有机会在进入睡眠之前完成线程,从而释放该线程持有的资源;即使线程仍然可能最终进入休眠状态,我们通过延迟reschedule 调用来增加它不会休眠的机会。我现在的推理正确吗?
    • (SO 不允许 cmets 像“yes”一样短。)
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2012-06-23
    • 2017-04-08
    • 1970-01-01
    • 2017-09-19
    • 2014-09-26
    • 2011-07-31
    • 1970-01-01
    相关资源
    最近更新 更多