少し気になったこと

アバター
tk-xleader
記事: 158
登録日時: 13年前
連絡を取る:

少し気になったこと

投稿記事 by tk-xleader » 1年前

少し前のこの質問について...
本筋から離れるので日記で。

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を指定している以上、これも仕方はないのかもしれませんが...

アバター
usao
記事: 1887
登録日時: 11年前

Re: 少し気になったこと

投稿記事 by usao » 1年前

純粋な疑問ですが,

> 複数スレッドの同時join

というのができると,(forでjoinするのと比較して)何かが変わってくるのでしょうか?

アバター
tk-xleader
記事: 158
登録日時: 13年前
連絡を取る:

Re: 少し気になったこと

投稿記事 by tk-xleader » 1年前

usao さんが書きました:
1年前
純粋な疑問ですが,

> 複数スレッドの同時join

というのができると,(forでjoinするのと比較して)何かが変わってくるのでしょうか?
 環境にもよりますが、複数のスレッドの終了を1回のAPIコールで待機できて、その方が1つ1つのスレッドを個別に待機するよりも効率がよい実装であれば、複数スレッドの同時joinができることには意味がありそうです。
 例えば、Windowsであれば、WaitForMultipleObjects APIで、効率的かどうかについては未検証ですが、複数スレッドの同時待機ができます。

アバター
usao
記事: 1887
登録日時: 11年前

Re: 少し気になったこと

投稿記事 by usao » 1年前

> forでjoin

だと,各joinの間に「次をjoin」のための処理がちまちま挟まるのが効率悪い,みたいな話ですか.
「本当の意味で一括で待つ」ができるならばそっちが良い,と.

アバター
usao
記事: 1887
登録日時: 11年前

Re: 少し気になったこと

投稿記事 by usao » 1年前

あとは,そういった(特に,環境に依存しそうな)具体実装詳細はAPIの向こう側でやってくれると良い,っていう.

アバター
tk-xleader
記事: 158
登録日時: 13年前
連絡を取る:

Re: 少し気になったこと

投稿記事 by tk-xleader » 1年前

>usaoさん

 usaoさんのおっしゃる通りのことをつらつらと考えておりました。
 なお、boost::thread_groupの実装を見ると、threadオブジェクトをstd::listで管理していて、join_allはforループでlistに入っているthreadを順次joinしているので、boostを使う限りは、std::vectorでthreadを管理する方が効率が良さそうですね。