--- a/paper/datasegment.ind	Tue Aug 09 09:12:30 2011 +0900
+++ b/paper/datasegment.ind	Thu Aug 11 00:11:16 2011 +0900
@@ -11,15 +11,53 @@
 本論文では、今まので Cerium の構成と問題点を記述し、新しい TaskManager の設計
 方針を述べる。
 
+--Ceriumでの並列プログラミングの問題点
 
+Cerium では、ゲームプログラミング及び、sort や word count などの例題を書いたが、いくつかの問題点が明らかになっている。
 
+  Task の取り扱うデータ型が示されない
+  Task 自体は簡単だが Task を構成する方法が繁雑
+  Open CL に比べても構文的に複雑
+  Task の種類が複雑
+  Task の依存関係の記述がデータの依存関係と無関係
+  Task Scheduler が大きくメモリを圧迫
+  
+などである。実装方法的にもいくつか問題がある。
 
---Ceriumでの並列プログラミングの問題点
+  C++ と Task 記述の相性が良くない
+  Task Manager が複雑になりすぎ
+
+Task Scheduler は Queue からTaskを取り出して一つ一つパイプライン実行を行うインタプリタ的な構造を持っている。これが、Task Manager 自体を複雑にする原因になっている。
 
 --Continuation based C との相性
 
+当研究室で開発している Continuation based C は、並列処理の基本単位である Task に対応した code segment を持っている。これを Cerium に対応させようとすると以下のような問題がある。
+
+   Inteface の型が整合しないとTask同士を接続できない
+   Scheduler への接続が特定のInterfaceを要求する
+
+どちらも、Code segment の interface (入力と出力) は、決まった形であるべきだと言うことを示している。しかし、Task 自体は様々なデータを取り扱う必要がある。ここに矛盾がある。この矛盾を解決するためには、データ側も基本単位を導入するべきだいうことになる。
+
+Data Segment は、Code segment の双対概念であり、C の構造体に相当する。CbC の Code segment は、
+
+   input interface (関数の引数の型)
+   output interface (goto 文の引数の型)
+
+を持っているが、これらを
+
+   input datasegments
+   output datasegments
+
+に置き換える。つまり、Code segment は、複数の動的に割り当てられた Data segment を持っている。これらは、標準的な構造を持っているので、Interface の型の不整合を避けることができる。
+
+Data segment は型を持っていて、その型は実行時に一致している必要がある。分散通信を考えて、Data segment の型は MessagePack \cite{MessagePack} を用いる。
+
 --C++ との相性
 
+Cerium の Task は、Cell のspuとppuで共通であり、同じ Task ID で管理されている。これは C++ のオブジェクトとは関係ない。Cerium の開発でわかったのは、Cerium のデータは、Actor の become 的\cite{Act3} に書き換えられるということである。
+
+
+
 --Data Segment を用いた Cerium の再設計
 
 ---Data Segment の型