fork/joinフレームワークを勉強しようとして・・・ 断念した今日の

あまりにもGWが暇すぎて、一人さびしく昼間っから酒を飲むのもどうかと思ったので、

  1. 今遊びで作ってるhttpサーバに何か特徴的な実装を入れ込んでみよう
  2. 特徴的な実装かあ・・・ httpサーバと言えばいつもスレッドプール周りの設定で悩むなあ
  3. スレッドプールの数で悩まなくてもよい実装って作れるか?
  4. そもそも、1リクエスト処理が1スレッドを占有するからイケないんじゃね?
  5. 複数のリクエストが一つのスレッドを共有する実装は可能か?
  6. いまどきのフレームワークは、スレッド占有な並列処理に依存しているから、トランザクションとかDBコネクションとか、実装がみんなこれに依存してるんだよなあ・・・
  7. そういえば、java7から新しい並列処理機構が出てたなあ
  8. fork/join、食わず嫌いしてたけど、ちょっと触ってみるか
  9. 触るのは良いけど、仕事で使えるかなあ・・・

などと考え事をした結果、前置きが長いのはいつものこととして、ふと「fork/joinフレームワークはSIの現場で使えるか」という思考実験を始めよう思ってみた。とは言うものの、そもそもfork/joinフレームワークをあまり知らないので、ちょっと調べ始めた。

さて、fork/joinフレームワーク、個人的には、次世代並列処理機構を担うフレームワークであるという触れ込みで、鳴り物入りで登場したような感がある。もしかしたら、単純に視野が狭くなっているだけかもしれないし、もしかしたら、本当にそれぐらいしかJDK7には何もなかっただけかもしれない。とはいえ、登場当時は、ネット上のいろいろなところで取り上げられていたような気がしなくもないので、さぞ素晴らしいものに違いはないだろうと、勝手に考えていた。

ところがいろいろ調べるうちに、あれと思うところがところどころ。

  1. クイックソートマージソートフィボナッチ数列ディレクトリ探査? おいおい、もうちっと、汎用性の高い良い例はないのか?
  2. 図が、4行ぐらいにぶつ切りの横長の箱が並んで、ほら効率的でしょ、ばかり。そりゃ、そう並べれば、そう見えるよね。
  3. スレッド数を増やすと、性能が上がるでしょ。でも、2スレッドにしたからって倍にはならないし、ある程度で限界になるよ。アプリケーションの種類によって違うよ。って、この手の記事を書く連中に一言、アムダールの法則で済む内容を、わざわざ1000文字とかっこい図を10枚使って説明するな。

こんなのばかり。(英語のサイトは知らない)ちょっと拍子抜けした。で、いろいろ調べてみたのだが、もしかしたら、本当にfork/joinしか出来ない、不器用な子なのかもしれない。もしそうなら、木構造再帰系の処理の高速化にしか使えなくね?

もう10年近く前に、細粒度並列処理機構のJavaでの実装に挑戦した身からすると、fork/joinフレームワークの何が素晴らしいって、限定された個数のスレッドで、それよりも多くの独立したコンテキスト(タスク、もしくは擬似的なスタックフレームっぽい何か)を処理出来ているということじゃないかと。
これが未熟な実装の場合、タスクごとにスレッドが発生する。forkでスレッドが生成され、joinで待ち合わせが行われる。
ところがfork/joinフレームワークでは、これがなぜか少数のスレッドで処理しきれているわけだ。どう実装しているのかが気になる。おそらく、forkでタスクをキューイングし、joinにて、キューイングされているタスクを起動していると予想される。

javaにはschemeのcall/ccのようなものがないので、ユーザレベルで、擬似的にマルチスレッドっぽいことを実装することは出来ない。なので、おそらく、ワーカースレッドは、FW制御→タスク実行→FW制御→タスク実行・・・といった具合に、再帰的にタスクが処理されているのだと予想してみた。
で、実際のところはどうかと思って、ソースを読み始めたら・・・

き、きたねえ。俺の部屋よりきたねえ。
何でしょう。とてもじゃないけど、読めたもんじゃない、何を目的にこんなコードになっているのか分からない、何とも言えない残念な気持ちになるコードは久しぶりです。正直、こうなるべくしてなったのか、それとも、書き手の問題なのか、5秒考えて分からなかったので諦めてしまった。

さて、暇つぶしに「fork/joinフレームワークはSIの現場で使えるか」という思考実験を行おうとし、十分に理解せぬまま、どころか、コードを何一つ書いてない状態で結論が出てしまった。結論は、使えるでも使えないでもない。結論は、「fork/joinフレームワークソースコードを1分眺めて、理解できなければ使うべきではない。理解できたとしても、そのシステムを一生お守するつもりがなければ、使うべきではない」だ。

なぜかって? トラブったら、どうにもならないから。