スレッド(コンピュータ)について その1

| コメント(0) | トラックバック(0) このエントリーを含むはてなブックマーク

Future Technology Days の Windows Azure に参加してきた。
この時 WebRole と WorkerRole という言葉を知ることになった。

この言葉を聞いていて思った事があったので、書いてみます。
(注意:完結していません)

 

Future Technology Days の Windows Azure のセッションの説明では、各Roleとも1つのVMに割当てられると伺った。また各ロールの中でスレッドを生成するなどが出来ないことを聞いた記憶がある。
とすると、各RoleとVMが(今の時点では)1対1の割り当てとなっているようである(将来にどのようにマッピングされるかは不明であるが)(むかしスレッドにM:Nモデルが存在したが(今も存在するか)このような考え方で Role と VMのマッピングされる日がくるのだろうか。)

この時VMを物理マシンとして考えた際、歴史が繰り返されていると思われたので、記載しておく。


今日、マルチスレッドに対応していないという環境は稀であると考える。
ここで、以降の話で出てくるスレッドやプロセスについての、定義をしておく。
これは、Wikipedia の スレッド(コンピュータ) を参照しつつ以下のように勝手に定義しておく。

  • スレッド:実行コンテキスト CPU状態やスタック領域を保持する物
  • プロセス:スレッドとそのスレッドが動作するメモリ空間などを含むリソースの保護単位

このように考えていくと、実マシンというのは、複数のプロセスが動作する物となる。
仮想マシンとは1つの実マシンの中に、あたかも独立した複数の実マシンがあるかのようにふるまったものであるとすると。


この定義をもって、Azureの処理単位について考えてみる。各ロールが1対1でVMに張り付くという事は、あたかも各ロールはシングルプロセス、シングルスレッドのパラダイムで動作しているように感じられる。(いわゆるMS-DOSとかがそれに近かったような気がする)
もちろん、各ロールはストレージを用いて疎結合で通信をするため、自由度はあると感じる。

このスタイルを考えるとロールは実行コンテキストのみと強い結合をしているように見え、しかも
実行コンテキストは、以下のシーケンスで繰り返されれていると考えられる。
1.要求を待つ(ブロックする)
2.要求が来たら、その要求を処理する
3.要求が完了したら、次の要求を待つ

このシーケンスは、実際のコードに強い制約(自由を奪うという意味で)を課すが、結果的にスケールアウト/アップの可能性を上げていると考える。
(もちろん Webアプリケーションも上記シーケンスの縛りを持つため、あまり強い制約ではないように感じるが)

最後に
言いたいこととしては、スケールアウトなどを検討していく上で、現状の複雑なプロセス/スレッドモデルではなくシンプルなモデルが採用されている。

(続きます)

トラックバック(0)

トラックバックURL: http://www.m-tea.info/mt-tb.cgi/4

コメントする

あわせて読みたいブログパーツ

このブログ記事について

このページは、k1ha410が2009年10月14日 22:38に書いたブログ記事です。

ひとつ前のブログ記事は「購入予定書籍」です。

次のブログ記事は「Rubyのスレッド」です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。