2

条件変数のスレッド ブロックを想像してください。

pthread_mutex_lock (mutex);
do_something ();
pthread_cond_wait(cond, mutex); // [1]
do_something_else ();
pthread_mutex_unlock (mutex);

ミューテックスがロック解除され、ミューテックスをロックしようとしている別のスレッドのブロックが解除されます。

pthread_mutex_lock (mutex);
do_some_work ();
pthread_cond_signal (cond);
pthread_mutex_unlock (mutex);

同時に、クリティカル セクションの所有権を取得するために待機している別のスレッドがあります。

pthread_mutex_lock (mutex); // [2]
do_some_random_work ();
pthread_mutex_unlock (mutex);

ここでの問題は、pthread_cond_signal() が呼び出されたとき、pthread_cond_wait() [1] が pthread_mutex_lock() [2] の前にブロック解除されることが保証されているかどうかです。

POSIX仕様は、ケースについて何も言っていないようです。

4

1 に答える 1

5

いいえ、ちがいます。

pthread_cond_signal() の説明は、次のように表現されることがあります。

pthread_cond_signal() または pthread_cond_broadcast() の結果としてブロック解除された各スレッドが、pthread_cond_wait() または pthread_cond_timedwait() への呼び出しから戻ると、スレッドは pthread_cond_wait() または pthread_cond_timedwait() を呼び出したミューテックスを所有します。ブロックされていないスレッドは、スケジューリング ポリシー (該当する場合) に従って、それぞれが pthread_mutex_lock() を呼び出したかのように、mutex を求めて競合します。

（このリンクから取得）

ご覧のとおり、「あたかもそれぞれが pthread_mutex_lock() を呼び出したかのように」という表現になっています。したがって、別のスレッドからの実際の pthread_mutex_lock 呼び出しと比較して、この暗黙の pthread_mutex_lock 呼び出しの優先度はありません。

于 2012-10-03T15:55:22.090 に答える