Mercurial > hg > Papers > 2022 > ikki-master

--- a/Paper/chapter/0-introduction.tex	Thu Feb 10 01:08:27 2022 +0900
+++ b/Paper/chapter/0-introduction.tex	Thu Feb 10 10:03:41 2022 +0900
@@ -9,8 +9,8 @@


 当研究室では信頼性の保証と拡張性の高さを目指したOSプロジェクトである、GearsOSの開発を行なっている。
-GearsOSはテストコードでなく、AgdaやCoqなどの型式手法に含まれる定理証明支援系やモデル検査を用い、
-実施にOSとして動作するコードそのものを検証することで信頼性の補償を目指している。
+GearsOSはテストコードでなく、AgdaやCoqなどの形式手法に含まれる定理証明支援系やモデル検査を用い、
+実施にOSとして動作するコードそのものを検証することで信頼性の保証を目指している。
 また、GeasOSはノーマルレベルとメタレベルを分離して記述するContinuation based C(CbC)にて記述される。
 ノーマルレベルとはユーザが行いたい計算をさし、メタレベルとはノーマルレベルの計算を行うための計算をさす。
 ノーマルレベルのプログラムのメタレベルに対して自由に差し替えを行うことにより、
@@ -31,4 +31,4 @@
 GearsOSのファイルシステムでは、Christieによるファイル通信を構成することで自律分散なファイルシステムの構築を目指したい。

 加えて、Christieの持つGear概念による簡潔な分散処理と、処理を行うノードごとの接続(Topology形成)
-を管理するTopologyManagerの機能を用いることによって複雑な分散処理の構成を簡潔化が期待できる。
+を管理するTopologyManagerの機能を用いることによって複雑な分散処理の接続の簡潔化が期待できる。
--- a/Paper/chapter/3-GearsOS.tex	Thu Feb 10 01:08:27 2022 +0900
+++ b/Paper/chapter/3-GearsOS.tex	Thu Feb 10 10:03:41 2022 +0900
@@ -51,12 +51,12 @@
 Impl内で記述した変数は後述のコンストラクタで行われる処理によって、プログラム上でimpl*型変数\texttt{->}変数名で参照が行えるようになる。
 また、GearsOSは全てのInterface, Implの情報を構造体としてコンパイルする際にContextに記録するため、
 ソースコード中2,3,4行ではImplに別のInterfaceを構造体として記述することで、
-プログラム内で他のInterfaceを実装したプログラム、もしくはInterfaceを純粋な構造体としてを呼び出すことができる。
+プログラム内で他のInterfaceを実装したプログラム、もしくはInterfaceを純粋な構造体として呼び出すことができる。

 \lstinputlisting[label=src:SynchronizedQueue.h, caption=Queue.hの実装となるSynchronizedQueue.h]{src/SynchronizedQueue.h}

 \section{GearsOSのプログラム例}
-GearsOSのプログラムの一例として先述したソースコード\ref{src:Queue.h}、\ref{src:SynchronizedQueue.h}をInterface,Imlementとして継承した
+GearsOSのプログラムの一例として先述したソースコード\ref{src:Queue.h}、\ref{src:SynchronizedQueue.h}をInterface,Implementとして継承した
 SynchronizedQueue.cbcの一部分をソースコード\ref{src:SynchronizedQueue.cbc}に示す。
 GearsOSにはImplementが記述されたヘッダファイルから、cbcファイルの雛形を自動生成するimpl2cbc.plが導入されている。
 雛形には7行目のQueue*を返すcreateSychronizedQueueとその中の処理、
@@ -79,7 +79,7 @@

 22行目から38行目はInterfaceで宣言されたputAPIの実装部分である。
 Interfaceで宣言されたAPIと対応するCodeGearは.cbcファイル上ではAPI名 + Impl名で宣言する必要がある。
-コンストラクタ内13行目にてatopmiReferenceの呼び出しを行っているが、atomicInterfaceへのポインタは最終的に返り値のqueueが保持しているため、
+コンストラクタ内13行目にてatomicReferenceの呼び出しを行っているが、atomicInterfaceへのポインタは最終的に返り値のqueueが保持しているため、
 atomicInterfaceで定義されたAPIのCodeGearへ遷移することができるようになる。
 現状のGearsOSでは一度、Interfaceのポインタ型をプログラム内で宣言し、コンストラクタで生成した実装のポインタを代入、
 そしてgoto文を用いて遷移するという冗長な記述が必要となっているため、トランスコンパイラにより改善するといった手段が考えられる。
@@ -97,13 +97,13 @@

 図\ref{fig:context}にCodeGearが遷移する際のContextに対するDataGearの書き込みまたは呼び出しを示す。
 CodeGearが遷移する際にOutputDataGearをContextに対して書き込みを行う。
-続いて遷移先のstubCodeGearがContextから遷移先CodeGearが必要とするInputDataGer
+続いて遷移先のstubCodeGearがContextから遷移先CodeGearが必要とするInputDataGear
 と出力する必要があるOutputDataGearを参照する。
 stubCodeGearでDataGearの準備が完了したあと、本体のCodeGearへ遷移し処理により出力されたデータをOutPutDataGearとして書き出す。
 以上の手順で軽量継続の際にContextの参照が行われる。

 Contextはノーマルレベルから直接参照を行わない。
-Contextをユーザーが任意の操作することはノーマルレベルとメタレベルの分離した意味が無くなってしまうためである。
+Contextをユーザーが自由に操作できると、ノーマルレベルとメタレベルの分離した意味が無くなってしまうためである。
 Contextに対するDataGearの操作はstubCodeGearのみならずCodeGear内でも行われるが、それらの記述はトランスコンパイラの自動生成により行われる。
 先述のnew演算子がその一例として挙げられる。
 もしnew演算子でなく、直にContextの操作が行えてしまうと、
--- a/Paper/chapter/4-Christie.tex	Thu Feb 10 01:08:27 2022 +0900
+++ b/Paper/chapter/4-Christie.tex	Thu Feb 10 10:03:41 2022 +0900
@@ -45,8 +45,8 @@
 \end{figure}

 \section{LocalDGMとRemoteDGM}
-図DataGearManagerはLocalDGMとRemoteDGMの二種類が存在する。
-\ref{fig:RDGM}にDataGearManagerによる通信の関係性を示す。
+DataGearManagerはLocalDGMとRemoteDGMの二種類が存在する。
+図\ref{fig:RDGM}にDataGearManagerによる通信の関係性を示す。
 LocalDGMは所有しているCodeGearManager自身に対応するDGMである。
 LocalDGMにput操作を行うことで自身の持つkeyに対してDataGearを送ることができる。

