pthread_cond_wait での mutex

以下の様なサンプルプログラム（一部省略）があります。
bossスレッドが1秒ごとにworkerスレッドを起こして、workerスレッドは処理後、再び眠ります。

worker ()
{
while (...)
{
* pthread_mutex_lock(&g_lock);
pthread_cond_wait(&g_signal, &g_lock);
* pthread_mutex_unlock(&g_lock);
:
}
}

boss()
{
while (...)
{
wait( 1 );
* pthread_mutex_lock(&g_lock);
pthread_cond_signal(&g_signal)
* pthread_mutex_unlock(&g_lock);
}
}

waitで待機し、signalで起こされるのはわかるのですが、
mutexでロックしている意味がわかりません。
mutexが不必要な処理の場合、*部分はいらないのでしょうか？

No.2 ベストアンサー 回答者： tokichim 回答日時： 2008/06/19 01:22

> bossとworkerの同期が必要の無いシステムにおいてはmutexは不要という考えでいいのでしょうか？

workerのループ前にlockが一個必要ですが（pthread_cond_waitはunlockして待つのでその前準備として）、それ以外はたぶん不要ということでいいと思います。
たぶんと書いたのは全てのpthreadの実装で大丈夫かはわからないからです。

まあ、mutex操作の時間が惜しいほどシビアな処理でなければ、後々の処理追加の可能性や他人がそのソースを使う事も考えて、おまじない的に入れておいてもよいかと個人的には思います。

この回答へのお礼

度々のご回答ありがとうございます。

実はリアルタイム処理の実装を実現するために、限界まで高速なマルチ処理を考えています。
そのため、無駄なmutexは極力避けたないという背景があります。

pthreadの内部仕様を眺めて検討したいと思います。
ありがとうございました。

お礼日時：2008/06/19 09:02

No.1 回答者： tokichim 回答日時： 2008/06/17 17:35

結論からいうとmutexは必要です。

実は質問文のソースには潜在的なバグがあります。
pthread_cond_signal()は送信をキューイングしません。つまりその時点でwaitされてなかったら何も起こりません。
例えば、もしworker()の処理が1秒ほどかかったら、worker()がwaitする前にboss()がsignalを送ってしまうことになります。
その場合はworker()は次のsignalまでwaitしてしまうため、結果としてboss()のsignalを一回飛ばしてしまうことになります。

ですから、このへんをクリアした処理にするためには、「worker()が仕事をするべきフラグ」のような変数を導入し、boss()はsignalを送る前にそのフラグを立て、worker()はwaitに入る前にそのフラグを確認しなければなりません。
このフラグ変数は2つのスレッドから同時にアクセスされうる変数ですから、mutexで保護してやる必要があります。

これ以外にも同期をとる2つのスレッドの間ではたいてい何らかの情報共有をしているはずなので、それへアクセスするにもmutexの保護が必要です。

こういうことでmutexで保護することが一般的なのです。

この回答へのお礼

ご回答ありがとうございます。

signalの動きについてわかりやすい説明で理解できました。
一般的に同期を取るにはやはり必要なんですね。

一方で、私がこれから構築しようとしているシステムもそうなんですが、
bossとworkerの同期が必要の無いシステムにおいてはmutexは不要という考えでいいのでしょうか？
つまり、bossがシグナルを発したとき、workerがビジーなら無視されても構わないシステムであり、workerの処理はworker単体で完結します。

お礼日時：2008/06/18 17:46