Ad Network

あわせて読みたい

  • あわせて読みたい

« 凍結した道には注意しよう | Main | 優秀な主婦はイベント・ドリブン(event-driven)方式でパンを焼く »

マルチ・スレッド(multi-thread)プログラミングの落とし穴、その1(かもしれない)

Snowman1 ここのところ技術系ブロガーの間で話題になっている、「C10K問題(参照1参照2)」は、ひとことで言えば、多くのウェブ・サーバーで採用されているmulti-threadやmulti-processに頼った(もしくは頼りすぎた)多重処理というアーキテクチャーのスケーラビリティに対する極めてまっとうな警告である。

 この話は、決して最近になって始まった話ではなく、パソコン業界ではパソコンのOSにpreemptiveなマルチタスクが導入されはじめた90年代の前半から、さらに遡ると、DECを中心にテクノロジーが進化したミニコンの時代から、ソフトウェア・エンジニアたちの間で盛んに討論されてきたテーマである(さすがに、メインフレーム時代の話は私は知らない)。

 十数年を経た今でも、いまだに決着が付いていないこの問題は、私の大好きなテーマの一つでもあるし、もし私が博士号をこれから取得しようとするのであれば、博士論文のテーマに最適だと思っている。この論争は、ある意味では、ミニコンから降りてきたmulti-threadを多用した多重処理を支持する一派と、16ビットパソコンの時代のnon pre-emptiveなOSの上で別の進化をしてきたasynchronous I/Oを利用した多重処理のアーキテクチャを支持する一派とのぶつかり合い、ということも出来るぐらい根が深いものだ。

 「単純化しすぎ」と批判されることを承知で、便宜上、前者を「multi-thread派」、後者を「asynchronous I/O派」と呼ぶことにする。両派の主張は以下のようなものである。

multi-thread派の主張

 人間は、一つの仕事を処理するときには、それを小さな仕事に分割して、順番に処理する。それゆえ、プログラミングもそんな人間の頭の構造を反映して、呼びたいAPIを順番に羅列して行く「手続き型プログラミング」が適している。もちろん、APIによっては、ファイルIOやネットワークIOのように遅延を持つものもあるが、そこはプログラマーにはできるだけ意識させず、OS内部で自動的にcontext switchを行って、それによって多重処理を可能にすれば良い。せっかく、CPUやOSのレベルでmulti-thread、multi-processをサポートしているし、context-switchのコストは相対的にものすごく小さくなったのだから、それを最大限活用すべきである。

asynchronous I/O派の主張

 multi-threadを多用した「手続き型プログラミング」による多重処理は、一見とっつきやすく簡単に見えるが、実はシステムの安定性、保守性、スケーラビリティの面で色々と問題がある。複数のthread(もしくはprocess)で共有するリソースへのアクセスをシリアライズするためのクリティカル・セクションをアプリケーションレベルできちんと使いこなすことは容易ではないし、I/O待ちのthreadの数が莫大になった時にそれぞれのthreadのcontextを保つために必要なリソースが膨大になる。それに加え、APIによる遅延をプログラマーが意識しないというスタイルのプログラミングでは、そういったAPI呼び出しによる遅延をユーザーから隠してレスポンスの良いアプリケーションを作ることが難しくなる。それよりは、できるだけ少ない数のthreadで、遅延を持つI/Oはすべてasynchronous APIを使ったメッセージ・ドリブン(もしくはイベント・ドリブン)なプログラミングによる多重化の方が優れている。

 この二つのプログラミング・スタイルに関するディベートは、90年代前半にOSの設計に関わっていたMicrosoft、IBM、Appleなどの企業内部でさかんに行われ、GUI OS上でのthreadの使い方に関しては一応の決着を見たようにみえたが、それが90年代中ごろから、インターネットを介した数百msecという桁外れに大きなの遅延に向き合わなければならないWWWブラウザーやHTTPサーバーが出てきた時に、さらに別のディベートとさまざまな試行錯誤が行われながらも、今に至っても(業界のトップクラスのエンジニアたちの間ですら)まだ決着が付いていない、というのが実情である。

 たまたまnon-preemptive OS(Windows 3.1)、preemptive OS(Windows 95)、WWWブラウザー(Internet Explorer)、HTTPサーバー(IIS/Personal Web Server)の設計・開発のどれにも深く関わってきた私としては、さまざまな失敗と成功を通して、それなりのノウハウも蓄積してきたし、言いたいこともたくさんある。しかし、そういったことを全部書くと、一冊の本になりそうなぐらいの量になるし、思いっきりテクニカルになってしまってエンジニア以外の読者をこのブログから失ってしまいそうなので、ここで書き続けるべきか少し悩んでいる(ひょっとしたら、以前から試してみたかった自費出版向きのテーマかもしれない…1000部ぐらいならこのブログを通して売れそうだし^^)。とりあえず今日のところは、渡辺千賀さんの本のタイトル風に「その1(かもしれない)」とお茶を濁しておく。

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d8341c4f9853ef00d83510d3bc69e2