@@ -89,7 +89,7 @@
 \section{Christieのプログラミング例}
 ソースコード\ref{src:SHW}\ref{src:HWCG}にChristieの簡単なプログラム例を示す。

-StartCodeGearを継承したソースコード\ref{src:SHW}、StartHelloWorldはCbCやC言語におけるmain部分に相当する。
+StartCodeGearを継承したソースコード\ref{src:SHW}、StartOddEvenはCbCやC言語におけるmain部分に相当する。
 main部分ではCodeGearManagerをポート番号指定することで作成を行う。
 また、CGMに対して処理させたいCodeGearをsetupメソッドを用いることで、CGMに対してCGを持たせることができる。
 RemoteDGMの作成などを行う。
@@ -171,7 +171,7 @@
 また、TopologyManagerはCodeGearManagerの一つが運用する。
 図\ref{fig:TM}にTopplogyManagerにて簡単なTree型Topologyを形成する際の図を示す。
 図中の場合、CGAがTopoplogyManagerを所持しており、
-TopologyManagerによってCG1がroot、CG2とCG3がCG1の子として役を割り振られ、接続される形となる。
+TopologyManagerによってCG:1がroot、CG:2とCG:3がCG:1の子として役を割り振られ、接続される形となる。


 \begin{figure}[tb]
--- a/Paper/chapter/5-Implementation.tex	Thu Feb 10 01:08:27 2022 +0900
+++ b/Paper/chapter/5-Implementation.tex	Thu Feb 10 10:03:41 2022 +0900
@@ -1,7 +1,7 @@
 \chapter{GearsFileSystemの設計と実装}
 本章ではGearsOSのFileSystem(以下GearsFS)の実装について解説する。
 GearsOSのファイルは分散ファイルシステム的に大域的な資源として、
-複数のプロセスから競合的なアクセスが可能を可能としたい。
+複数のプロセスから競合的なアクセスを可能としたい。

 GearsFSは分散フレームワークChristieの仕組みの一部を応用する。
 ファイルはChristieにおけるDataGearManager的に実装を行い、ファイルの送受信は、
@@ -64,7 +64,7 @@
 しかしファイルのアクセス権限の設定などにより、データアクセスが単一のプロセスからしか許さないもしくは想定されない環境では
 読み込みの高速化とメモリの軽量化のため、
 SingleLinkedな(単純な)Queueを用いることも考えられる。
-ファイルに対する書き込みやMainQueueは単一プロセスのみからのアクセスとなるためSingleLickedなキューで実装する。
+ファイルに対する書き込みやMainQueueは単一プロセスのみからのアクセスとなるためSingleLinkedなキューで実装する。

 ファイルのレコードは例題中では単純にファイル内文字列を行ごとに区切り、FileString構造体に書き込んだものとなる。
 \ref{src:FS}にFileString構造体を示す。
@@ -92,7 +92,7 @@

 ファイルとWordCountの接続はUNIXのシェルのようにプログラムの外で行われる。
 ファイルは事前にC言語のFILE型構造体を用いて開かれ、行列であるwc\texttt{->}strTableへ内部文字列を行区切りで保存されている。
-MainからファイルのOpenが完了した後、CodeGear:putStrinに遷移し、strTableから文字列を行ごと呼び出しCountUpへ入力し遷移する。
+MainからファイルのOpenが完了した後、CodeGear:putStringに遷移し、strTableから文字列を行ごと呼び出しCountUpへ入力し遷移する。
 CodeGear:CountUpにて文字列の出力と文字数を読み取り記録、そしてputStringへ遷移する。
 ファイルの文字列がある間はputStringとCountUpをループし続け、
 putStringはstrTableの中身がなくなった(EOF)ならshowResultへ遷移する形となる。
@@ -116,7 +116,7 @@
 Local上にRemote先のファイルのproxyとなるRemoteDGMを作成し、
 これに対しLocalのファイルへの書き込みと同様に操作を行うことで自動的に通信を行ってくれる。

-ChiristieのDataGearManagerの仕組みを基準としたGearsFile APIによるWordCountの設計を行った。
+ChristieのDataGearManagerの仕組みを基準としたGearsFile APIによるWordCountの設計を行った。
 図\ref{fig:GearsFile API}にGearsFile APIによるWordCountを示す。
 GearsFile APIによるファイルデータ通信は2ペアのLocal/RemoteDGMを通して行われる。
 RemoteDGMは接続先のノードが持つLocalDGMのプロキシであり、RemoteDGMに対してput操作を行うことで、相手の持つLocalDGMへのデータの送信が行える。
@@ -130,7 +130,7 @@

 図中ではRemoteDGMを複数作成することにより通信のやりとりを行っているが、
 WordCountでない純粋なファイルの送信などの場合、DGMのSocketが持つAckのみでも通信を構成することが可能である。
-そのためデータの一方的な送受信のみならDGMのペアは一つだけでも通信が行うことができる。
+そのためデータの一方的な送受信のみならDGMのペアは一つだけでも通信を行うことができる。


@@ -169,13 +169,13 @@
 Remote側のsendDataはAPIとしては呼び出しは行えず、putAPIが呼び出されQueueへのput処理が終了した後に遷移され、
 putしたDataを接続先のQueueに対して送信する。

-\lstinputlisting[label=src:LDGQh, caption=LocalDGMQueueで使われるデータ構造たい]{src/LocalDGMQueue.h}
+\lstinputlisting[label=src:LDGQh, caption=LocalDGMQueueで使われるデータ構造体]{src/LocalDGMQueue.h}

 現状ではデータの通信に行われるDataGearは全てのDataGearのUnion(共用体)となるData型を用いている。
 送信データのサイズをUnion Data型のサイズにしている理由は、sizeof関数で返される値は共用体に含まれる構造体の中で最も大きなメモリサイズを返すためである。
 これによりputされたDataGearの型がどのようなものであれ、受け取り側がDataGearの型を正しく選択している限りはデータの整合性を守ることができる。
 しかし、受信側が受け取ったデータレコードの正しい型を把握しているとは限らないため、
-将来的にはJavaにおけるmessagePackに相当する機能になどによるシリアライズしたデータを送信する形にする。
+将来的にはJavaにおけるMessagePackに相当する機能になどによるシリアライズしたデータを送信する形にする。
 Socketの処理中に問題が発生した場合はinputDataGearとして指定した\texttt{\_\_}code whenError()として入力されたCodeGearに対して遷移する。

 \newpage{}
@@ -203,7 +203,7 @@
 いずれの場合もリストとなる赤黒木に対して任意のkeyのQueueのget操作を行い、そのQueueに対してputもしくはtake操作を行う。
 あくまでこのDGMはファイルに相当するものなので、
 赤黒木に含まれているQueueはInput/OutputStreamと実際にファイルデータを保持しておくmainDataQueueの三つとなる。
