Software Engineering Lecture s10
Menu Menu
オブジェクトの並列実行
サーバフロントエンドとデータベース
本当のネットワークアプリケーションは、自分でネットワーク接続を管理する必要がある。ここで良く使われるのはサーバクライアントと呼ばれるモデルである。サーバクライアントにもいくつか種類がある。 一つ一つの処理をサーバ逐次に行っていく方法では、クライアントを待たせる必要がある。 サーバがクライアントに対応したslave serverを立ち上げれば、データベースのアクセス競合がないかぎり、サービスは平行に行うことができる。どちらの方法にせよ、このモデルではサーバが必ずネックになる。これをさけるためには、サーバをなくし、それぞれのネットワーク・エージェントが独立に通信すれば良い。 しかし、この方法は、全体の整合性を維持する方法が難しい。それぞれのエージェントが自分のサーバとなるような方法、仮想的なリングを構成する方法、投票により全体の状態を統合する方法、などが使われている。
分散プログラミングにおける通信
ネットワーク上の通信は、ストリームなどの原始的な通信を使うこともできるが、いくつかのより高度な方法が提供されている。- Remote Procedure Call
- Tuple 通信
- 分散オブジェクト
Remote Procedure Call
RPC は、手続き呼び出しと同じ形式で、他のサイトのプログラムを呼び出す。RPC には同期と非同期がある。非同期は、call backにより答を返す。
Tuple通信
Linda とは、並列通信プログラミング手法の1つで、タプルと呼ばれるデータを交換する事により通信を行う。タプルは、サーバーに蓄えられ、 id によってアクセスする。サーバーにタプルを出し入れすることにより、複数のクライアントから通信する事ができる。
out(id, data);データをサーバに書き出すのに使う。
in(id) rd(id) ck(id);これらはサーバのデータを受け取るときに使う。まず、in/rd/ ck のどれかで、どのidのデータを受け取るかを指示する。データが来ていればデータを返す。rd は読み込んでもデータをサーバがから削除しない。ckの場合は、データが来ても、それはタプルがないことを示す空文字列の場合がある。
平行オブジェクト
平行オブジェクトでは、3種類のメッセージ送信がある。ACTORと呼ばれる平行オブジェクトは、オブジェクトをモニタとして扱う。つまり、オブジェクトの中には一回に一つのactivityしか存在できない。
この制限は、再帰呼出しなどの場合は若干きつすぎる。これの解決には様々な方法がある。
呼出しのプライオリティを付ける方法 オブジェクトの変更を名前付けだけに許すことにして、 自分自身の呼出しの際には、新しい名前を作る。Javaなどでは、平行実行とオブジェクトは独立。
整合性 (Consistency)
プログラムの状態が、特定の時点で、指定されたある条件を満たすことを整合性があるという。(OSおよびDatabaseの授業を参照せよ)並行実行を行うと、一般的には整合性を持たせることができない。一般的な整合性は、並行実行の全てのアクション(トランザクション)が、そのアクションを逐次実行したものと同等であることが必要である(整列可能性)。
整合性 = 整列可能性整列可能性を満たすためには、以下のような手法が必要となる。
ある同一地点で、トランザクションの順序を規定するこのためには、ロック、または、メッセージを単一のオブジェクトで受ける必要がある。
特殊な条件であれば、整列可能性が必要でない場合もある。分散共有メモリなどでは、その効率を維持するために、整列可能性を緩める場合がある。
デッドロック
並行オブジェクト同士が、互いのメッセージを待ち合う状況。デッドロックをなくすようにプログラムするか、デッドロックの検出器を作成する。前者は、それほど難しくない。後者は、検出すべきオブジェクトが停止しているので、やっかいな場合がある。
ここにでてきたすべての通信方法は、なんらかの「待ち」状況を持つので、デッドロックの可能性がある。
Scala と並行実行
IBMのScala の入門が良いようです。これだと、最初の方しかでない。
ちょっと例題が少し古いので動かなかったりするんですが...
Eclipse 用の Scala Plugin
http://www.scala-lang.org/scala-eclipse-plugin