少し前のこの質問について...
本筋から離れるので日記で。
viewtopic.php?f=3&t=21433
(1) vectorで多数joinすることについて
boost::threadであれば確か複数スレッドの同時joinをすることができるはずなんですが、C++標準だとできないんですよね。何か理由があるのでしょうか…?
(2) 多数のthreadを作るよりも...
おそらく、質問者さんは例えとして1000という数字を出したと思うのですが、1000個のスレッドを同時起動するというのはかなり重たくなりそう...(メモリだけ見ても、1スレッドあたりのスタックサイズが1MiBとすると約1GiBくらい?の消費ですし)
質問者さんのやりたいことを推察するに、threadpool を使って、そこにぽんぽん処理を投げた方が効率は良さげですね...
ただこれも、現在のC++標準ではthreadpoolが用意されていないので、C++20を指定している以上、これも仕方はないのかもしれませんが...
少し気になったこと
Re: 少し気になったこと
純粋な疑問ですが,
> 複数スレッドの同時join
というのができると,(forでjoinするのと比較して)何かが変わってくるのでしょうか?
> 複数スレッドの同時join
というのができると,(forでjoinするのと比較して)何かが変わってくるのでしょうか?
- tk-xleader
- 記事: 158
- 登録日時: 13年前
- 連絡を取る:
Re: 少し気になったこと
環境にもよりますが、複数のスレッドの終了を1回のAPIコールで待機できて、その方が1つ1つのスレッドを個別に待機するよりも効率がよい実装であれば、複数スレッドの同時joinができることには意味がありそうです。
例えば、Windowsであれば、WaitForMultipleObjects APIで、効率的かどうかについては未検証ですが、複数スレッドの同時待機ができます。
Re: 少し気になったこと
> forでjoin
だと,各joinの間に「次をjoin」のための処理がちまちま挟まるのが効率悪い,みたいな話ですか.
「本当の意味で一括で待つ」ができるならばそっちが良い,と.
だと,各joinの間に「次をjoin」のための処理がちまちま挟まるのが効率悪い,みたいな話ですか.
「本当の意味で一括で待つ」ができるならばそっちが良い,と.
Re: 少し気になったこと
あとは,そういった(特に,環境に依存しそうな)具体実装詳細はAPIの向こう側でやってくれると良い,っていう.
- tk-xleader
- 記事: 158
- 登録日時: 13年前
- 連絡を取る:
Re: 少し気になったこと
>usaoさん
usaoさんのおっしゃる通りのことをつらつらと考えておりました。
なお、boost::thread_groupの実装を見ると、threadオブジェクトをstd::listで管理していて、join_allはforループでlistに入っているthreadを順次joinしているので、boostを使う限りは、std::vectorでthreadを管理する方が効率が良さそうですね。
usaoさんのおっしゃる通りのことをつらつらと考えておりました。
なお、boost::thread_groupの実装を見ると、threadオブジェクトをstd::listで管理していて、join_allはforループでlistに入っているthreadを順次joinしているので、boostを使う限りは、std::vectorでthreadを管理する方が効率が良さそうですね。