-しかしWordCount例題のackや結果出力の通信など用途に用いるDataGearが必要な場合、Streamとなるkey以外を用いるために、
+しかしWordCount例題のAckや結果出力の通信など用途に用いるDataGearが必要な場合、Streamとなるkey以外を用いるために、
 ファイルに関連するkey以外にも任意にQueueを追加することもできる。
 任意のQueueを追加したい場合はstoreとなるTreeに対して、
 Treeが保持していないkeyへputが行われた場合は新しくそのkeyを持つQueueを生成しTreeに持たせる処理を追加すれば良い。
@@ -247,7 +247,7 @@
 \end{figure}

 GearsのディレクトリシステムはUnixのi-nodeの仕様を用いる。
-i-nodeとはファイルごとのユニークな番号(i-node番号)。データ領域へのポインタや作成日時、サイズなどのメタデータを保存するための領域である。
+i-nodeとはファイルごとのユニークな番号(i-node番号)をもち、データ領域へのポインタや作成日時、サイズなどのメタデータを保存するための領域である。
 GearsFSの赤黒木を用いたディレクトリシステムに実際に保存されるノードはkeyがFileName、
 valueがi-nodeのペアを保持している。
 DirectoryTreeをファイル名で探索を行うことで任意のファイルのi-node番号を手に入れ、DirectroyTreeとは別に実装されたkeyにi-node番号とペアとして
@@ -303,7 +303,7 @@
 よってDataGearを保持するQueueは純粋なQueueでなく複数のアクセスが行われても、
 データの整合性が保たれるSynchronizedなQueueを用いる必要が生じる場面がある。

-ChristieのではTask(CodeGear)はCodeGearManagerにより実行が行われる。
+ChristieではTask(CodeGear)はCodeGearManagerにより実行が行われる。
 GearsFSでは並列処理をCodeGearManagerを用いた実装に代わり、GearsOSに搭載されたpar gotoを利用するという手段が考えられる。
 par gotoとはGearsOSにおける並列処理構文である。
 par gotoによる並列処理ではTaskをContextで表現し、TaskのInputDataGearが揃ったTaskをWorkerで処理を行う。
--- a/Paper/chapter/6-Evaluation.tex	Thu Feb 10 01:08:27 2022 +0900
+++ b/Paper/chapter/6-Evaluation.tex	Thu Feb 10 10:03:41 2022 +0900
@@ -1,6 +1,6 @@
 \chapter{GearsOSの評価}
 当研究は純粋なGearsOSを用いて実装されるプロジェクトとしては初めてのものとなっている。
-本性ではファイルシステムの構築を通したGearsOSの評価を行う。
+本章ではファイルシステムの構築を通したGearsOSの評価を行う。


@@ -48,7 +48,7 @@
 加えてソースコード\ref{src:misspar}にソースコード\ref{src:mainDist}をトランスコンパイルした.cプログラムを示す。

 この問題点の一つとしてTaskの終了を示すCodeGearである\texttt{\_\_}exitが機能しないという問題がある。
-ソースコード\ref{src:mainDist}の4,5行目では本体par gotoにてTask:countUp->eNumが終了次第、
+ソースコード\ref{src:mainDist}の4,5行目では本体par gotoにてTask:countUp\texttt{\_}code>eNumが終了次第、
 Taskを処理したWorkerを解放せるための\texttt{\_\_}exitをnext\texttt{\_}codeとして指定したい。
 しかし、下記のコードではトランスコンパイルの時点でエラーを起こし、プログラムのコンパイルが行えない。
--- a/Paper/chapter/abstract.tex	Thu Feb 10 01:08:27 2022 +0900
+++ b/Paper/chapter/abstract.tex	Thu Feb 10 10:03:41 2022 +0900
@@ -19,7 +19,7 @@
 In our laboratory, we are developing GearsOS, an operating system for verifying the reliability of operating systems, which aims to compensate for scalability and reliability by separating user-level and meta-level descriptions.
 GearsOS is written in Continuation based C (CbC) and has the programming concept of Gears.
 Since GearsOS is still under development, it is currently implemented as a language framework, and there are many functions that need to be implemented in order to run as an OS, one of which is a distributed file system.
-One of them is a distributed file system. The distributed file system of GearsOS uses the distributed framework Christie, which is developed by our laboratory.
+The distributed file system of GearsOS uses the distributed framework Christie, which is developed by our laboratory.
 Christie has a different programming concept called "Gear" from GearsOS, and implements communication by connecting a DataPool called DataGearManager to a socket between nodes.
 The files in GearsOS are structured in the same way as DataGearManager, so that they are not only files but also correspond to the communication process itself.
 In this study, we used Christie's DataGearManager as a file and configured the API for its communication.
