pthread_cond_wait与signal

最新推荐文章于 2025-11-08 12:12:48 发布

转载最新推荐文章于 2025-11-08 12:12:48 发布 · 534 阅读

linux 专栏收录该内容

29 篇文章

订阅专栏

本文探讨了在某些平台上，当使用pthread条件变量时，如果在发送信号时保持互斥锁锁定可能会导致不必要的上下文切换。这种情况尤其发生在单处理器系统中。文章通过一个示例场景说明了这一问题，并解释了为什么这种做法可能导致额外的开销。

http://www.domaigne.com/blog/computing/condvars-signal-with-mutex-locked-or-not/

pthread_mutex_lock(&mutex);
predicate=true;
pthread_cond_signal(&cv);     // OR: pthread_mutex_unlock(&mutex);
pthread_mutex_unlock(&mutex); //   : pthread_cond_signal(&cv);

Signal with Mutex Locked

On some platforms, the OS performs a context switch to the woken thread right after the signal/broadcast operation, to minimize latency. On a single processor system, this may lead to unnecessary context switches if we signal or broadcast while holding the mutex.

signal with mutex locked

Fig 1- signal with mutex locked. We get 2 unnecessary context switch.

Indeed, consider the scenario shown in figure 1. The thread T₂ is blocked on the condition variable. T₁ signals the condition while holding the associated mutex. A context switch to T₂ occurs and T₂ wakes up. But before returning frompthread_cond_wait, T₂ needs to lock the mutex. However that mutex is already hold by T₁. As a result T₂ blocks (but this time contends for the mutex) and a context switch to T₁ occurs. Then T₁ unlocks the mutex, and T₂ becomes finally runnable. The situation appears to be even worse, if we broadcast the condition variable to several threads.