【问题标题】:Do pthread_mutex_unlock immediate context switch?pthread_mutex_unlock 是否立即进行上下文切换?
【发布时间】:2015-11-15 19:34:08
【问题描述】:

在互斥体上调用pthread_mutex_unlock,另一个具有更高实时优先级的线程正在等待该互斥体。在这样的系统调用期间是否会进行上下文切换,或者线程只会在量子结束后被抢占? 如果在这种情况下不能保证立即进行上下文切换,那么在每个 pthread_mutex_unlock 之后立即调用 sched_yield 是否是个好主意?

【问题讨论】:

    标签: linux multithreading real-time


    【解决方案1】:

    在互斥体上调用 pthread_mutex_unlock,另一个具有更高实时优先级的线程正在等待该互斥体。是在这样的系统调用期间进行上下文切换,还是在量子结束后才抢占线程?

    通常,如果没有其他内核可用于运行更高优先级的线程,解锁线程将被抢占。

    如果在这种情况下不能保证立即进行上下文切换,那么在每个 pthread_mutex_unlock 之后立即调用 sched_yield 是否是个好主意?

    不能保证,也不可能。另一个线程可能还没有准备好运行。

    在 pthread_mutex_unlock 之后立即调用 sched_yield 是一个糟糕的主意。即使是低优先级线程也会通过缓存争用等事情损害高优先级线程的性能,因此通过不必要的额外上下文切换使低优先级线程效率低下会损害高优先级线程。

    如果没有损坏,请不要修复它。实施了解优先事项并会尽力而为。

    【讨论】:

    • 因此,当解锁线程将被抢占时 - 在从pthread_mutex_unlock 或更高版本返回之前(通过定时器 IRQ),如果只有一个具有更高实时优先级的准备运行线程正在等待对于那个互斥体和单核 CPU?
    • @Marik 您的实现将尽其所能。您没有使用实时操作系统,因此它不能对此类事情做出硬性保证。
    猜你喜欢
    • 2011-07-23
    • 1970-01-01
    • 2013-02-14
    • 1970-01-01
    • 1970-01-01
    • 2018-09-22
    • 2017-09-09
    • 2011-07-27
    相关资源
    最近更新 更多