QThreadを使った複数スレッド間の通信について

Question

Qtを使ったマルチスレッドでスレッド間通信を
QThreadとSIGNAL/SLOTを用いて実装しようと考えていました。

SIGNAL/SLOTを使えば
threadAから発信されたSIGNALを
threadBでSLOTする？ということができるのは理解できました。

ただ、connectする際にSINGNALの送信元を指定する必要があるため
どこからともなく送られてきたとあるSIGNALに対してSLOTの処理をする
というような処理ができないような気がします。

スレッドが2つ、3つとかならいいですが
それ以上になるとそれぞれのインスタンスを持つ事に抵抗があります
それを避けるにはスレッド生成時に親スレッドの方でconnectを行う

また、送信元を指定せずにSIGNALとSLOTだけを自身で紐付けして
どこからか発信されたSIGNALを受信したら処理をするような動きをしたい場合
0. SIGNALの発信を行う専用のクラスを作成してシグナルの送信元はそれだけに絞る
0. もうSIGNAL/SLOTは捨てて、別でメッセージキューを実装する

というぐらいしか思いつきませんでした。

一般的にはどのような実装方法になるのでしょうか？
根本的に勘違いしている部分もあるかもしれませんが
是非、回答よろしくお願いいたします。

Answer 1

こんにちは。

signalは他のクラスへ処理を依頼した時の応答を受け取る際に使うことが多いように思います。
この場合は、処理の依頼先のクラスが当該signalをemitし、依頼元でそのsignalをconnectしておきますね。
つまり、signalはsignalを定義しているクラス自身が emit することがほとんどのように感じます。

さて、「クラスAがクラスBのsignalをemitしてはいけないのか？」は、恐らく良いだろうと予想しています。
しかし、Qtのsignal/slotの実装上ダメかもしれません。その場合はクラスBに当該signalをemitするだけの関数を設けて、それをクラスAから呼び出すことが考えられます。
後者がダメな理由はないように思います。（要求を処理する際に普通に使いますし。）

一般的にはどのような実装方法になるのでしょうか？

任意のクラスが特定のクラスのsignalを直接emitするようなコードはあまり一般的ではない印象です。
これは応答を受け取るのではなく要求を投げる場面でしょうから、上述した後者の実装をするケースが多いだろうと思います。

Comments

[tuyudaku]

>処理の依頼先のクラスが当該signalをemitし、依頼元でそのsignalをconnectしておきますね。
>つまり、signalはsignalを定義しているクラス自身が emit することがほとんどのように感じます。
根本的に考え方が間違っていたきがします...
今一度調べて整理します...

コメントを書いていたらこんがらがってしまったので
１つだけ質問させてください...

例えば
中央処理スレッド、センサー監視スレッド、画面制御スレッド、スピーカースレッド
というような構成で、中央処理スレッドが他のスレッドの親となり
センサーでONが検知されたら「ONしたよ！」という情報を中央に送り
画面の切替が必要なら画面制御スレッドへ、それと同時に音を鳴らすならスピーカースレッドへも
処理の要求を非同期で行うように
かならず中央を一度経由するような処理の流れの場合

signal/slotでの実装は向いていると思いますか？

[Chironian]

普通にできると思います。
そのケースの場合私なら次のように構築することもあると思います。

・センサー・スレッド・クラスにsenser_onシグナルを用意し、中央スレッド・クラスは自身のslotにsensor_onをconnectします。
・画面制御スレッド・クラスはswitch_window_signalとswitch_window_slotを持ち、コンストラクタでconnectしておきます。中央スレッドは必要に応じて画面制御スレッド・クラスのswich_window関数を呼び出し、switch_windowはswich_window_signalをemitします。

もしかすると、後者の実装は私独自かもしれませんが、どのスレッドから要求が来ても自分のスレッドで処理することになるので安心です。

私自身は、（スレッドのメリットをかなり殺すので）スレッドでイベント・ドリブンな実装はできるだけ行いたくなく上記のような構造はQtの場合に限られます。Qtは同期型の処理に対応していない（イベント・ループを回っていないと結果を受け取れない）ケースが多いので、moveToThreadを使ってイベント・ドリブンにしないと結構頭がいたいケースが少なくないのです。（何をやっているんだかと感じますが。）

[tuyudaku]

回答を頂いたり、調べるのを進めたをすればするほど
あれ・・・？と思うことが沢山出てきます...

std::threadなどを使用する場合、別スレッドで実行したい関数なりを渡している
何かを監視し続けるなどの処理をする場合は関数内で無限ループをして関数から抜けなくする
という実装になるかと思います

QThreadはQObjectを継承しているクラスからmoveToThreadで
QThreadに渡して、startをする。という実装になると思いますが(もしくはQThreadを継承)
startというのはつまりイベントループを開始するという考えでいいのですよね？
このままでは、ただイベントループが別のスレッドでたっただけ?

QThreadで監視をし続ける(ループし続ける)という処理をしたい場合
監視し続ける関数をコールするslotを子で準備して
親の方からそのsignalを発信、もしくはChironianさん流のsignalを発信する子の関数をコールする
という感じになるのでしょうか...

そうなると
それQThreadでやる意味在るの？
となりそうですが...

[Chironian]

> startというのはつまりイベントループを開始するという考えでいいのですよね？
> このままでは、ただイベントループが別のスレッドでたっただけ?

そういうことになります。

> QThreadで監視をし続ける(ループし続ける)という処理をしたい場合

その「監視」対象がどのようなイベントを発行できるのか？で結構変わってきます。
①コールバック関数を呼ぶタイプなら大抵のことができます。
②特定の同期オブジェクトを発火させるタイプなら、signalでslotを起動し、その中で同期オブジェクト待ちするのも手でしょう。ただし、その間イベント・ループを回っていないので、なかなか悩ましいです。
③特定のメモリの値を監視するなどしかないなら、ポーリングするしかないですね。
メイン・スレッドでインターバルタイマで監視する方法も考えられます。

結局、スレッドでどんな処理を行うかが問題です。単にイベント監視だけなら②のケースを除きスレッドを起こす必要はないと思います。（②についてはstd:thread等を使って監視ループを回して、signalを叩かせるのが良いと思います。）

複数のイベントが絡み合うような複雑なシーケンス制御を行うなら、スレッドで行うのは妥当です。
ですが、その際に非同期応答を受け取るのが非常に面倒です。非同期処理を同期処理化するための専用のクラスを作って対策しました。（本末転倒っぽく感じるので嫌なのですが。）

[tuyudaku]

あれから、もう一度調べなおして
Chironianさんの回答を参考にぼんやりと理解をし始めて
何とか形にすることができました
ありがとうございます。

まだ、細かい部分は曖昧のまま作っているので
また何度かQThreadに関しての質問をさせてもらうかもしれません
その際はよろしくお願いいたします。