--- a/paper/text/chapter2.tex	Sat Jan 15 16:50:14 2022 +0900
+++ b/paper/text/chapter2.tex	Sun Jan 16 18:52:03 2022 +0900
@@ -11,23 +11,6 @@
 特に入力のDataGearをInput DataGear，出力のDataGearをOutput DataGearと呼ぶ．
 gotoで次のCodeGearに遷移することができ，その際Output DataGearを次のCodeGearのInput DataGearとして渡すことができる．
 
-\section{ノーマルレベルとメタレベル}
-図\ref{fig:meta-cgdg}はCodeGearの遷移とMetaCodeGearの関係を表している．
-ノーマルレベルで見るとCodeGearがDataGearを受け取り，
-処理後，DataGearを次のCodeGearに渡すという動作をしているように見える．
-実際にはデータの整合性の確認や資源管理などのメタレベルの処理が存在し，
-それらの計算はMetaCodeGearで行われる．
-その際，MetaCodeGearに渡されるDataGearのことは特にMetaDataGearと呼ばれる．
-CodeGearの前に実行されるMetaCodeGearは特にstubCodeGearと呼ばれ，
-メタレベルを含めるとstubCodeGearとCodeGearを交互に実行する形で遷移していく．
-\begin{figure}[h]
-  \begin{center}
-      \includegraphics[width=100mm]{figs/meta-cg-dg.pdf}
-  \end{center}
-      \caption{CodeGearとMetaCodeGearの関係}
-  \label{fig:meta-cgdg}
-\end{figure}
-
 \section{継続}
 CodeGearから次のCodeGearに遷移していく一連の動作を継続と呼ぶ．
 CbCの継続はfunction callをせずにgotoによるjmpで行われる．
@@ -50,23 +33,63 @@
 軽量継続を基本とし，stackを持たない代わりに全てをContext経由で実行する．
 ノーマルレベルとメタレベルの処理を切り分けることができ，同様にGearの概念を持つCbC(Continuation based C)で記述されている．
 GearsOSは現在開発途上であり，OSとして動作するために今後実装しなければならない機能がいくつか残っている．
-\section{信頼性の保証}
-\section{stub}
-\section{context}
+
+\section{stubCodeGear}
+図\ref{fig:meta-cgdg}はCodeGearの遷移とMetaCodeGearの関係を表している．
+ノーマルレベルで見るとCodeGearがDataGearを受け取り，
+処理後，DataGearを次のCodeGearに渡すという動作をしているように見える．
+実際にはデータの整合性の確認や資源管理などのメタレベルの処理が存在し，
+それらの計算はMetaCodeGearで行われる．
+その際，MetaCodeGearに渡されるDataGearのことは特にMetaDataGearと呼ばれる．
+CodeGearの前に実行されるMetaCodeGearは特にstubCodeGearと呼ばれ，
+メタレベルを含めるとstubCodeGearとCodeGearを交互に実行する形で遷移していく．
+\begin{figure}[h]
+  \begin{center}
+      \includegraphics[width=100mm]{figs/meta-cg-dg.pdf}
+  \end{center}
+      \caption{CodeGearとMetaCodeGearの関係}
+  \label{fig:meta-cgdg}
+\end{figure}
+
+\section{Context}
+Contextは全てのCodeGear，DataGearを参照することができるMetaDataGearで，従来OSのプロセスに相当する．
+OS全体のContextを管理するKernel Contextやユーザープログラムごとに存在するUser Contextなどがある．
+ノーマルレベルのCodeGearがContextを直接参照してしまうと，メタレベルを切り分けた意味がなくなってしまう．
+そのためContextは必ずMetaDataGearとしてMetaCodeGearから参照される．
 
 \chapter{Christie}
 Christieは当研究室で開発を行っているJavaで記述された分散フレームワークである．
-CodeGear，DataGear，CodeGearManager，DataGearManagerなどのCbCと似ているが別物のGearという概念を持つ．
+CbCと似ているが別物のGearという概念や，任意のTopologyを形成するためのTopologyManagerがある．
+
+\section{Gearの概念}
+Christieには以下の4つのGearという概念が存在する．
+
+\begin{itemize}
+  \item CodeGear
+  \item DataGear
+  \item CodeGearManager（以下CGM）
+  \item DataGearManager（以下DGM）
+\end{itemize}
+
 CodeGearはクラスやスレッドに相当する．DataGearは変数データに相当し，Javaのアノテーションを用いて記述される．
-CodeGearManagerはいわゆるノードに相当し，CodeGear，DataGear，DataGearManagerを管理する．
-複数のCodeGearManager同士が配線され，DataGearを送信し合うことで分散処理を実現している．
-DataGearManagerはDataGearを管理しているもので変数プールに相当する．
-GearsOSではDataGearManagerの仕組みをファイルシステムとして用いたい．
-さらに，ChristieにはTopologyを形成するためのTopologyManagerがある．
-TopologyManagerはCodeGearManagerを任意の形のTopologyに接続する機能を持っている．
-\section{Gearの概念}
+CGMはいわゆるノードに相当し，CodeGear，DataGear，DGMを管理する．
+複数のCGM同士が配線され，DataGearを送信し合うことで分散処理を実現している．
+DGMはDataGearを管理しているもので変数プールに相当する．
+
 \section{DataGearManager}
-\section{topology manager}
+DataGearManagerはkey value storeの構造を持つ．
+CGMが利用するCGのkeyとputされたDataGearの組み合わせでDataGearを管理する．
+DGMはLocalDGMとRemoteDGMに区別することができる．
+LocalDGMはCGM自身が所持するDataGearのプールである．
+ReomoteDGMはCGMが配線されている別のCGMがもつDGのプールである．
+
+\section{Topology-Manager}
+Christieには任意のtopologyを生成し，ノード同士の通信接続を管理ことができるTopology-Managerという機能が存在する．
+Topology-Managerで生成できるtopologyには静的topologyと動的topologyの2つがある．
+静的topologyはプログラマが任意のtopologyとノードの配線を行うことができる．
+dotファイルにノードの配線を記述し，Topology-Managerに参照させることで生成する．
+dotファイルに記述したノードの数と参加ノードの数が一致した場合に動作する．
+動的topologyは参加を表明したノードに対し，自動的に配線を行う．
 
 \chapter{UnixのFileSystem}
 \section{inode}

Binary file paper/thesis.pdf has changed