[linux][pthread]pthread_cond_wait()を勘違いしていた (2)

前回、けっこうがんばったつもりだったので、このタイトルで2回目の記事は書きたくなかった。。。
つまり、まだあれではダメだった、ということだ。

前回の一番最後の図で、左側に要求を出すスレッドが2つ、右側に要求を処理するスレッドが1つあった。

1. 右側が先にmutex_lock()してcond_wait()によってロック解除
2. 左側がmutex_lock()して、リソースを書き換えてcond_signal()
3. 右側はcond_signal()を受けて動き出したいけど、内部でmutex_lock()をするため、左側がmutex_lock()していることにより動けない
4. 左側がmutex_unlock()
5. 右側が動き始める

こういうシナリオだった。

が、左側には要求を出すスレッドが複数あるので、こんなことが起きているようなのだ。

1. 右側が先にmutex_lock()してcond_wait()によってロック解除
2. 左側Aがmutex_lock()して、リソースを書き換えてcond_signal()
3. 左側Bがmutex_lock()して、動けない
4. 右側はcond_signal()を受けて動き出したいけど、内部でmutex_lock()をするため、左側Aがmutex_lock()していることにより動けない
5. 左側Aがmutex_unlock()
6. 左側Bが動き始めて、左側Aが書き換えたリソースを上書きしてしまう

たぶん、こうなっている。
はぁ。

---

この記事の真ん中から下にも書いてあるが、順番に処理したいならキューイングするしかなかろう。
(まったく読んでなかった。。。)

IBM: 一般的なスレッド: POSIX スレッドの説明: 第3回

やりたいことは異なるのでソースをまねするかは分からないけど、キューイングみたいなことはいるな。

リンク先のworkcrew.cで、L.49でmutex_unlock()、L.53でmutex_lock()しているけど、これはいるんだろうか？
cond_wait()を抜けたときには内部でmutex_lock()して、cond_wait()を呼ぶときには内部でmutex_unlock()されるということだったので、私のコードからは削除したのだ。

全体で何をやっているコードなのか見ていないので何とも言えんな。
隙を見せる(一瞬unlockする)ことで、何か利点があるのかもしれん。