Listed below are links to weblogs that reference マルチ・スレッド(multi-thread)プログラミングの落とし穴、その1(かもしれない):

Comments

R

読みたいです! > async vs. multithread

lopes

買います++;

YAMACHAN

かいます。いくらくらいになりますか?

YAMACHAN

かいます。いくらくらいになりますか?

いつも見てる人

「その1」の続きはいつですか?

anonymous

ネタが古いな.両主張の衝突はP2P技術の適用で解消する見通しだ.だが遺物雑話は娯楽として認めたい.

taichi

続き、読みたいです。書籍なら、勿論買いたいです。

sho

続きも読みたいです。
他のネタと並行で書けばエンジニア以外の読者も離れないのではないでしょうか。

eakas

"日本語とオブジェクト指向"みたいなエンジニア以外の人にも理解可能な例えが随所で導入されていれば大丈夫かと思います。

もちろん他のネタと並行でも楽しく読ませて頂けるかと思います。

心は萌え

部分的に執筆します。
分け前下さい ++

心は萌え

ちなみに、私はハイブリッド派です。(w
条件に応じて、multi-threadとasynchronous I/Oを組み合わせながら、
multi-thread and asynchronous I/O combinateion というのを設計レベルで行っておくというのが最強かとー

とくにCore Duo / Quad / などなどなど スレッドが有効な場面も増えてきましたシー

Bak.

machのメッセージパッシングがスレッド間の通信として使えるので、オブジェクトは全て自動的に別スレッドになって、GUIイベントは全てオブジェクト間通信でメッセージパッシングとして処理されてるんだ、と勝手な解釈をしてた事に気付きました。
…そらそうやわな、スレッド使うのってコーディングする時に明示的に指定してやらんといかんし(Javaの場合)、MacOS9までだと下手したらToolBox関数いじるという話があったぐらいだもの。
Beってどうだったんだろう、とか気にしてみたり。

lisp

自費出版ってwwwwwww
凄く読みたいですが、せめて同人誌にしましょうよ、時期的にw

cyberoptic

自費出版であれば、オンデマンドで行きましょう!

今年リリースする弊社のサービスでは、
いわゆる「Web Top Publishing」をPhotoback( http://www.photobacl.jp/ )的UIで
実現する予定で、かつ、それを通じて作成したコンテンツを
手軽に流通・販売させることができますよ。
品切れ・絶版、在庫無し。改訂版を出すのも容易ですしね!

shige-zo

podcastingしてみてはいかがでしょう。で、本業に影響を与えずに出版を実現するには、その思想や理論を汲んだみなさんがtext writingすれば良いかな、と。参加した人は経済活動では得られない満足を得られるかもしれません。
知識創造・交換、netを通じた個の協業・・

BlueJewel

I've been watching for a while but now i'm making my first post.
I'm interested in getting some useful info, I hope this is the right place.
Looking to meet new people to exchange info with,so leave me your name
Peace,

Post a comment

This weblog only allows comments from registered users. To comment, please Sign In.