2018/11/30

[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する)ことで、何か利点があるのかもしれん。

0 件のコメント:

コメントを投稿

コメントありがとうございます。
スパムかもしれない、と私が思ったら、
申し訳ないですが勝手に削除することもあります。

注: コメントを投稿できるのは、このブログのメンバーだけです。