1

pthread_cond_wait関数とpthread_cond_signal関数について疑問があります。マニュアルページも読んだ後、理解できませんでした。

次のコードを検討してください。

void* thread_handler(){
... // counts till COUNT_LIMIT is reached
if (count == COUNT_LIMIT) {
  pthread_cond_signal(&count_threshold_cv);
  printf("inc_count(): thread %ld, count = %d  Threshold reached.\n",
         my_id, count);
}
printf("inc_count(): thread %ld, count = %d, unlocking mutex\n",
       my_id, count);
...
}

void* thread_handler1(){
... // waits till the previous thread has finished counting
pthread_mutex_lock(&count_mutex);
while (count<COUNT_LIMIT) {
   pthread_cond_wait(&count_threshold_cv, &count_mutex);
   printf("watch_count(): thread %ld Condition signal received.\n", my_id);
}
pthread_mutex_unlock(&count_mutex);
pthread_exit(NULL);
}

コードは期待どおりに機能しています。私はコードを理解しようとしています。プログラムの仕組みは次のとおりです

  1. thread_handler1と入力し、cond_waitを実行します。マニュアルページから、cond_waitがすぐにロックをアトミックに解放することがわかりました。では、なぜ彼らはthread_handler1で再びロックを解除するのですか？

  2. 最初のスレッドが条件を満たし、条件信号に達した後、ブロックしていたスレッドがそのステップを実行することを期待しました。代わりに、cond_signalを実行したスレッドの下にprintfsを取得しました。なぜこうなった

  3. 全体として、待機して信号を送る前にロックをかける必要があるのはなぜですか。これをロックなしで行うことはできません。

プログラムの概要については、こちらの完全なプログラムをご覧ください。これは、「条件変数の使用」セクションにあります。

前もって感謝します

チダンバラム

4

1 に答える 1

2

thread_handler1と入力し、cond_waitを実行します。マニュアルページから、cond_waitがすぐにロックをアトミックに解放することがわかりました。では、なぜ彼らはthread_handler1で再びロックを解除するのですか？

待機することになっているスレッドは、呼び出し時にロックを解放しますwaitが、シグナルが送信された後（使用可能になったとき）に再取得するためです。そのため、後で明示的に再リリースする必要があります。

最初のスレッドが条件を満たし、条件信号に達した後、ブロックしていたスレッドがそのステップを実行することを期待しました。代わりに、cond_signalを実行したスレッドの下にprintfsを取得しました。なぜこうなった

呼び出しsignalはCPUからスレッドを切り替えないためです。引き続き正常に動作します。

于 2012-10-26T13:02:44.430 に答える