--- a/paper/io.tex	Mon Apr 21 14:53:36 2014 +0900
+++ b/paper/io.tex	Mon Apr 21 23:10:45 2014 +0900
@@ -1,10 +1,15 @@
 \section{並列処理向け I/O の設計と実装}
 
-従来は mmap や read でファイルの読み込みの実装を行っていた。
+I/Oを平行に行うには、従来の read loop を行うのでは
+read がプログラム全体を止めてしまう。
+もっとも簡単にreadを並行して行うには、file open の代わりに
+mmap を使う方法がある。mmap は直ぐにファイルを読みに行くのではなく、
+仮想メモリ空間にファイルの中身を対応させる。
+そのメモリ空間にアクセスに行くと、それに対応した部分のファイルをOSが見に行く。
+ファイルが読み込まれるまでは、アクセスしたスレッド/プロセスは、その場で待たされる。
+しかし、mmap は逐次アクセスを仮定しているので、OS内部で自動的にファイルの先読みを
+行うと期待される。
 
-mmap とは、sys/mman.h に含まれている関数で、ファイルの読み込み等に使用される関数である。
-ユーザ(プロセスの)メモリ空間にファイルのマッピングを行う UNIX のシステムコールであり、
-mmapした領域にアクセスされるときに、そのファイルが実メモリに展開される。
 
 \begin{tiny}
   \begin{table}[ht]
@@ -41,15 +46,18 @@
 flags にはメモリ確保する際のオプションを指定することができる。(表\ref{table:mmap})
 \fi
 
-mmap でファイルを読み込むタイミングは、mmap 関数が呼ばれたときではなく、mmap した領域に対して何らかのアクセスをしたときに初めてファイルが読み込まれる。
+% mmap でファイルを読み込むタイミングは、mmap 関数が呼ばれたときではなく、mmap した領域に対して何らかのアクセスをしたときに初めてファイルが読み込まれる。
 
 図\ref{fig:mmap}では、読み込んだファイルを分割して、それらの領域に何らかの処理を加えるときの図である。
 
 1個目の Task が実行されるときに初めてそれらの領域にファイルが読み込まれ、その後何らかの処理が行われ、そして Task 2 も同様に読み込みを行ってから処理が行われる。
-これら Task は並列に実行されるべきであるが、ファイル読み込みの I/O 部分がネックとなり、本来並列実行される Task が読み込み待ちを起こしてしまう恐れがある。
-さらに、読み込みが OS 依存となるために環境によって左右されやすく、プログラムの書き手が読み込みに関して制御しにくい。
+mmap の read は、Task と並列に実行されるべきであるが、それは OS の実装に依存する。実際、mmap のフラグのほとんどは実装されていない。
+読み込みの実行が、うまく並列に実行されなければ、Task が読み込み待ちを起こしてしまう。
+読み込みが OS 依存となるために環境によって左右されやすく、mmap では細かく制御することができない。
 
-それらを解決するためには、ファイル読み込みと Task を分離し、ファイルの読み込みも制御できるようになれば高速で動くのではないかと考えた。
+そこで、mmap を使わずに read を独立したスレッドで行い、読み込まれた部分に対して、並列
+タスクを起動する方法があるが、プログラミングは煩雑になる。今回は、この部分を
+実装し、mmap に対して、どれだけ性能が向上するかを調べる
 
 
 \begin{figure}[htbp]
@@ -63,17 +71,18 @@
 
 \subsection{Blocked Read の設計と実装}
 
+% Asynchronous Read の方が良いね。
+
 Blocked Read とは、読み込みの Task と、それらに対して何らかの処理を行う Task を切り離すための実装方法である。それを実現するため、pread 関数にて実装した。
 pread 関数は、unistd.h に含まれている UNIX 専用の関数である。
 ファイルディスクリプタで指定したファイルの先頭から offset 分ずれた場所を基準として、その基準から count バイトを読み込み、それを buf に格納する。
-(表4)
+(表4)  
 
 \begin{tiny}
   \begin{table}[ht]
     \begin{center}
       \small
       ssize\_t pread(int d, void *buf, size\_t nbyte, off\_t offset);