Binary file Paper/master_paper.pdf has changed
--- a/Paper/master_paper.tex	Thu Feb 10 01:08:27 2022 +0900
+++ b/Paper/master_paper.tex	Thu Feb 10 10:03:41 2022 +0900
@@ -33,7 +33,6 @@
 % \end{minipage}}

 \newcommand\figref[1]{図 \ref{fig:#1}}
-\newcommand\tabref[1]{表 \ref{tab:#1}}
 \newcommand\coderef[1]{ソースコード \ref{code:#1}}

 \lstset{
@@ -90,8 +89,7 @@
 %図目次
 \listoffigures

-%表目次
-\listoftables
+

 %リスト目次
 % \lstlistoflistings
--- a/slide/thesis.html	Thu Feb 10 01:08:27 2022 +0900
+++ b/slide/thesis.html	Thu Feb 10 10:03:41 2022 +0900
@@ -103,8 +103,8 @@
   </li>
   <li>GearsOSには将来的にアプリケーションが担う重要な機能をOSに取り込みたい
     <ul>
+      <li>ファイルの型認識</li>
       <li>バックアップ</li>
-      <li>ファイルの型認識</li>
     </ul>
   </li>
 </ul>
@@ -392,24 +392,6 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="複数のストリームから構成されるファイル">複数のストリームから構成されるファイル</h2>
-<ul>
-  <li>入力されるデータに応じた個別のstreamを備えたい
-    <ul>
-      <li>streamと入力されたデータの処理を直接結びつけたい</li>
-    </ul>
-  </li>
-  <li>最低でもInput/OutputStreamの二つが必要となる</li>
-  <li>ファイルは複数のStreamを持ったリストとして実装する</li>
-  <li>Streamはkey nameを持ち、keyでアクセスを行う</li>
-</ul>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
 <h2 id="ファイル通信の構成">ファイル通信の構成</h2>
 <ul>
   <li>GearsOSのファイルは大域的に解放された資源としたい
@@ -450,7 +432,7 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="datagearmanager-1">DataGearManager</h2>
+<h2 id="datagearmanagerによる通信構成">DataGearManagerによる通信構成</h2>
 <ul>
   <li>任意の相手のRemoteDGMを作成することでTopologyが形成される</li>
 </ul>
@@ -466,11 +448,10 @@
   <!-- _S9SLIDE_ -->
 <h2 id="gearsos上のsocket通信">GearsOS上のsocket通信</h2>
 <ul>
-  <li>GearsOS上のsocket通信を検証したい</li>
+  <li>GearsOS上のsocket通信を実装したい</li>
   <li>Queueをsocketに接続し、簡易的なAPIの記述をした
     <ul>
-      <li>Localなqueueに対してRemoteのqueueがソケット接続を行う</li>
-      <li>socketはQueueの生成時に接続される
+      <li>Localなqueueに対してRemoteのqueueがソケット接続を行う
         <pre><code>typedef struct CQueue&lt;&gt;{
 union Data* cQueue;
 union Data* data;
@@ -496,11 +477,10 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="remotequeue側からの送信">RemoteQueue側からの送信</h2>
+<h2 id="senddata-codegear">sendData CodeGear</h2>
 <ul>
-  <li>QueueのPutAPIの後に遷移される</li>
-  <li>putしたデータをsocketを通じて送信する</li>
-  <li>将来的にsendではなくwriteを用いる
+  <li>proxy側はQueueにputされたDataをsocketで送信する</li>
+  <li>送信されたDataはLocal側でgetDataAPIで取り出される
     <pre><code>__code sendDataRemoteDGMQueue(struct RemoteDGMQueue* cQueue, union Data* data, __code next(...), __code whenError(...)){
   char recv_buf;
   int send_size, recv_size;
@@ -520,13 +500,10 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="localqueue側の受信">LocalQueue側の受信</h2>
+<h2 id="getdata-codegear">getData CodeGear</h2>
 <ul>
-  <li>APIとしてsocketのデータを取り出す</li>
-  <li>取り出されたデータはQueueにputされる</li>
-  <li>union Data型でデータを受け取りmain側で処理を行う</li>
-  <li>取り出されたデータはmain側で処理される</li>
-  <li>将来的にrecvでなくreadを用いる
+  <li>ファイル本体(Local側)はsocketからDataを取り出す</li>
+  <li>取り出されたデータはQueueにputされる
     <pre><code>__code getDataLocalDGMQueue(struct LocalDGMQueue* cQueue, __code next(...), __code whenError(...)){
   int recv_size, send_size;
   char send_buf;
@@ -548,16 +525,45 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="ファイル単位のsocket通信">ファイル単位のsocket通信</h2>
+<h2 id="複数のストリームから構成されるファイル">複数のストリームから構成されるファイル</h2>
 <ul>
-  <li>実際のファイルは複数のQueueを持つ一つのリストである</li>
-  <li>Queue単体でなく、リスト(ファイル)単位でsocketを持つ必要がある</li>
-  <li>リストは赤黒木となる</li>
-  <li>DataGearをputするkeyを指定して書き込みを行う
+  <li>入力されるデータに応じた個別のstreamを備えたい
     <ul>
-      <li>Localなファイルの同一のQueueに対して書き込みが行われる</li>
+      <li>streamと入力されたデータの処理を直接結びつけたい</li>
     </ul>
   </li>
+  <li>最低でもInput/OutputStreamの二つが必要となる</li>
+  <li>ファイルは複数のStreamを持ったリストとして実装する</li>
+  <li>Streamはkey nameを持ち、keyでアクセスを行う</li>
+</ul>
+
+
+
+</div>
+
+<div class='slide'>
+  <!-- _S9SLIDE_ -->
+<h2 id="複数のストリームを持つファイルの設計">複数のストリームを持つファイルの設計</h2>
+<ul>
+  <li>Queueのリストとして赤黒木を用いる
+    <ul>
+      <li>key/value storeなアクセスを行うことができる</li>
+      <li>GearsOS上にすでに実装が行われている</li>
+    </ul>
+  </li>
+  <li>DataのTake/Put時には必ずkey nameの指定が必要となる</li>
+</ul>
+
+
+
+</div>
+
+<div class='slide'>
+  <!-- _S9SLIDE_ -->
+<h2 id="リスト単位の通信の構成">リスト単位の通信の構成</h2>
+<ul>
+  <li>指定したkeyのQueueが探索で返される</li>
+  <li>proxyの場合、どのkeyに対してどんなDataを書き込んだかを通信で送信する</li>
 </ul>
 <div style="text-align: center;">
   　<img src="images/socketCom.pdf" alt="socketを通じたレコード送信" width="800" />
@@ -569,31 +575,7 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="main部分によるapi">main部分によるAPI</h2>
-<ul>
-  <li>readの場合(リモート側に読み込みたいファイルが存在する)
-    <ul>
-      <li>(手順1)ローカル側は空のファイルを作成し、socketを持たせる</li>
-      <li>(手順2)リモート側は, ローカル側の持つ空ファイルのproxyを作成する</li>
-      <li>(手順3)リモート側はproxyに対して、目的のファイルのデータをputする</li>
-    </ul>
-  </li>
-  <li>writeの場合(リモート側に書き込みたいファイルが存在する)
-    <ul>
-      <li>(手順1)リモート側は対象ファイルにsocketを持たせる</li>
-      <li>(手順2)ローカル側は対象のファイルに対応するproxyを作成する</li>
-      <li>(手順3)ローカル側はproxyのkeyに対してデータをputする</li>
-    </ul>
-  </li>
-</ul>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h2 id="wordcountの例題">wordCountの例題</h2>
+<h2 id="wordcount例題による通信apiの構築">wordCount例題による通信APIの構築</h2>
 <ul>
   <li>DataGearManagerによるファイル通信APIはWordCount例題を目指して設計した
     <ul>
@@ -612,12 +594,38 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="christieapiによるwordcount">ChristieAPIによるWordCount</h2>
+<h2 id="gearsfile-apiによるwordcount13">GearsFile APIによるWordCount(1/3)</h2>
 <ul>
   <li>FileOpen側とWordCount側でノードが別れる</li>
   <li>(手順1)FileOpen側はRDGMに文字列をputする</li>
   <li>(手順2)WordCount側は処理の後、ackを返信する</li>
+</ul>
+<div style="text-align: center;">
+  　<img src="images/wordCountDGM.pdf" alt="ChristieAPIによるWordCount" width="800" />
+</div>
+
+
+
+</div>
+
+<div class='slide'>
+  <!-- _S9SLIDE_ -->
+<h2 id="gearsfile-apiによるwordcount23">GearsFile APIによるWordCount(2/3)</h2>
+<ul>
   <li>(手順3)1,2をループし、FileOpen側はEoFならフラグを送信する</li>
+</ul>
+<div style="text-align: center;">
+  　<img src="images/wordCountDGM.pdf" alt="ChristieAPIによるWordCount" width="800" />
+</div>
+
+
+
+</div>
+
+<div class='slide'>
+  <!-- _S9SLIDE_ -->
+<h2 id="gearsfile-apiによるwordcount33">GearsFile APIによるWordCount(3/3)</h2>
+<ul>
   <li>(手順4)EoFを受信したWordCountは結果を返信し、双方の処理を終了させる</li>
 </ul>
 <div style="text-align: center;">
@@ -630,16 +638,33 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="これから実装が必要となる機能">これから実装が必要となる機能</h2>
+<h2 id="現在のgearsfile-apiの開発状況">現在のGearsFile APIの開発状況</h2>
 <ul>
-  <li>keyアクセスに対応したファイル通信
+  <li>実装ずみ
     <ul>
-      <li>単一のQueueによる通信は確認が行えた</li>
+      <li>keyアクセスに対応したファイル通信
+        <ul>
+          <li>単一のQueueによる通信の記述</li>
+        </ul>
+      </li>
+      <li>リストとなるTree
+        <ul>
+          <li>赤黒木</li>
+        </ul>
+      </li>
+      <li>atomicな操作が行えるQueue
+        <ul>
+          <li>複数からのアクセス時にデータ整合を保つ</li>
+        </ul>
+      </li>
     </ul>
   </li>
-  <li>ファイル保存</li>
-  <li>バックアップ機能</li>
-  <li>並列処理</li>
+  <li>実装中
+    <ul>
+      <li>keyアクセスが行えるQueueのリスト</li>
+      <li>リスト単位での通信の記述</li>
+    </ul>
+  </li>
 </ul>


@@ -648,22 +673,7 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="gearsosのディレクトリとバックアップ">GearsOSのディレクトリとバックアップ</h2>
-<ul>
-  <li>又吉雄斗による並行研究にて、inodeによるファイルシステムが開発されている</li>
-  <li>赤黒木の非破壊な編集により、ディレクトリの履歴を残すことができる</li>
-</ul>
-<div style="text-align: center;">
-  　<img src="images/nonDestroyTreeEdit.pdf" alt="非破壊的なツリー編集" width="800" />
-</div>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h2 id="生成形の問題点">生成形の問題点</h2>
+<h2 id="gearsosの生成形の問題点">GearsOSの生成形の問題点</h2>
 <ul>
   <li>GearsOSのメタレベルの処理の記述はトランスコンパイラにより行われる</li>
   <li>場合によりメタレベルの記述を行わなくてはならない
@@ -711,12 +721,12 @@
 <h2 id="並列処理構文par-gotoが持つ問題">並列処理構文par gotoが持つ問題</h2>
 <ul>
   <li>par gotoとはGearsOSに実装された並列処理構文である</li>
+  <li>StreamQueueに対するput/takeの並列処理の実装をpar goto構文で試みた</li>
   <li>par gotoはトランスコンパイラへの依存性が高い
     <ul>
       <li>stubCodeGearのように任意な書き換えが行えない</li>
     </ul>
   </li>
-  <li>StreamQueueに対するput/takeの並列処理の実装をpar goto構文で試みた</li>
   <li>特定のCodeGearの宣言のみでしか正常な処理が生成されない
     <ul>
       <li>Interfaceに記述されたAPICodeGearではバグが生じる</li>
@@ -736,13 +746,25 @@
 <ul>
   <li>GearsOSのファイルの設計を行った
     <ul>
-      <li>ファイルの構造の設計</li>
-      <li>socketによる通信部分の実装</li>
-      <li>単純化した通信APIの記述</li>
+      <li>ファイルの構造の設計
+        <ul>
+          <li>DataGear単位での操作が行える</li>
+        </ul>
+      </li>
+      <li>socketによる通信部分の実装
+        <ul>
+          <li>GearsOS上でのソケット通信の記述</li>
+        </ul>
+      </li>
+      <li>APIの段階的な設計記述
+        <ul>
+          <li>Proxyによるファイル通信</li>
+        </ul>
+      </li>
       <li>GearsOSの調査</li>
     </ul>
   </li>
-  <li>ファイルproxyによる通信実現を行いたい</li>
+  <li>Streamのリスト単位での通信の完成</li>
 </ul>


@@ -751,7 +773,7 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="これからの課題">これからの課題</h2>
+<h2 id="将来的な課題">将来的な課題</h2>
 <ul>
   <li>TopoplogyManagerの設計
     <ul>
@@ -786,6 +808,21 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
+<h2 id="gearsosのディレクトリとバックアップ">GearsOSのディレクトリとバックアップ</h2>
+<ul>
+  <li>又吉雄斗による並行研究にて、inodeによるファイルシステムが開発されている</li>
+  <li>赤黒木の非破壊な編集により、ディレクトリの履歴を残すことができる</li>
+</ul>
+<div style="text-align: center;">
+  　<img src="images/nonDestroyTreeEdit.pdf" alt="非破壊的なツリー編集" width="800" />
+</div>
+
+
+
+</div>
+
+<div class='slide'>
+  <!-- _S9SLIDE_ -->
 <h2 id="ファイルqueueに対するapi--peek-">ファイルQueueに対するAPI -Peek-</h2>
 <ul>
   <li>Peek
--- a/slide/thesis.md	Thu Feb 10 01:08:27 2022 +0900
+++ b/slide/thesis.md	Thu Feb 10 10:03:41 2022 +0900
@@ -12,8 +12,8 @@
 - ファイルに取り扱うデータに対応した複数のストリームを持たせたい
   - 従来では異なるデータでも単一のストリームから入力される
 - GearsOSには将来的にアプリケーションが担う重要な機能をOSに取り込みたい
+  - ファイルの型認識
   - バックアップ
-  - ファイルの型認識

 ## GearsOSのGear概念(1/2)
 - 関数でなくGearという単位を用いて記述する
@@ -151,14 +151,6 @@
 ```


-
-## 複数のストリームから構成されるファイル
-- 入力されるデータに応じた個別のstreamを備えたい
-  - streamと入力されたデータの処理を直接結びつけたい
-- 最低でもInput/OutputStreamの二つが必要となる
-- ファイルは複数のStreamを持ったリストとして実装する
-- Streamはkey nameを持ち、keyでアクセスを行う
-
 ## ファイル通信の構成
 - GearsOSのファイルは大域的に解放された資源としたい
   - ファイル自信を通信そのものとして実装する
@@ -186,8 +178,6 @@
 - GearsOS上のsocket通信を実装したい
 - Queueをsocketに接続し、簡易的なAPIの記述をした
   - Localなqueueに対してRemoteのqueueがソケット接続を行う
-  - socketはQueueの生成時に接続される
-- RemoteDGM(proxy)の接続先は、他ユーザー、SSDなどのデバイスが挙げられる
 ```
 typedef struct CQueue<>{
     union Data* cQueue;
@@ -237,18 +227,30 @@
 }
 ```

-## ファイル単位のsocket通信
-- 実際のファイルは複数のQueueを持つ一つのリストである
-- Queue単体でなく、リスト(ファイル)単位でsocketを持つ必要がある
-- リストは赤黒木となる
-- DataGearをputするkeyを指定して書き込みを行う
-  - Localなファイルの同一のQueueに対して書き込みが行われる
+## 複数のストリームから構成されるファイル
+- 入力されるデータに応じた個別のstreamを備えたい
+  - streamと入力されたデータの処理を直接結びつけたい
+- 最低でもInput/OutputStreamの二つが必要となる
+- ファイルは複数のStreamを持ったリストとして実装する
+- Streamはkey nameを持ち、keyでアクセスを行う
+
+## 複数のストリームを持つファイルの設計
+- Queueのリストとして赤黒木を用いる
+  - key/value storeなアクセスを行うことができる
+  - GearsOS上にすでに実装が行われている
+- DataのTake/Put時には必ずkey nameの指定が必要となる
+
+## リスト単位の通信の構成
+- 指定したkeyのQueueが探索で返される
+- proxyの場合、どのkeyに対してどんなDataを書き込んだかを通信で送信する
 <div style="text-align: center;">
   　<img src="images/socketCom.pdf" alt=socketを通じたレコード送信 width="800">
 </div>


-## wordCountの例題
+
+
+## wordCount例題による通信APIの構築
 - DataGearManagerによるファイル通信APIはWordCount例題を目指して設計した
   - ファイル内の文字列を1行づつ受け取り、文字列,行数をカウントする例題
 - 文字列送信側とCount側を別ノード上で行うことで、ファイルの呼び出しと通信処理が構成できる
@@ -258,34 +260,41 @@


-## ChristieAPIによるWordCount
+##  GearsFile APIによるWordCount(1/3)
 - FileOpen側とWordCount側でノードが別れる
 - (手順1)FileOpen側はRDGMに文字列をputする
 - (手順2)WordCount側は処理の後、ackを返信する
+<div style="text-align: center;">
+  　<img src="images/wordCountDGM.pdf" alt=ChristieAPIによるWordCount width="800">
+</div>
+
+##  GearsFile APIによるWordCount(2/3)
 - (手順3)1,2をループし、FileOpen側はEoFならフラグを送信する
+<div style="text-align: center;">
+  　<img src="images/wordCountDGM.pdf" alt=ChristieAPIによるWordCount width="800">
+</div>
+
+##  GearsFile APIによるWordCount(3/3)
 - (手順4)EoFを受信したWordCountは結果を返信し、双方の処理を終了させる
 <div style="text-align: center;">
   　<img src="images/wordCountDGM.pdf" alt=ChristieAPIによるWordCount width="800">
 </div>


-## これから実装が必要となる機能
-- keyアクセスに対応したファイル通信
-  - 単一のQueueによる通信は確認が行えた
-- ファイル保存
-- バックアップ機能
-- 並列処理
-
-## GearsOSのディレクトリとバックアップ
-- 又吉雄斗による並行研究にて、inodeによるファイルシステムが開発されている
-- 赤黒木の非破壊な編集により、ディレクトリの履歴を残すことができる
-<div style="text-align: center;">
-  　<img src="images/nonDestroyTreeEdit.pdf" alt=非破壊的なツリー編集 width="800">
-</div>
+## 現在のGearsFile APIの開発状況
+- 実装ずみ
+  - keyアクセスに対応したファイル通信
+    - 単一のQueueによる通信の記述
+  - リストとなるTree
+    - 赤黒木
+  - atomicな操作が行えるQueue
+    - 複数からのアクセス時にデータ整合を保つ
+- 実装中
+  - keyアクセスが行えるQueueのリスト
+  - リスト単位での通信の記述


-
-## 生成形の問題点
+## GearsOSの生成形の問題点
 - GearsOSのメタレベルの処理の記述はトランスコンパイラにより行われる
 - 場合によりメタレベルの記述を行わなくてはならない
   - 他のInterfaceを継承したオブジェクトからのDataGear継承
@@ -319,9 +328,9 @@

 ## 並列処理構文par gotoが持つ問題
 - par gotoとはGearsOSに実装された並列処理構文である
+- StreamQueueに対するput/takeの並列処理の実装をpar goto構文で試みた
 - par gotoはトランスコンパイラへの依存性が高い
   - stubCodeGearのように任意な書き換えが行えない
-- StreamQueueに対するput/takeの並列処理の実装をpar goto構文で試みた
 - 特定のCodeGearの宣言のみでしか正常な処理が生成されない
   - Interfaceに記述されたAPICodeGearではバグが生じる
   - par gotoでの使用を前提としたCodeGearを書かなくてはならない
@@ -331,12 +340,15 @@
 ## 結論
 - GearsOSのファイルの設計を行った
   - ファイルの構造の設計
+    - DataGear単位での操作が行える
   - socketによる通信部分の実装
-  - 単純化した通信APIの記述
+    - GearsOS上でのソケット通信の記述
+  - APIの段階的な設計記述
+    - Proxyによるファイル通信
   - GearsOSの調査
-- ファイルproxyによる通信実現を行いたい
+- Streamのリスト単位での通信の完成

-## これからの課題
+## 将来的な課題
 - TopoplogyManagerの設計
   - 参加したノードを任意の形のTopologyに接続する機能
   - ファイルシステム向けの機能を追加したい
@@ -348,6 +360,14 @@

 ## この先保留

+## GearsOSのディレクトリとバックアップ
+- 又吉雄斗による並行研究にて、inodeによるファイルシステムが開発されている
+- 赤黒木の非破壊な編集により、ディレクトリの履歴を残すことができる
+<div style="text-align: center;">
+  　<img src="images/nonDestroyTreeEdit.pdf" alt=非破壊的なツリー編集 width="800">
+</div>
+
+
 ## ファイルQueueに対するAPI -Peek-
 - Peek
   - QueueのElementを参照するが、削除は行わない
--- a/slide/thesis.pdf.html	Thu Feb 10 01:08:27 2022 +0900
+++ b/slide/thesis.pdf.html	Thu Feb 10 10:03:41 2022 +0900
@@ -87,8 +87,8 @@
   </li>
   <li>GearsOSには将来的にアプリケーションが担う重要な機能をOSに取り込みたい
     <ul>
+      <li>ファイルの型認識</li>
       <li>バックアップ</li>
-      <li>ファイルの型認識</li>
     </ul>
   </li>
 </ul>
@@ -376,24 +376,6 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="複数のストリームから構成されるファイル">複数のストリームから構成されるファイル</h2>
-<ul>
-  <li>入力されるデータに応じた個別のstreamを備えたい
-    <ul>
-      <li>streamと入力されたデータの処理を直接結びつけたい</li>
-    </ul>
-  </li>
-  <li>最低でもInput/OutputStreamの二つが必要となる</li>
-  <li>ファイルは複数のStreamを持ったリストとして実装する</li>
-  <li>Streamはkey nameを持ち、keyでアクセスを行う</li>
-</ul>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
 <h2 id="ファイル通信の構成">ファイル通信の構成</h2>
 <ul>
   <li>GearsOSのファイルは大域的に解放された資源としたい
@@ -434,7 +416,7 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="datagearmanager-1">DataGearManager</h2>
+<h2 id="datagearmanagerによる通信構成">DataGearManagerによる通信構成</h2>
 <ul>
   <li>任意の相手のRemoteDGMを作成することでTopologyが形成される</li>
 </ul>
@@ -450,11 +432,10 @@
   <!-- _S9SLIDE_ -->
 <h2 id="gearsos上のsocket通信">GearsOS上のsocket通信</h2>
 <ul>
-  <li>GearsOS上のsocket通信を検証したい</li>
+  <li>GearsOS上のsocket通信を実装したい</li>
   <li>Queueをsocketに接続し、簡易的なAPIの記述をした
     <ul>
-      <li>Localなqueueに対してRemoteのqueueがソケット接続を行う</li>
-      <li>socketはQueueの生成時に接続される
+      <li>Localなqueueに対してRemoteのqueueがソケット接続を行う
         <pre><code>typedef struct CQueue&lt;&gt;{
 union Data* cQueue;
 union Data* data;
@@ -480,11 +461,10 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="remotequeue側からの送信">RemoteQueue側からの送信</h2>
+<h2 id="senddata-codegear">sendData CodeGear</h2>
 <ul>
-  <li>QueueのPutAPIの後に遷移される</li>
-  <li>putしたデータをsocketを通じて送信する</li>
-  <li>将来的にsendではなくwriteを用いる
+  <li>proxy側はQueueにputされたDataをsocketで送信する</li>
+  <li>送信されたDataはLocal側でgetDataAPIで取り出される
     <pre><code>__code sendDataRemoteDGMQueue(struct RemoteDGMQueue* cQueue, union Data* data, __code next(...), __code whenError(...)){
   char recv_buf;
   int send_size, recv_size;
@@ -504,13 +484,10 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="localqueue側の受信">LocalQueue側の受信</h2>
+<h2 id="getdata-codegear">getData CodeGear</h2>
 <ul>
-  <li>APIとしてsocketのデータを取り出す</li>
-  <li>取り出されたデータはQueueにputされる</li>
-  <li>union Data型でデータを受け取りmain側で処理を行う</li>
-  <li>取り出されたデータはmain側で処理される</li>
-  <li>将来的にrecvでなくreadを用いる
+  <li>ファイル本体(Local側)はsocketからDataを取り出す</li>
+  <li>取り出されたデータはQueueにputされる
     <pre><code>__code getDataLocalDGMQueue(struct LocalDGMQueue* cQueue, __code next(...), __code whenError(...)){
   int recv_size, send_size;
   char send_buf;
@@ -532,16 +509,45 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="ファイル単位のsocket通信">ファイル単位のsocket通信</h2>
+<h2 id="複数のストリームから構成されるファイル">複数のストリームから構成されるファイル</h2>
 <ul>
-  <li>実際のファイルは複数のQueueを持つ一つのリストである</li>
-  <li>Queue単体でなく、リスト(ファイル)単位でsocketを持つ必要がある</li>
-  <li>リストは赤黒木となる</li>
-  <li>DataGearをputするkeyを指定して書き込みを行う
+  <li>入力されるデータに応じた個別のstreamを備えたい
     <ul>
-      <li>Localなファイルの同一のQueueに対して書き込みが行われる</li>
+      <li>streamと入力されたデータの処理を直接結びつけたい</li>
     </ul>
   </li>
+  <li>最低でもInput/OutputStreamの二つが必要となる</li>
+  <li>ファイルは複数のStreamを持ったリストとして実装する</li>
+  <li>Streamはkey nameを持ち、keyでアクセスを行う</li>
+</ul>
+
+
+
+</div>
+
+<div class='slide'>
+  <!-- _S9SLIDE_ -->
+<h2 id="複数のストリームを持つファイルの設計">複数のストリームを持つファイルの設計</h2>
+<ul>
+  <li>Queueのリストとして赤黒木を用いる
+    <ul>
+      <li>key/value storeなアクセスを行うことができる</li>
+      <li>GearsOS上にすでに実装が行われている</li>
+    </ul>
+  </li>
+  <li>DataのTake/Put時には必ずkey nameの指定が必要となる</li>
+</ul>
+
+
+
+</div>
+
+<div class='slide'>
+  <!-- _S9SLIDE_ -->
+<h2 id="リスト単位の通信の構成">リスト単位の通信の構成</h2>
+<ul>
+  <li>指定したkeyのQueueが探索で返される</li>
+  <li>proxyの場合、どのkeyに対してどんなDataを書き込んだかを通信で送信する</li>
 </ul>
 <div style="text-align: center;">
   　<img src="images/socketCom.pdf" alt="socketを通じたレコード送信" width="800" />
@@ -553,31 +559,7 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="main部分によるapi">main部分によるAPI</h2>
-<ul>
-  <li>readの場合(リモート側に読み込みたいファイルが存在する)
-    <ul>
-      <li>(手順1)ローカル側は空のファイルを作成し、socketを持たせる</li>
-      <li>(手順2)リモート側は, ローカル側の持つ空ファイルのproxyを作成する</li>
-      <li>(手順3)リモート側はproxyに対して、目的のファイルのデータをputする</li>
-    </ul>
-  </li>
-  <li>writeの場合(リモート側に書き込みたいファイルが存在する)
-    <ul>
-      <li>(手順1)リモート側は対象ファイルにsocketを持たせる</li>
-      <li>(手順2)ローカル側は対象のファイルに対応するproxyを作成する</li>
-      <li>(手順3)ローカル側はproxyのkeyに対してデータをputする</li>
-    </ul>
-  </li>
-</ul>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h2 id="wordcountの例題">wordCountの例題</h2>
+<h2 id="wordcount例題による通信apiの構築">wordCount例題による通信APIの構築</h2>
 <ul>
   <li>DataGearManagerによるファイル通信APIはWordCount例題を目指して設計した
     <ul>
@@ -596,12 +578,38 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="christieapiによるwordcount">ChristieAPIによるWordCount</h2>
+<h2 id="gearsfile-apiによるwordcount13">GearsFile APIによるWordCount(1/3)</h2>
 <ul>
   <li>FileOpen側とWordCount側でノードが別れる</li>
   <li>(手順1)FileOpen側はRDGMに文字列をputする</li>
   <li>(手順2)WordCount側は処理の後、ackを返信する</li>
+</ul>
+<div style="text-align: center;">
+  　<img src="images/wordCountDGM.pdf" alt="ChristieAPIによるWordCount" width="800" />
+</div>
+
+
+
+</div>
+
+<div class='slide'>
+  <!-- _S9SLIDE_ -->
+<h2 id="gearsfile-apiによるwordcount23">GearsFile APIによるWordCount(2/3)</h2>
+<ul>
   <li>(手順3)1,2をループし、FileOpen側はEoFならフラグを送信する</li>
+</ul>
+<div style="text-align: center;">
+  　<img src="images/wordCountDGM.pdf" alt="ChristieAPIによるWordCount" width="800" />
+</div>
+
+
+
+</div>
+
+<div class='slide'>
+  <!-- _S9SLIDE_ -->
+<h2 id="gearsfile-apiによるwordcount33">GearsFile APIによるWordCount(3/3)</h2>
+<ul>
   <li>(手順4)EoFを受信したWordCountは結果を返信し、双方の処理を終了させる</li>
 </ul>
 <div style="text-align: center;">
@@ -614,16 +622,33 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="これから実装が必要となる機能">これから実装が必要となる機能</h2>
+<h2 id="現在のgearsfile-apiの開発状況">現在のGearsFile APIの開発状況</h2>
 <ul>
-  <li>keyアクセスに対応したファイル通信
+  <li>実装ずみ
     <ul>
-      <li>単一のQueueによる通信は確認が行えた</li>
+      <li>keyアクセスに対応したファイル通信
+        <ul>
+          <li>単一のQueueによる通信の記述</li>
+        </ul>
+      </li>
+      <li>リストとなるTree
+        <ul>
+          <li>赤黒木</li>
+        </ul>
+      </li>
+      <li>atomicな操作が行えるQueue
+        <ul>
+          <li>複数からのアクセス時にデータ整合を保つ</li>
+        </ul>
+      </li>
     </ul>
   </li>
-  <li>ファイル保存</li>
-  <li>バックアップ機能</li>
-  <li>並列処理</li>
+  <li>実装中
+    <ul>
+      <li>keyアクセスが行えるQueueのリスト</li>
+      <li>リスト単位での通信の記述</li>
+    </ul>
+  </li>
 </ul>


@@ -632,22 +657,7 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="gearsosのディレクトリとバックアップ">GearsOSのディレクトリとバックアップ</h2>
-<ul>
-  <li>又吉雄斗による並行研究にて、inodeによるファイルシステムが開発されている</li>
-  <li>赤黒木の非破壊な編集により、ディレクトリの履歴を残すことができる</li>
-</ul>
-<div style="text-align: center;">
-  　<img src="images/nonDestroyTreeEdit.pdf" alt="非破壊的なツリー編集" width="800" />
-</div>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h2 id="生成形の問題点">生成形の問題点</h2>
+<h2 id="gearsosの生成形の問題点">GearsOSの生成形の問題点</h2>
 <ul>
   <li>GearsOSのメタレベルの処理の記述はトランスコンパイラにより行われる</li>
   <li>場合によりメタレベルの記述を行わなくてはならない
@@ -695,12 +705,12 @@
 <h2 id="並列処理構文par-gotoが持つ問題">並列処理構文par gotoが持つ問題</h2>
 <ul>
   <li>par gotoとはGearsOSに実装された並列処理構文である</li>
+  <li>StreamQueueに対するput/takeの並列処理の実装をpar goto構文で試みた</li>
   <li>par gotoはトランスコンパイラへの依存性が高い
     <ul>
       <li>stubCodeGearのように任意な書き換えが行えない</li>
     </ul>
   </li>
-  <li>StreamQueueに対するput/takeの並列処理の実装をpar goto構文で試みた</li>
   <li>特定のCodeGearの宣言のみでしか正常な処理が生成されない
     <ul>
       <li>Interfaceに記述されたAPICodeGearではバグが生じる</li>
@@ -720,13 +730,25 @@
 <ul>
   <li>GearsOSのファイルの設計を行った
     <ul>
-      <li>ファイルの構造の設計</li>
-      <li>socketによる通信部分の実装</li>
-      <li>単純化した通信APIの記述</li>
+      <li>ファイルの構造の設計
+        <ul>
+          <li>DataGear単位での操作が行える</li>
+        </ul>
+      </li>
+      <li>socketによる通信部分の実装
+        <ul>
+          <li>GearsOS上でのソケット通信の記述</li>
+        </ul>
+      </li>
+      <li>APIの段階的な設計記述
+        <ul>
+          <li>Proxyによるファイル通信</li>
+        </ul>
+      </li>
       <li>GearsOSの調査</li>
     </ul>
   </li>
-  <li>ファイルproxyによる通信実現を行いたい</li>
+  <li>Streamのリスト単位での通信の完成</li>
 </ul>


@@ -735,7 +757,7 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="これからの課題">これからの課題</h2>
+<h2 id="将来的な課題">将来的な課題</h2>
 <ul>
   <li>TopoplogyManagerの設計
     <ul>
@@ -770,6 +792,21 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
+<h2 id="gearsosのディレクトリとバックアップ">GearsOSのディレクトリとバックアップ</h2>
+<ul>
+  <li>又吉雄斗による並行研究にて、inodeによるファイルシステムが開発されている</li>
+  <li>赤黒木の非破壊な編集により、ディレクトリの履歴を残すことができる</li>
+</ul>
+<div style="text-align: center;">
+  　<img src="images/nonDestroyTreeEdit.pdf" alt="非破壊的なツリー編集" width="800" />
+</div>
+
+
+
+</div>
+
+<div class='slide'>
+  <!-- _S9SLIDE_ -->
 <h2 id="ファイルqueueに対するapi--peek-">ファイルQueueに対するAPI -Peek-</h2>
 <ul>
   <li>Peek