質問内容
condition_variable を用いて キュー内の job をひらすら実行するロジックを実装したのですが
jobを追加する際に待ち状態となってしまう問題に遭遇しました。
下記のように condition_variable を用いて jobs キューからjobを取得し実行するロジックを実装しました。
c++
1キュー内のjobをひらすら実行するロジック (ワーカースレッドにて実行) 2while(1) { 3 unique_lock<mutex> mlock(mtx); 4 my_condition_variable.wait(mlock, [this] { return !this->jobs.empty(); }); 5 while (!jobs.empty()) { 6 Job job = move(jobs.front()); 7 job.work(); 8 jobs.pop(); 9 } 10}
jobを追加する関数は以下の通りです。
c++
1ジョブを追加するロジック (メインスレッドにて実行) 2void addJob(Job job) { 3 lock_guard<mutex> mlock(mtx); // <----- この行で待ち発生!! 4 jobs.push(job); 5 my_condition_variable.notify_all(); 6}
jobを追加する際に待ち状態になることは絶対にないと思ったのですが
実際にはaddJob関数内のlock_guardの行で待ちとなってしまいました。
調査したところ job を実行する側の while (!jobs.empty()) {...} のループから抜ける(実際には while(1) {...} の完了)まで待っているようでした。
unique_lockで取得したロックが解放されていないからだろうと思い、下記のようにunique_lockを中括弧 { } で囲こみ、中括弧から抜ける際に unique_lock のデストラクタが呼ばれてロックが解放されるのを期待して実装しました。
c++
1改修版:キュー内のjobをひらすら実行するロジック (ワーカースレッドにて実行) 2while(1) { 3 { 4 unique_lock<mutex> mlock(mtx); 5 my_condition_variable.wait(mlock, [this] { return !this->jobs.empty(); }); 6 } 7 while (!jobs.empty()) { 8 Job job = move(jobs.front()); 9 job.work(); 10 jobs.pop(); 11 } 12}
結果はビンゴでした。
ここで質問なのですがこのように中括弧にてロックが解放されるようにしても問題ないのでしょうか?
わざわざワーカースレッドを利用しているのはjobの処理を待ちたくないから利用しているのにjobを追加する際に待っていては本末転倒でして・・・。
今書いていて思ったのですが job キューの更新中に job が追加されることがあるので危険かもしれないですね・・・。
んー、解決策が分からないです。
よくあるケースだと思うのですがネットでは一歩踏み込んだ良い例が見つからずでして。
以上、どうぞよろしくお願いいたします。
回答1件
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2020/03/24 14:25