-
       \begin{tabular}[t]{c|l}
         \hline
         int d & 読み込むファイルのファイルディスクリプタ\\
@@ -151,8 +160,12 @@
 set\_outData(0) にファイルを読み込んだときの格納場所を指定し、set\_param(0) にて読み込むファイルのファイルディスクリプタを設定している。
 set\_param(1) 、 set\_param(2) にて Blocked Read Task 単体で読み込むファイルの範囲の先頭と末尾のポジションを設定する。
 
-なお、run\_tasks 内部で、処理を行う task を生成している。
-その内部で、task が生成されるたびに task\_num のインクリメントを行っている。
+Cerium の Task は、最初に word count に必要な Task を全部起動してしまうと、そのTaskを表すデータ構造自体がメモリを消費してしまう。
+そこで、既にある程度の量の Task を起動し、それが終了してから(正確には、終了する前に)次のTaskを生成するようになっている。
+これが \verb+run_tasks+ である。
+そこの部分にファイルを読み込む Task との待ち合わせを入れれば良いので、実装は比較的容易にできる。
+
+\verb+run_tasks+ の中で、\verb+READ_TASK+ に対する待ち合わせを \verb+wair_for()+ を使って実現している。
 
 Blocked Read Task の記述は以下のようになる。
 
@@ -180,6 +193,7 @@
 
 それらのパラメータを使用して、pread 関数に渡すことで Blocked Read によるファイル読み込みを実現している。
 
+
 \subsection{I/O 専用 thread の実装}
 
 Cerium Task Manager では、各種 Task にデバイスを設定することができる。
@@ -209,9 +223,12 @@
 %\label{fig:addio0}
 %\end{figure}
 
-IO\_0 は、SPE\_ANY よりも priority を高く設定しているので、IO\_0 で設定された Read Task に SPE\_ANY で設定した 文字列検索 Task に割り込まれることがなくなる。
-Cerium では、並列処理を pthread で記述しており、pthread\_getschedparam()でIO\_0 の priority を設定している。
-pthread\_getschedparam は、〜をする関数である。
+IO\_0 は、SPE\_ANY とは、別なスレッド動いているスケジューラーで動くので、
+SPE\_ANY で動いている 文字列検索 Task に割り込まれることはない。
+しかし、読み込みが完了した時に、その完了を通知し、次の read を行う時に、他の計算スレッドにスレッドレベルで割り込まれてしまうと、全体の計算が待たされてしまう。
+そこで、 pthread\_getschedparam()でIO\_0 の priority を設定している。
+IO thread は計算はほとんどしないので、高い優先順位を割り当てても他の計算を行うスレッドには影響しない。
+IOを含む処理では IOを行うスレッドの優先順位を高くする必要があるということである。
 (図\ref{fig:io0})
 
 \begin{figure}[htbp]

--- a/paper/sigos.tex	Mon Apr 21 14:53:36 2014 +0900
+++ b/paper/sigos.tex	Mon Apr 21 23:10:45 2014 +0900
@@ -47,15 +47,18 @@
 Blocked Read ではファイル読み込みからの測定だと速くなった。
 \end{abstract}
 % 英文概要
-% \begin{eabstract}
-% Cerium Task Manager is a parallel programming framework.
-% To achieve good performance in GPGPU using Open CL, various tuning is needed.
-% In particular, it is necessary to implement the dependency of task in Cerium by the function of Open CL.
-% But, to match specialization for OpenCL spoiles of flexibility of framework. 
-% Balance of flexibility and the performance is considered.
-% We evaluate example  Sort, Word count, and FFT.
-% 
-% \end{eabstract}
+\begin{eabstract}
+We are developping a Parallel task manager Cerium.
+With I/O, speciall care is necessary to work with parallel processing.
+It is easy to use mmap system call to read from file parallely, but
+current implementation of mmap sometimes does work well.
+So we implement asynchronous read thread with high priority.
+If the file is in a kernel file system cache, mmap and asynchronous
+read has no difference. In real read situation, asynchronous read
+sometimes gives good result on word count example. We gives the
+result and analysis.
+
+\end{eabstract}
 
 % 表題などの出力
 \maketitle