スレッドとファイバ

並列処理を実現するのにはWindowsではスレッドを作るのが一般的・・・というわけでもないので少し戦略的に考えてみる。

・ユーザがボタンを押して処理を実行し、その処理がすぐ終わる類のものはベタっとイベントハンドラを書けば良い
・処理がすぐ終わらないものについてはスレッド化しないといけない

ところが、スレッドを作成するといくつか問題がある
・同期の問題
　非同期処理にしないとスレッドを作る意味が無いが、データを共有するのにMutexなどで適切に動機を行う必要がある。
・効率の問題
　CPUの個数に依存する。まあそもそも大抵はスレッドは１つあれば足りるのであまりこれが問題になることはないと思うが。ゲームではかなり重要かも。
・効率の問題２
　タスクスケジューラがスレッドを切り替える事自体がかなりオーバーヘッドが高いので、並列処理させたいスレッド同士が独立性が高くない場合に切り替えコストが高くなる場合がある。
・効率の問題３
　スレッドとCPUの個数には密接な関係があり、特にCPUのキャッシュラインサイズを意識する必要がある

とスレッドを導入して効果を出そうとすると考えることは多い。
特に意識しないといけないのはメインスレッドとサブスレッドの関連性。特にゲームではメイン処理部分とサウンド処理であればかなり独立性は高いと思うが、メイン処理の一部にCPUのアルゴリズムだったりキー入力だったりがあったりした場合はかなり密結合になると思う。

でタスク切り替えのオーバーヘッドが少なくスレッドのように扱えるものとしてFibre、マイクロスレッドやコルーチンと呼ばれるものが数年前の流行り。

キーワードはyield。スレッドでは意図的に別のスレッドに所有権を渡したい場合はsleep(0)だが、Fibreの場合、実質的なスレッドは１つしかないので、自分の中でスレッド切り替えを明示的に行う必要がある。それがyield。yieldで別処理を行い、処理が終わるか途中の段階でまた所有権を戻してもらう。こうすることで、マルチスレッドのように見えていて実際はマルチスレッドではないFibreを実現する。

MSはちゃんとAPIでFibreを導入している。というか、大抵IT関係で話題があると、新しいWindowsにはこっそり導入されてたりする。
http://msdn.microsoft.com/en-us/library/ms682661%28VS.85%29.aspx

で、自分の場合は最初に書いたようにスレッド一個作れば足りるような仕事しかしていないので、これの使い道が無くちゃんと調べないでそのままだった。

また、Linuxの場合だとそもそもスレッドを作ること自体が皆無でforcになってしまうのか。Linuxのユーザランドでマルチスレッドの必要性があるものを作ったことがない。カーネルだと勝手にマルチスレッドになってしまっていたり、カーネルスレッド作るのがデフォだったりするので、自分で意識的にどうこうする必要もない。

ゲームだったりパフォーマンスが要求されるような場合で、スレッドを作ってみたけど無駄が多いなと思われるような場合に試してみようと思うがまずそういうことはないだろうｗ