--- a/problem.tex	Mon Apr 01 01:52:11 2013 +0900
+++ b/problem.tex	Mon Apr 01 18:44:41 2013 +0900
@@ -4,15 +4,16 @@
 特に実行速度の問題では分散環境をテストする例題として作成されたRingの例題(トポロジーを円状に構成し、メッセージが1周する時間を計測する)ではシングルスレッドで実装されているFederated Lindaに実行速度で及ばない。また、並列環境をテストする例題として作成したbitonic sortの例題も期待した結果を得ることができなかった。そこで、実行速度の改善を行うために、オーバーヘッドになっている原因の洗い出しを行った。その結果以下のような原因が見つかっている。
 
 {\bf HashMapの多用　} 
-AliceではData Segment Managerのマネージャーキーによる探索、Data Segmentのキーによる探索などHashMapを多用している。この検索かかる時間が多少ではあるが、オーバーヘッドになっているものと考えられる。
+AliceではData Segment Managerのマネージャーキーによる探索、Data Segmentのキーによる探索などHashMapを多用している。この探索を行う際に排他制御を行うためかかる時間が多少ではあるが、オーバーヘッドになっていると予想される。
 
 
 {\bf Message Packの convert / unconvert　} 
-現在の実装ではputまたはupdateを呼ぶとMessage PackによりValue型へと変換が行われている。また、Code Segment内でValue型から変換元の型への変換が行われる。
+現在の実装ではputまたはupdateを呼ぶとMessage PackによりValue型へと変換が行われている。また、peek,takeで取得したData Segmentに対してCode Segment内でValue型から変換元の型への変換を行う必要がある。
 この作業もオーバーヘッドになる。また、配列の要素数が増えると変換に時間が多くかかるので、この作業はできるだけ避けたい。
 
 {\bf SEDA Architecture　} 
-Federated Lindaに比べて、通信のレスポンスが遅い原因にはSEDA Architectureが挙げられる。SEDA とはマルチコアスレッドを用いて大量の接続を管理し、受け取ったデータを処理ごとに分けられたステージと呼ばれるスレッドに投げ、処理が終わると次のステージにデータを伝搬させて行く処理方式である。しかし、SEDAはスループット重視の実装であり、レスポンス重視ではない。逆に多段のパイプラインのせいでレスポンスは遅れてしまう。また、非力なマシーンではSEDAの効果を得られず、スレッドを切り替える等の時間もオーバーヘッドになってしまう。
+Federated Lindaに比べて、通信のレスポンスが遅い原因にはSEDA Architectureが挙げられる。SEDA とはマルチコアスレッドを用いて大量の接続を管理し、受け取ったデータを処理ごとに分けられたステージと呼ばれるスレッドに投げ、処理が終わると次のステージにデータを伝搬させて行く処理方式である。しかし、SEDAはスループット重視の実装であり、レスポンス重視ではない。逆に多段のパイプラインのせいでレスポンスは遅れてしまう。また、データを次のステージへ伝搬させていく際にLinkedBlockingQueueを使用しているがenqueue時、dequeue時にロックを掛けるのでオーバーヘッドの原因と思われる。LinkedBlockingQueueは片方向の連結リストをベースとしたQueue実装である。enqueue / dequeueの操作時の排他制御にはそれぞれ別々のロックオブジェクトが使用されている。そのため、enqueueとdequeueが重なってもロック解除待ちは発生しないが、そのかわりに連結リストのNodeオブジェクトの生成操作などが発生してしまうため、enqueue操作の処理コストが高い。
+さらに、非力なマシーンではSEDAの効果を得られず、スレッドを切り替えが頻繁に起こりオーバーヘッドになってしまう。
 
 {\bf Data Segmentの再構成　} 
 取得されたData Segmentに変更を行いKey Value Storeへ追加する際に、Output Data Segmentが毎回新しく作成される。そして、変更された値のコピーが行われる。