Mercurial > hg > Papers > 2022 > ikki-master

changeset 19:9e6fd2255ee1

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
tweak slide
author ichikitakahiro <e165713@ie.u-ryukyu.ac.jp>
date Mon, 07 Feb 2022 20:58:17 +0900
parents b0fde43e331b
children 55a0fd236f78
files Paper/master_paper.pdf slide/.DS_Store slide/thesis.html slide/thesis.md slide/thesis.pdf.html
diffstat 5 files changed, 467 insertions(+), 405 deletions(-) [+]
line wrap: on
line diff
Binary file Paper/master_paper.pdf has changed
Binary file slide/.DS_Store has changed
--- a/slide/thesis.html	Mon Feb 07 03:39:50 2022 +0900
+++ b/slide/thesis.html	Mon Feb 07 20:58:17 2022 +0900
@@ -94,7 +94,7 @@
 <h2 id="gearsosとその現状">GearsOSとその現状</h2>
 <ul>
   <li>信頼性の保証と拡張性の高さを目指したOSプロジェクト</li>
-  <li>軽量継続を用いた言語、CbC(Continuation based C)により記述される。</li>
+  <li>軽量継続を用いた言語、CbC(Continuation based C)により記述される</li>
   <li>ノーマルレベルとメタレベルを分離して記述する</li>
   <li>現状では言語フレームワークとしてのみ機能する</li>
   <li>OSとして動作するには多くの機能の開発が必要
@@ -236,14 +236,7 @@
   <li>Implement
     <ul>
       <li>Interfaceの実装</li>
-    </ul>
-  </li>
-  <li>Context
-    <ul>
-      <li>プログラムに使われるCodeGear/DataGearを全て管理する</li>
-      <li>CodeGear/DataGearの格納場所でもある</li>
-      <li>軽量継続中、必ず持ち歩かれる</li>
-      <li>メタレベルなCodeGearからのみ参照される</li>
+      <li>プログラム内で共通して利用したい変数</li>
     </ul>
   </li>
 </ul>
@@ -274,8 +267,18 @@
 <div class='slide'>
   <!-- _S9SLIDE_ -->
 <h2 id="contextとgearの関係性">ContextとGearの関係性</h2>
+<ul>
+  <li>Context
+    <ul>
+      <li>遷移の際にデータを全て記録するオブジェクト</li>
+      <li>プログラムに使われるCodeGear/DataGearを管理する</li>
+      <li>軽量継続中、必ず引数で参照される</li>
+      <li>メタレベルなCodeGearからのみ参照される</li>
+    </ul>
+  </li>
+</ul>
 <div style="text-align: center;">
-　<img src="images/Context_ref.pdf" alt="Contextの参照" width="800" />
+　<img src="images/Context_ref.pdf" alt="Contextの参照" width="900" />
 </div>
 
 
@@ -291,7 +294,7 @@
       <li>トランスコンパイルの際に、メタレベルの記述が行われる
         <ul>
           <li>StubCodeGearの自動生成</li>
-          <li>Gears向けに記述された演算子(par goto ,NEW)の書き換え</li>
+          <li>Gears向けに記述された演算子(par goto、NEW)の書き換え</li>
         </ul>
       </li>
     </ul>
@@ -321,10 +324,10 @@
 <h2 id="分散フレームワークchristie">分散フレームワークChristie</h2>
 <ul>
   <li>Java言語で記述された分散フレームワーク</li>
-  <li>CbCと似てはいるが異なったGearというプログラム概念がある</li>
+  <li>CbCとは異なったGearというプログラム概念がある</li>
   <li>特定のkeyに対する変数データ書き込みにより通信を行う</li>
   <li>自律分散の実現を目指して開発された</li>
-  <li>通信ノードの接続を行うTopologyManagerという機能を持つ</li>
+  <li>TopologyManagerという機能を持つ</li>
 </ul>
 
 
@@ -338,32 +341,26 @@
   <li>CodeGear
     <ul>
       <li>スレッドに相当する</li>
-      <li>処理開始前に任意のDataGearを待ち合わせ、揃ったら処理が実行される</li>
+      <li>任意のkey nameを持つDataGearを待ち合わせ、揃ったら処理が実行される</li>
     </ul>
   </li>
   <li>DataGear
     <ul>
       <li>変数データに相当する</li>
-      <li>型を所持している</li>
-      <li>アノテーションによりデータの参照後の処理が変化する
-        <ul>
-          <li>Take : 参照されたDataGearは削除される</li>
-          <li>Peek : 参照されてもDataGearは削除されない</li>
-        </ul>
-      </li>
+      <li>key nameと変数データのペアで管理される</li>
     </ul>
   </li>
   <li>CodeGearManger
     <ul>
       <li>ノードに相当する</li>
-      <li>DataGearManagerを所持し、それによりCodeGearとDataGearを管理する</li>
+      <li>DataGearManagerを所持し、CodeGearとDataGearを管理する</li>
     </ul>
   </li>
   <li>DataGearManager
     <ul>
       <li>データプールに相当する</li>
-      <li>DataGearのkeyとデータの組み合わせを保持している</li>
-      <li>LocalとRemoteの二種類が存在する</li>
+      <li>DataGearとkeyの組み合わせを保持している</li>
+      <li>LocalDGMとRemoteDGMの二種類が存在する</li>
     </ul>
   </li>
 </ul>
@@ -380,13 +377,13 @@
   <li>LocalDataGearManager (LocalDGM)
     <ul>
       <li>CodeGearManagerが持つ、自身のDataGearPool</li>
-      <li>CodeGear中のDataGearは普段これを参照する</li>
+      <li>DataGearの大半はこれを参照する</li>
     </ul>
   </li>
   <li>RemoteDataGearManager (RemoteDGM)
     <ul>
       <li>他のCodeGearManagerが持つLocalDGMに対応するploxy</li>
-      <li>RemoteDGMに書き込みを行うと、対応したCodeGearManagerが持つLocalDGMに書き込みが行われる</li>
+      <li>書き込みを行うと、対応したCodeGearManagerが持つLocalDGMに書き込みがされる</li>
     </ul>
   </li>
   <li>DataGearManagerによる通信がChristieの通信の要となっている</li>
@@ -409,8 +406,8 @@
       <li>接続されたノードは他のノードを相対的な名前で参照できる(例:Child/parent, right/leftなど)</li>
     </ul>
   </li>
-  <li>TopologyManagerに煩雑な通信接続を任せることができる</li>
 </ul>
+
 <div style="text-align: center;">
 　<img src="images/TopologyManager.pdf" alt="TopologyManager" width="800" />
 </div>
@@ -421,21 +418,21 @@
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="gearsfilesystemの目指す仕様">GearsFileSystemの目指す仕様</h2>
+<h2 id="gearsfilesystemの方針">GearsFileSystemの方針</h2>
 <ul>
   <li>データベース的なレコード操作によるファイルアクセス
     <ul>
       <li>KeyValueStoreに対する書き込み</li>
     </ul>
   </li>
-  <li>ファイルのバックアップの
+  <li>ファイルのバックアップ
     <ul>
       <li>ディレクトリの非破壊的編集とファイルの構成方法</li>
     </ul>
   </li>
   <li>ファイルの型の認識
     <ul>
-      <li>ファイルレコードの構造体の型により認識する</li>
+      <li>ファイルレコードを適切な形の構造体にする</li>
     </ul>
   </li>
   <li>自律分散を目指した分散ファイルシステム
@@ -451,17 +448,18 @@
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="gearsfsのファイル構造13">GearsFSのファイル構造1/3</h2>
+<h2 id="gearsfsのファイル構造14">GearsFSのファイル構造1/4</h2>
 <ul>
-  <li>ファイルのデータは任意の型を持ったレコードとして断続的に分割された状態で保存される
+  <li>ファイルのデータ単位は任意の型を持ったレコード
     <ul>
-      <li>レコードはQueueに保存される</li>
-      <li>ファイルはレコードが先頭から順に読むことで構成される</li>
+      <li>断続的に分割された状態で保存される</li>
+      <li>Queueに保存される</li>
+      <li>レコードを先頭から順に読むことでファイルを構成する</li>
     </ul>
   </li>
   <li>ファイルレコードは構造体で再現される
     <ul>
-      <li>ファイルレコード構造体はGearsDataGearとして利用できる</li>
+      <li>ファイルレコード構造体はGearsのDataGearとして利用できる</li>
       <li>レコードの構造体によりOSはファイルの型を認識する
         <ul>
           <li>ファイルの特性に合わせ、レコードとその構成方法を適した形で構成できる</li>
@@ -481,25 +479,20 @@
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="gearsfsのファイル構造23">GearsFSのファイル構造2/3</h2>
+<h2 id="gearsfsのファイル構造24">GearsFSのファイル構造2/4</h2>
 <ul>
-  <li>GearsOSのファイルはChristieのDataGearManagerの仕組みを用いる</li>
   <li>ファイルの読み込み/書き込みはStreamを通して行われる
     <ul>
       <li>streamも同様にQueueで構成される</li>
-      <li>streamはそれぞれ特定のkey nameをもち、keyを用いることでアクセスが行われる</li>
+      <li>streamはそれぞれ特定のkey nameをもつ</li>
+      <li>keyを用いることでアクセスが行われる</li>
     </ul>
   </li>
-  <li>最低でも、Input/OutputのStreamとファイルデータを保持するmainなQueueの三つで構成される</li>
+  <li>最低で、Input/OutputのStreamとファイルデータを保持するmainなQueueの三つで構成される</li>
   <li>Write : InputStreamに対してレコードをputすれば良い</li>
   <li>Read : OutputStreamからレコードを全てtakeすれば良い</li>
-  <li>GearsOSのファイルは大域的な資源として複数のプロセスより競合的なアクセスが行われる
-    <ul>
-      <li>OutputStreamは複数のアクセスが行われても整合性が保たれる必要がある</li>
-      <li>CAS(Compare And Swap)が採用されたSynchronizedQueueを用いる</li>
-    </ul>
-  </li>
 </ul>
+
 <div style="text-align: center;">
   　<img src="images/GearsFile.pdf" alt="streamによるファイルアクセス" width="800" />
 </div>
@@ -510,11 +503,30 @@
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="gearsfsのファイル構造33">GearsFSのファイル構造3/3</h2>
+<h2 id="gearsfsのファイル構造34">GearsFSのファイル構造3/4</h2>
+<ul>
+  <li>ChristieのDataGearManagerに相当する</li>
+  <li>GearsOSのファイルは大域的な資源である
+    <ul>
+      <li>複数のプロセスより競合的なアクセスが行われる</li>
+      <li>OutputStreamは複数のアクセスが行われても整合性が保たれる必要がある</li>
+      <li>CAS(Compare And Swap)が採用されたSynchronizedQueueを用いる</li>
+    </ul>
+  </li>
+</ul>
+
+
+
+</div>
+
+<div class='slide'>
+  <!-- _S9SLIDE_ -->
+<h2 id="gearsfsのファイル構造44">GearsFSのファイル構造4/4</h2>
 <ul>
   <li>stream、mainQueueはDataGearに相当し、keyによるアクセスが行われる</li>
-  <li>Queueは赤黒木に保持されており、key nameで検索が行われ参照される</li>
-  <li>DGMへ書き込みを行うプロセスは入力するデータに加え対象のkey nameを指定する必要がある</li>
+  <li>Queueは赤黒木に保持される</li>
+  <li>key nameで探索が行われ参照される</li>
+  <li>DGM書き込みは対象のkey nameを指定する</li>
 </ul>
 <div style="text-align: center;">
   　<img src="images/newGearsFile.pdf" alt="DataGearの保存形式" width="800" />
@@ -528,34 +540,87 @@
   <!-- _S9SLIDE_ -->
 <h2 id="遠隔からのファイル操作">遠隔からのファイル操作</h2>
 <ul>
-  <li>GearsOSのファイルはファイルであり、通信そのものにも相当する</li>
+  <li>GearsOSのファイルは、ファイル通信そのものにも相当する</li>
   <li>RemoteDGMの仕組みを用いることで遠隔からのファイル読み込み/書き込みを行う</li>
-  <li>readの場合(リモート側に読み込みたいファイルが存在する)
-    <ul>
-      <li>(手順1)ローカル側はLocalDGMの相当する空のファイルを作成し、socketを持つ</li>
-      <li>(手順2)リモート側はローカルの空ファイルのploxyを作成する</li>
-      <li>(手順3)リモート側はploxyに対してデータをputする</li>
-    </ul>
-  </li>
-  <li>writeの場合(リモート側に書き込みたいファイルが存在する)
-    <ul>
-      <li>(手順1)リモート側はファイルのsocketを持つ</li>
-      <li>(手順2)ローカル側はローカルのファイルに接続し、ploxy(RemoteDGM)を作成する</li>
-      <li>(手順3)ローカル側はploxyのkeyに対してデータをputする</li>
-    </ul>
-  </li>
 </ul>
 
+<div style="text-align: center;">
+  　<img src="images/socketCom.pdf" alt="socketを通じたレコード送信" width="800" />
+</div>
+
 
 
 </div>
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="遠隔からのファイル変更">遠隔からのファイル変更</h2>
-<div style="text-align: center;">
-    　<img src="images/socketCom.pdf" alt="socketを通じたレコード送信" width="800" />
-  </div>
+<h2 id="socketからの受信データ取り出し">socketからの受信データ取り出し</h2>
+<ul>
+  <li>socketはImplementに記述される</li>
+  <li>LocalDGMに相当するファイルは、接続先socketから送信されたデータを取り出す</li>
+  <li>APIとして記述される</li>
+  <li>取り出されたデータは次の継続先でQueueに対してputされる</li>
+</ul>
+
+<pre><code>__code getDataLocalDGMQueue(struct LocalDGMQueue* cQueue, __code next(...), __code whenEOF(...), __code whenError(...)){
+    union Data* recv_data;
+    recv_size = recv(cQueue-&gt;socket, recv_data, sizeof(union Data), 0);
+    if (recv_size == -1) {
+        printf("recv error\n");
+        goto whenError(...);
+    }
+    FileString* fileString = NEW(FileString);
+    fileString = recv_data;
+    if (fileString-&gt;EoF) == 1) {
+        send_buf = 0;
+        send_size = send(cQueue-&gt;socket, &amp;send_buf, 1, 0);
+        if (send_size == -1) {
+            printf("send error\n");
+        }
+        close(cQueue-&gt;buffer);
+        goto whenEOF(...);
+    } else {
+        send_buf = 1;
+        send_size = send(cQueue-&gt;socket, &amp;send_buf, 1, 0);
+        if (send_size == -1) {
+            printf("send error\n");
+            goto whenError(...);
+        }
+    }
+
+    Gearef(context, cQueue)-&gt;data = recv_data;
+    goto putLocalDGMQueue(recv_data, next);
+}
+</code></pre>
+
+
+
+</div>
+
+<div class='slide'>
+  <!-- _S9SLIDE_ -->
+<h2 id="remotedgmのsocketによるデータ送信">RemoteDGMのsocketによるデータ送信</h2>
+<ul>
+  <li>RemoteDGM側はsocketを用いてデータを送信する</li>
+  <li>Queueに対してputされたデータを送信する</li>
+  <li>putCodeGearの直後に呼び出される
+    <pre><code>__code sendDataRemoteDGMQueue(struct RemoteDGMQueue* cQueue, union Data* data, __code next(...), __code whenError(...)){
+  send_size = send(cQueue-&gt;socket, data, sizeof(union Data), 0);
+  if (send_size == -1) {
+      printf("send error\n");
+      goto whenError();
+  }
+
+  recv_size = recv(cQueue-&gt;socket, &amp;recv_buf, 1, 0);
+  if (recv_size == -1) {
+      printf("recv error\n");
+      goto whenError();
+  }
+  goto next(...);
+}
+</code></pre>
+  </li>
+</ul>
 
 
 
@@ -566,16 +631,10 @@
 <h2 id="wordcount例題">WordCount例題</h2>
 <ul>
   <li>ChristieAPIの構成をWordCount例題を通して行った</li>
-  <li>ファイルの中を1行ずつ読み取り、ファイル内の文字数、行列を調べる</li>
-  <li>ファイルの読み込みと文字列のカウントをそれぞれ別ノード上で行うことで、ファイル読み込みとファイルレコードの通信の必要が生じる</li>
-  <li>(手順1)ファイル内文字列を1行ずつWordCount関数へ入力する、これをループ</li>
-  <li>(手順2)ファイル内文字列が無くなった場合(EoF)結果を出力し、終了する</li>
+  <li>ファイルの中の文字列を1行ずつ読み取り、ファイル内の文字数と行数を調べる</li>
+  <li>ファイルの送信と文字列のカウントをそれぞれ別ノード上で行うことで、ファイル読み込みとファイルレコードの通信処理が構成できる</li>
 </ul>
 
-<div style="text-align: center;">
-  　<img src="images/wordCountStates.pdf" alt="WordCountの遷移図" width="800" />
-</div>
-
 
 
 </div>
@@ -600,82 +659,6 @@
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="localdgmのsocketの受信データ取り出し">LocalDGMのsocketの受信データ取り出し</h2>
-<ul>
-  <li>socketはImplementに記述される</li>
-  <li>LocalDGMに相当するファイルは、接続先socketから送信されたデータを取り出す</li>
-  <li>取り出されたデータはInputStreamQueueに対してputされる
-    <pre><code>__code getDataLocalDGMQueue(struct LocalDGMQueue* cQueue, __code next(...), __code whenEOF(...), __code whenError(...)){
-  union Data* recv_data;
-  recv_size = recv(cQueue-&gt;socket, recv_data, sizeof(union Data), 0);
-  if (recv_size == -1) {
-      printf("recv error\n");
-      goto whenError(...);
-  }
-  FileString* fileString = NEW(FileString);
-  fileString = recv_data;
-  if (fileString-&gt;EoF) == 1) {
-      send_buf = 0;
-      send_size = send(cQueue-&gt;socket, &amp;send_buf, 1, 0);
-      if (send_size == -1) {
-          printf("send error\n");
-      }
-      close(cQueue-&gt;buffer);
-      goto whenEOF(...);
-  } else {
-      send_buf = 1;
-      send_size = send(cQueue-&gt;socket, &amp;send_buf, 1, 0);
-      if (send_size == -1) {
-          printf("send error\n");
-          goto whenError(...);
-      }
-  }
-
-  Gearef(context, cQueue)-&gt;data = recv_data;
-  goto putLocalDGMQueue(recv_data, next);
-}
-</code></pre>
-  </li>
-</ul>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h2 id="remotedgmのsocketによるデータ送信">RemoteDGMのsocketによるデータ送信</h2>
-<ul>
-  <li>RemoteDGM側はsocketを用いてデータを送信する</li>
-  <li>Queueに対してputされたデータを送信する
-    <ul>
-      <li>putCodeGearの直後に呼び出される
-        <pre><code>__code sendDataRemoteDGMQueue(struct RemoteDGMQueue* cQueue, union Data* data, __code next(...), __code whenError(...)){
-send_size = send(cQueue-&gt;socket, data, sizeof(union Data), 0);
-if (send_size == -1) {
-    printf("send error\n");
-    goto whenError();
-}
-
-recv_size = recv(cQueue-&gt;socket, &amp;recv_buf, 1, 0);
-if (recv_size == -1) {
-    printf("recv error\n");
-    goto whenError();
-}
-goto next(...);
-}
-</code></pre>
-      </li>
-    </ul>
-  </li>
-</ul>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
 <h2 id="gearsfsのディレクトリ">GearsFSのディレクトリ</h2>
 <ul>
   <li>ディレクトリを赤黒木で実装する</li>
@@ -730,8 +713,8 @@
   <li>par gotoを用いる案
     <ul>
       <li>処理速度が遅い</li>
+      <li>トランスコンパイラへの依存度が高い</li>
       <li>現状バグが存在している</li>
-      <li>トランスコンパイラへの依存度が高い</li>
     </ul>
   </li>
   <li>新しく並列処理を開発する</li>
@@ -790,23 +773,24 @@
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="まとめ">まとめ</h2>
+<h2 id="結論">結論</h2>
 <ul>
   <li>GearsFileSystemの設計
     <ul>
       <li>ファイルの構成方法
         <ul>
-          <li>Queueのリストである</li>
+          <li>keyによってアクセスされるQueueのリスト</li>
         </ul>
       </li>
       <li>ファイル操作API
         <ul>
+          <li>ChristieAPI</li>
           <li>レコード単位で操作される</li>
         </ul>
       </li>
       <li>ファイル送受信の実装
         <ul>
-          <li>ファイルploxy</li>
+          <li>RemoteDGM(ファイルploxy)</li>
         </ul>
       </li>
       <li>ディレクトリの仕組み
@@ -845,14 +829,17 @@
 struct Atomic* atomic;
 } SynchronizedQueue;
 </code></pre>
-    
+  </li>
+</ul>
+
+
 
 </div>
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
 <h2 id="研究成果">研究成果</h2>
-  </li>
+<ul>
   <li>連続するレコードで構成されるGearsOSファイルの設計</li>
   <li>keyアクセスを用いたファイルに対するRead, writeAPI</li>
   <li>赤黒木を用いたディレクトリシステムの構築</li>
@@ -860,13 +847,49 @@
   <li>ploxyを用いたファイルの送受信</li>
 </ul>
 
-<p>##
-&lt;!–</p>
+
+
+</div>
+
+<div class='slide'>
+  <!-- _S9SLIDE_ -->
+<h2 id="api手順">API手順</h2>
 <ul>
-  <li>RocalDGMを立ち上げるにはDataSegmentクラスが提供する、connectメソッドを用い、接続したいポートのipアドレスとport番号、そして任意のManager名を指定することで立ち上げる。
-–&gt;</li>
+  <li>readの場合(リモート側に読み込みたいファイルが存在する)
+    <ul>
+      <li>(手順1)ローカル側はLocalDGMの相当する空のファイルを作成し、socketを持つ</li>
+      <li>(手順2)リモート側はローカルの空ファイルのploxyを作成する</li>
+      <li>(手順3)リモート側はploxyに対してデータをputする</li>
+    </ul>
+  </li>
+  <li>writeの場合(リモート側に書き込みたいファイルが存在する)
+    <ul>
+      <li>(手順1)リモート側は対象ファイルにsocketを持たせる</li>
+      <li>(手順2)ローカル側は対象のファイルに対応するploxy(RemoteDGM)を作成する</li>
+      <li>(手順3)ローカル側はploxyのkeyに対してデータをputする</li>
+    </ul>
+  </li>
 </ul>
 
+
+
+</div>
+
+<div class='slide'>
+  <!-- _S9SLIDE_ -->
+<h2 id="wordcount手順">WordCount手順</h2>
+<ul>
+  <li>(手順1)ファイル内文字列を1行ずつWordCount関数へ入力する、これをループ</li>
+  <li>(手順2)ファイル内文字列が無くなった場合(EoF)結果を出力し、終了する</li>
+</ul>
+<div style="text-align: center;">
+  　<img src="images/wordCountStates.pdf" alt="WordCountの遷移図" width="800" />
+</div>
+
+<!--
+- RocalDGMを立ち上げるにはDataSegmentクラスが提供する、connectメソッドを用い、接続したいポートのipアドレスとport番号、そして任意のManager名を指定することで立ち上げる。
+-->
+
 </div>
 
 
--- a/slide/thesis.md	Mon Feb 07 03:39:50 2022 +0900
+++ b/slide/thesis.md	Mon Feb 07 20:58:17 2022 +0900
@@ -4,14 +4,16 @@
 lang: Japanese
 code-engine: coderay
 
+
 ## GearsOSとその現状
 - 信頼性の保証と拡張性の高さを目指したOSプロジェクト
-- 軽量継続を用いた言語、CbC(Continuation based C)により記述される。
+- 軽量継続を用いた言語、CbC(Continuation based C)により記述される
 - ノーマルレベルとメタレベルを分離して記述する
 - 現状では言語フレームワークとしてのみ機能する
 - OSとして動作するには多くの機能の開発が必要
   - その中の一つにファイルシステムが挙げられる
 
+
 ## 従来の物より発展した分散ファイルシステムの設計
 - データベース的なレコード操作によるアクセス
   - ファイルに対する全ての操作がTransactionとなる
@@ -23,7 +25,6 @@
   - 分散フレームワークChristieの仕組みにより実現する
 
 
-
 ## CbC (Continuation based C)
 - C言語の拡張言語である
 - 関数に代わる軽量継続をメインに記述する
@@ -80,11 +81,7 @@
   - コンパイル時にContext(後述)に書き込まれる
 - Implement
   - Interfaceの実装
-- Context
-  - プログラムに使われるCodeGear/DataGearを全て管理する
-  - CodeGear/DataGearの格納場所でもある
-  - 軽量継続中、必ず持ち歩かれる
-  - メタレベルなCodeGearからのみ参照される
+  - プログラム内で共通して利用したい変数
 
 ```
 typedef struct Queue<>{
@@ -108,15 +105,20 @@
 ```
 
 ## ContextとGearの関係性
+- Context
+  - 遷移の際にデータを全て記録するオブジェクト
+  - プログラムに使われるCodeGear/DataGearを管理する
+  - 軽量継続中、必ず引数で参照される
+  - メタレベルなCodeGearからのみ参照される
 <div style="text-align: center;">
-　<img src="images/Context_ref.pdf" alt="Contextの参照" width="800">
+　<img src="images/Context_ref.pdf" alt="Contextの参照" width="900">
 </div>
 
 ## GearsOSのトランスコンパイラ
 - CbCプログラムはトランスコンパイルによりC言語プログラムに書き換えられる
   - トランスコンパイルの際に、メタレベルの記述が行われる
     - StubCodeGearの自動生成
-    - Gears向けに記述された演算子(par goto ,NEW)の書き換え
+    - Gears向けに記述された演算子(par goto、NEW)の書き換え
 - StubCodeGearはCbCプログラムへ直に記述することでユーザーの任意の処理に変えられる
 ```
 __code putSynchronizedQueue_stub(struct Context* context) {
@@ -135,37 +137,34 @@
 
 ## 分散フレームワークChristie
 - Java言語で記述された分散フレームワーク
-- CbCと似てはいるが異なったGearというプログラム概念がある
+- CbCとは異なったGearというプログラム概念がある
 - 特定のkeyに対する変数データ書き込みにより通信を行う
 - 自律分散の実現を目指して開発された
-- 通信ノードの接続を行うTopologyManagerという機能を持つ
+- TopologyManagerという機能を持つ
 
 ## ChristieのGear
 - CodeGear
   - スレッドに相当する
-  - 処理開始前に任意のDataGearを待ち合わせ、揃ったら処理が実行される
+  - 任意のkey nameを持つDataGearを待ち合わせ、揃ったら処理が実行される
 - DataGear
   - 変数データに相当する
-  - 型を所持している
-  - アノテーションによりデータの参照後の処理が変化する
-    - Take : 参照されたDataGearは削除される
-    - Peek : 参照されてもDataGearは削除されない
+  - key nameと変数データのペアで管理される
 - CodeGearManger
   - ノードに相当する
-  - DataGearManagerを所持し、それによりCodeGearとDataGearを管理する
+  - DataGearManagerを所持し、CodeGearとDataGearを管理する
 - DataGearManager
   - データプールに相当する
-  - DataGearのkeyとデータの組み合わせを保持している
-  - LocalとRemoteの二種類が存在する
+  - DataGearとkeyの組み合わせを保持している
+  - LocalDGMとRemoteDGMの二種類が存在する
 
 ## DataGearManagerによる通信
 - ChristieではDataGearの送受信によりノードどうしの通信を行う
 - LocalDataGearManager (LocalDGM)
   - CodeGearManagerが持つ、自身のDataGearPool
-  - CodeGear中のDataGearは普段これを参照する
+  - DataGearの大半はこれを参照する
 - RemoteDataGearManager (RemoteDGM)
   - 他のCodeGearManagerが持つLocalDGMに対応するploxy
-  - RemoteDGMに書き込みを行うと、対応したCodeGearManagerが持つLocalDGMに書き込みが行われる
+  - 書き込みを行うと、対応したCodeGearManagerが持つLocalDGMに書き込みがされる
 - DataGearManagerによる通信がChristieの通信の要となっている
 <div style="text-align: center;">
 　<img src="images/Remote_DataGearManager.pdf" alt="RemoteDGMの関係図" width="800">
@@ -175,27 +174,28 @@
 - 参加を表明したノードに対して任意の形のTopologyに接続する
   - 接続 = RemoteDGMを作成する
   - 接続されたノードは他のノードを相対的な名前で参照できる(例:Child/parent, right/leftなど)
-- TopologyManagerに煩雑な通信接続を任せることができる
+
 <div style="text-align: center;">
 　<img src="images/TopologyManager.pdf" alt=TopologyManager width="800">
 </div>
 
-## GearsFileSystemの目指す仕様
+## GearsFileSystemの方針
 - データベース的なレコード操作によるファイルアクセス
   - KeyValueStoreに対する書き込み
-- ファイルのバックアップの
+- ファイルのバックアップ
   - ディレクトリの非破壊的編集とファイルの構成方法
 - ファイルの型の認識
-  - ファイルレコードの構造体の型により認識する
+  - ファイルレコードを適切な形の構造体にする
 - 自律分散を目指した分散ファイルシステム
   - プロトコルを用いないChristieAPI
 
-## GearsFSのファイル構造1/3
-- ファイルのデータは任意の型を持ったレコードとして断続的に分割された状態で保存される
-  - レコードはQueueに保存される
-  - ファイルはレコードが先頭から順に読むことで構成される
+## GearsFSのファイル構造1/4
+- ファイルのデータ単位は任意の型を持ったレコード
+  - 断続的に分割された状態で保存される
+  - Queueに保存される
+  - レコードを先頭から順に読むことでファイルを構成する
 - ファイルレコードは構造体で再現される
-  - ファイルレコード構造体はGearsDataGearとして利用できる
+  - ファイルレコード構造体はGearsのDataGearとして利用できる
   - レコードの構造体によりOSはファイルの型を認識する
     - ファイルの特性に合わせ、レコードとその構成方法を適した形で構成できる
 
@@ -203,74 +203,51 @@
   　<img src="images/QueueElement.pdf" alt=Queueの構造 width="800">
 </div>
 
-## GearsFSのファイル構造2/3
-- GearsOSのファイルはChristieのDataGearManagerの仕組みを用いる
+## GearsFSのファイル構造2/4
 - ファイルの読み込み/書き込みはStreamを通して行われる
   - streamも同様にQueueで構成される
-  - streamはそれぞれ特定のkey nameをもち、keyを用いることでアクセスが行われる
-- 最低でも、Input/OutputのStreamとファイルデータを保持するmainなQueueの三つで構成される
+  - streamはそれぞれ特定のkey nameをもつ
+  - keyを用いることでアクセスが行われる
+- 最低で、Input/OutputのStreamとファイルデータを保持するmainなQueueの三つで構成される
 - Write : InputStreamに対してレコードをputすれば良い
 - Read : OutputStreamからレコードを全てtakeすれば良い
-- GearsOSのファイルは大域的な資源として複数のプロセスより競合的なアクセスが行われる
-  - OutputStreamは複数のアクセスが行われても整合性が保たれる必要がある
-  - CAS(Compare And Swap)が採用されたSynchronizedQueueを用いる
+
 <div style="text-align: center;">
   　<img src="images/GearsFile.pdf" alt= streamによるファイルアクセス width="800">
 </div>
 
-## GearsFSのファイル構造3/3
+
+## GearsFSのファイル構造3/4
+- ChristieのDataGearManagerに相当する
+- GearsOSのファイルは大域的な資源である
+  - 複数のプロセスより競合的なアクセスが行われる
+  - OutputStreamは複数のアクセスが行われても整合性が保たれる必要がある
+  - CAS(Compare And Swap)が採用されたSynchronizedQueueを用いる
+
+## GearsFSのファイル構造4/4
 - stream、mainQueueはDataGearに相当し、keyによるアクセスが行われる
-- Queueは赤黒木に保持されており、key nameで検索が行われ参照される
-- DGMへ書き込みを行うプロセスは入力するデータに加え対象のkey nameを指定する必要がある
+- Queueは赤黒木に保持される
+- key nameで探索が行われ参照される
+- DGM書き込みは対象のkey nameを指定する
 <div style="text-align: center;">
   　<img src="images/newGearsFile.pdf" alt= DataGearの保存形式 width="800">
 </div>
 
-
 ## 遠隔からのファイル操作
-- GearsOSのファイルはファイルであり、通信そのものにも相当する
+- GearsOSのファイルは、ファイル通信そのものにも相当する
 - RemoteDGMの仕組みを用いることで遠隔からのファイル読み込み/書き込みを行う
-- readの場合(リモート側に読み込みたいファイルが存在する)
-  - (手順1)ローカル側はLocalDGMの相当する空のファイルを作成し、socketを持つ
-  - (手順2)リモート側はローカルの空ファイルのploxyを作成する
-  - (手順3)リモート側はploxyに対してデータをputする
-- writeの場合(リモート側に書き込みたいファイルが存在する)
-  - (手順1)リモート側はファイルのsocketを持つ
-  - (手順2)ローカル側はローカルのファイルに接続し、ploxy(RemoteDGM)を作成する
-  - (手順3)ローカル側はploxyのkeyに対してデータをputする
-
-## 遠隔からのファイル変更
-  <div style="text-align: center;">
-    　<img src="images/socketCom.pdf" alt=socketを通じたレコード送信 width="800">
-  </div>
-
-
-## WordCount例題
-- ChristieAPIの構成をWordCount例題を通して行った
-- ファイルの中を1行ずつ読み取り、ファイル内の文字数、行列を調べる
-- ファイルの読み込みと文字列のカウントをそれぞれ別ノード上で行うことで、ファイル読み込みとファイルレコードの通信の必要が生じる
-- (手順1)ファイル内文字列を1行ずつWordCount関数へ入力する、これをループ
-- (手順2)ファイル内文字列が無くなった場合(EoF)結果を出力し、終了する
 
 <div style="text-align: center;">
-  　<img src="images/wordCountStates.pdf" alt=WordCountの遷移図 width="800">
+  　<img src="images/socketCom.pdf" alt=socketを通じたレコード送信 width="800">
 </div>
 
 
-## ChristieAPIによるWordCount
-- FileOpen側とWordCount側でノードが別れる
-- (手順1)FileOpen側はRDGMに文字列をputする
-- (手順2)WordCount側は処理の後、ackを返信する
-- (手順3)1,2をループし、FileOpen側はEoFならフラグを送信する
-- (手順4)EoFを受信したWordCountは結果を返信し、双方の処理を終了させる
-<div style="text-align: center;">
-  　<img src="images/wordCountDGM.pdf" alt=ChristieAPIによるWordCount width="800">
-</div>
-
-## LocalDGMのsocketの受信データ取り出し
+## socketからの受信データ取り出し
 - socketはImplementに記述される
 - LocalDGMに相当するファイルは、接続先socketから送信されたデータを取り出す
-- 取り出されたデータはInputStreamQueueに対してputされる
+- APIとして記述される
+- 取り出されたデータは次の継続先でQueueに対してputされる
+
 ```
 __code getDataLocalDGMQueue(struct LocalDGMQueue* cQueue, __code next(...), __code whenEOF(...), __code whenError(...)){
     union Data* recv_data;
@@ -306,7 +283,7 @@
 ## RemoteDGMのsocketによるデータ送信
 - RemoteDGM側はsocketを用いてデータを送信する
 - Queueに対してputされたデータを送信する
-  - putCodeGearの直後に呼び出される
+- putCodeGearの直後に呼び出される
 ```
 __code sendDataRemoteDGMQueue(struct RemoteDGMQueue* cQueue, union Data* data, __code next(...), __code whenError(...)){
     send_size = send(cQueue->socket, data, sizeof(union Data), 0);
@@ -324,6 +301,24 @@
 }
 ```
 
+
+## WordCount例題
+- ChristieAPIの構成をWordCount例題を通して行った
+- ファイルの中の文字列を1行ずつ読み取り、ファイル内の文字数と行数を調べる
+- ファイルの送信と文字列のカウントをそれぞれ別ノード上で行うことで、ファイル読み込みとファイルレコードの通信処理が構成できる
+
+## ChristieAPIによるWordCount
+- FileOpen側とWordCount側でノードが別れる
+- (手順1)FileOpen側はRDGMに文字列をputする
+- (手順2)WordCount側は処理の後、ackを返信する
+- (手順3)1,2をループし、FileOpen側はEoFならフラグを送信する
+- (手順4)EoFを受信したWordCountは結果を返信し、双方の処理を終了させる
+<div style="text-align: center;">
+  　<img src="images/wordCountDGM.pdf" alt=ChristieAPIによるWordCount width="800">
+</div>
+
+
+
 ## GearsFSのディレクトリ
 - ディレクトリを赤黒木で実装する
 - 赤黒木のノードとしてファイル/ディレクトリが保存される
@@ -332,6 +327,7 @@
   　<img src="images/GearsDirectory.pdf" alt=GearsOSのディレクトリ width="500">
 </div>
 
+
 ## GearsFSのバックアップ(1/2)
 - ディレクトリツリーを非破壊的な編集で更新する
 - 木構造の編集前の構造が履歴となる
@@ -340,17 +336,19 @@
   　<img src="images/nonDestroyTreeEdit.pdf" alt=非破壊的なツリー編集 width="800">
 </div>
 
+
 ## GearsFSのバックアップ(2/2)
 - ファイルレコードを変更差分として構成する
   - GithubやMercurialのようなバージョン管理が行える
   - 特定の日時までのレコードを読めばよい
 - 定期的なファイルの再構築が必要
 
+
 ## GearsFSの並列処理
 - par gotoを用いる案
   - 処理速度が遅い
+  - トランスコンパイラへの依存度が高い
   - 現状バグが存在している
-  - トランスコンパイラへの依存度が高い
 - 新しく並列処理を開発する
 
 ## GearsOSの問題点
@@ -372,15 +370,15 @@
   - par gotoの改良
   - 新たな案を実装する
 
-
-## まとめ
+## 結論
 - GearsFileSystemの設計
   - ファイルの構成方法
-    - Queueのリストである
+    - keyによってアクセスされるQueueのリスト
   - ファイル操作API
+    - ChristieAPI
     - レコード単位で操作される
   - ファイル送受信の実装
-    - ファイルploxy
+    -  RemoteDGM(ファイルploxy)
   - ディレクトリの仕組み
     - 赤黒木を用いる
     - 非破壊的な編集によるログ
@@ -401,6 +399,8 @@
   struct Atomic* atomic;
 } SynchronizedQueue;
 ```
+
+
 ## 研究成果
 - 連続するレコードで構成されるGearsOSファイルの設計
 - keyアクセスを用いたファイルに対するRead, writeAPI
@@ -408,7 +408,23 @@
 - ファイルのバックアップ考察
 - ploxyを用いたファイルの送受信
 
-##
+## API手順
+- readの場合(リモート側に読み込みたいファイルが存在する)
+  - (手順1)ローカル側はLocalDGMの相当する空のファイルを作成し、socketを持つ
+  - (手順2)リモート側はローカルの空ファイルのploxyを作成する
+  - (手順3)リモート側はploxyに対してデータをputする
+- writeの場合(リモート側に書き込みたいファイルが存在する)
+  - (手順1)リモート側は対象ファイルにsocketを持たせる
+  - (手順2)ローカル側は対象のファイルに対応するploxy(RemoteDGM)を作成する
+  - (手順3)ローカル側はploxyのkeyに対してデータをputする
+
+## WordCount手順
+- (手順1)ファイル内文字列を1行ずつWordCount関数へ入力する、これをループ
+- (手順2)ファイル内文字列が無くなった場合(EoF)結果を出力し、終了する
+<div style="text-align: center;">
+  　<img src="images/wordCountStates.pdf" alt=WordCountの遷移図 width="800">
+</div>
+
 <!--
 - RocalDGMを立ち上げるにはDataSegmentクラスが提供する、connectメソッドを用い、接続したいポートのipアドレスとport番号、そして任意のManager名を指定することで立ち上げる。
 -->
--- a/slide/thesis.pdf.html	Mon Feb 07 03:39:50 2022 +0900
+++ b/slide/thesis.pdf.html	Mon Feb 07 20:58:17 2022 +0900
@@ -78,7 +78,7 @@
 <h2 id="gearsosとその現状">GearsOSとその現状</h2>
 <ul>
   <li>信頼性の保証と拡張性の高さを目指したOSプロジェクト</li>
-  <li>軽量継続を用いた言語、CbC(Continuation based C)により記述される。</li>
+  <li>軽量継続を用いた言語、CbC(Continuation based C)により記述される</li>
   <li>ノーマルレベルとメタレベルを分離して記述する</li>
   <li>現状では言語フレームワークとしてのみ機能する</li>
   <li>OSとして動作するには多くの機能の開発が必要
@@ -220,14 +220,7 @@
   <li>Implement
     <ul>
       <li>Interfaceの実装</li>
-    </ul>
-  </li>
-  <li>Context
-    <ul>
-      <li>プログラムに使われるCodeGear/DataGearを全て管理する</li>
-      <li>CodeGear/DataGearの格納場所でもある</li>
-      <li>軽量継続中、必ず持ち歩かれる</li>
-      <li>メタレベルなCodeGearからのみ参照される</li>
+      <li>プログラム内で共通して利用したい変数</li>
     </ul>
   </li>
 </ul>
@@ -258,8 +251,18 @@
 <div class='slide'>
   <!-- _S9SLIDE_ -->
 <h2 id="contextとgearの関係性">ContextとGearの関係性</h2>
+<ul>
+  <li>Context
+    <ul>
+      <li>遷移の際にデータを全て記録するオブジェクト</li>
+      <li>プログラムに使われるCodeGear/DataGearを管理する</li>
+      <li>軽量継続中、必ず引数で参照される</li>
+      <li>メタレベルなCodeGearからのみ参照される</li>
+    </ul>
+  </li>
+</ul>
 <div style="text-align: center;">
-　<img src="images/Context_ref.pdf" alt="Contextの参照" width="800" />
+　<img src="images/Context_ref.pdf" alt="Contextの参照" width="900" />
 </div>
 
 
@@ -275,7 +278,7 @@
       <li>トランスコンパイルの際に、メタレベルの記述が行われる
         <ul>
           <li>StubCodeGearの自動生成</li>
-          <li>Gears向けに記述された演算子(par goto ,NEW)の書き換え</li>
+          <li>Gears向けに記述された演算子(par goto、NEW)の書き換え</li>
         </ul>
       </li>
     </ul>
@@ -305,10 +308,10 @@
 <h2 id="分散フレームワークchristie">分散フレームワークChristie</h2>
 <ul>
   <li>Java言語で記述された分散フレームワーク</li>
-  <li>CbCと似てはいるが異なったGearというプログラム概念がある</li>
+  <li>CbCとは異なったGearというプログラム概念がある</li>
   <li>特定のkeyに対する変数データ書き込みにより通信を行う</li>
   <li>自律分散の実現を目指して開発された</li>
-  <li>通信ノードの接続を行うTopologyManagerという機能を持つ</li>
+  <li>TopologyManagerという機能を持つ</li>
 </ul>
 
 
@@ -322,32 +325,26 @@
   <li>CodeGear
     <ul>
       <li>スレッドに相当する</li>
-      <li>処理開始前に任意のDataGearを待ち合わせ、揃ったら処理が実行される</li>
+      <li>任意のkey nameを持つDataGearを待ち合わせ、揃ったら処理が実行される</li>
     </ul>
   </li>
   <li>DataGear
     <ul>
       <li>変数データに相当する</li>
-      <li>型を所持している</li>
-      <li>アノテーションによりデータの参照後の処理が変化する
-        <ul>
-          <li>Take : 参照されたDataGearは削除される</li>
-          <li>Peek : 参照されてもDataGearは削除されない</li>
-        </ul>
-      </li>
+      <li>key nameと変数データのペアで管理される</li>
     </ul>
   </li>
   <li>CodeGearManger
     <ul>
       <li>ノードに相当する</li>
-      <li>DataGearManagerを所持し、それによりCodeGearとDataGearを管理する</li>
+      <li>DataGearManagerを所持し、CodeGearとDataGearを管理する</li>
     </ul>
   </li>
   <li>DataGearManager
     <ul>
       <li>データプールに相当する</li>
-      <li>DataGearのkeyとデータの組み合わせを保持している</li>
-      <li>LocalとRemoteの二種類が存在する</li>
+      <li>DataGearとkeyの組み合わせを保持している</li>
+      <li>LocalDGMとRemoteDGMの二種類が存在する</li>
     </ul>
   </li>
 </ul>
@@ -364,13 +361,13 @@
   <li>LocalDataGearManager (LocalDGM)
     <ul>
       <li>CodeGearManagerが持つ、自身のDataGearPool</li>
-      <li>CodeGear中のDataGearは普段これを参照する</li>
+      <li>DataGearの大半はこれを参照する</li>
     </ul>
   </li>
   <li>RemoteDataGearManager (RemoteDGM)
     <ul>
       <li>他のCodeGearManagerが持つLocalDGMに対応するploxy</li>
-      <li>RemoteDGMに書き込みを行うと、対応したCodeGearManagerが持つLocalDGMに書き込みが行われる</li>
+      <li>書き込みを行うと、対応したCodeGearManagerが持つLocalDGMに書き込みがされる</li>
     </ul>
   </li>
   <li>DataGearManagerによる通信がChristieの通信の要となっている</li>
@@ -393,8 +390,8 @@
       <li>接続されたノードは他のノードを相対的な名前で参照できる(例:Child/parent, right/leftなど)</li>
     </ul>
   </li>
-  <li>TopologyManagerに煩雑な通信接続を任せることができる</li>
 </ul>
+
 <div style="text-align: center;">
 　<img src="images/TopologyManager.pdf" alt="TopologyManager" width="800" />
 </div>
@@ -405,21 +402,21 @@
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="gearsfilesystemの目指す仕様">GearsFileSystemの目指す仕様</h2>
+<h2 id="gearsfilesystemの方針">GearsFileSystemの方針</h2>
 <ul>
   <li>データベース的なレコード操作によるファイルアクセス
     <ul>
       <li>KeyValueStoreに対する書き込み</li>
     </ul>
   </li>
-  <li>ファイルのバックアップの
+  <li>ファイルのバックアップ
     <ul>
       <li>ディレクトリの非破壊的編集とファイルの構成方法</li>
     </ul>
   </li>
   <li>ファイルの型の認識
     <ul>
-      <li>ファイルレコードの構造体の型により認識する</li>
+      <li>ファイルレコードを適切な形の構造体にする</li>
     </ul>
   </li>
   <li>自律分散を目指した分散ファイルシステム
@@ -435,17 +432,18 @@
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="gearsfsのファイル構造13">GearsFSのファイル構造1/3</h2>
+<h2 id="gearsfsのファイル構造14">GearsFSのファイル構造1/4</h2>
 <ul>
-  <li>ファイルのデータは任意の型を持ったレコードとして断続的に分割された状態で保存される
+  <li>ファイルのデータ単位は任意の型を持ったレコード
     <ul>
-      <li>レコードはQueueに保存される</li>
-      <li>ファイルはレコードが先頭から順に読むことで構成される</li>
+      <li>断続的に分割された状態で保存される</li>
+      <li>Queueに保存される</li>
+      <li>レコードを先頭から順に読むことでファイルを構成する</li>
     </ul>
   </li>
   <li>ファイルレコードは構造体で再現される
     <ul>
-      <li>ファイルレコード構造体はGearsDataGearとして利用できる</li>
+      <li>ファイルレコード構造体はGearsのDataGearとして利用できる</li>
       <li>レコードの構造体によりOSはファイルの型を認識する
         <ul>
           <li>ファイルの特性に合わせ、レコードとその構成方法を適した形で構成できる</li>
@@ -465,25 +463,20 @@
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="gearsfsのファイル構造23">GearsFSのファイル構造2/3</h2>
+<h2 id="gearsfsのファイル構造24">GearsFSのファイル構造2/4</h2>
 <ul>
-  <li>GearsOSのファイルはChristieのDataGearManagerの仕組みを用いる</li>
   <li>ファイルの読み込み/書き込みはStreamを通して行われる
     <ul>
       <li>streamも同様にQueueで構成される</li>
-      <li>streamはそれぞれ特定のkey nameをもち、keyを用いることでアクセスが行われる</li>
+      <li>streamはそれぞれ特定のkey nameをもつ</li>
+      <li>keyを用いることでアクセスが行われる</li>
     </ul>
   </li>
-  <li>最低でも、Input/OutputのStreamとファイルデータを保持するmainなQueueの三つで構成される</li>
+  <li>最低で、Input/OutputのStreamとファイルデータを保持するmainなQueueの三つで構成される</li>
   <li>Write : InputStreamに対してレコードをputすれば良い</li>
   <li>Read : OutputStreamからレコードを全てtakeすれば良い</li>
-  <li>GearsOSのファイルは大域的な資源として複数のプロセスより競合的なアクセスが行われる
-    <ul>
-      <li>OutputStreamは複数のアクセスが行われても整合性が保たれる必要がある</li>
-      <li>CAS(Compare And Swap)が採用されたSynchronizedQueueを用いる</li>
-    </ul>
-  </li>
 </ul>
+
 <div style="text-align: center;">
   　<img src="images/GearsFile.pdf" alt="streamによるファイルアクセス" width="800" />
 </div>
@@ -494,11 +487,30 @@
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="gearsfsのファイル構造33">GearsFSのファイル構造3/3</h2>
+<h2 id="gearsfsのファイル構造34">GearsFSのファイル構造3/4</h2>
+<ul>
+  <li>ChristieのDataGearManagerに相当する</li>
+  <li>GearsOSのファイルは大域的な資源である
+    <ul>
+      <li>複数のプロセスより競合的なアクセスが行われる</li>
+      <li>OutputStreamは複数のアクセスが行われても整合性が保たれる必要がある</li>
+      <li>CAS(Compare And Swap)が採用されたSynchronizedQueueを用いる</li>
+    </ul>
+  </li>
+</ul>
+
+
+
+</div>
+
+<div class='slide'>
+  <!-- _S9SLIDE_ -->
+<h2 id="gearsfsのファイル構造44">GearsFSのファイル構造4/4</h2>
 <ul>
   <li>stream、mainQueueはDataGearに相当し、keyによるアクセスが行われる</li>
-  <li>Queueは赤黒木に保持されており、key nameで検索が行われ参照される</li>
-  <li>DGMへ書き込みを行うプロセスは入力するデータに加え対象のkey nameを指定する必要がある</li>
+  <li>Queueは赤黒木に保持される</li>
+  <li>key nameで探索が行われ参照される</li>
+  <li>DGM書き込みは対象のkey nameを指定する</li>
 </ul>
 <div style="text-align: center;">
   　<img src="images/newGearsFile.pdf" alt="DataGearの保存形式" width="800" />
@@ -512,34 +524,87 @@
   <!-- _S9SLIDE_ -->
 <h2 id="遠隔からのファイル操作">遠隔からのファイル操作</h2>
 <ul>
-  <li>GearsOSのファイルはファイルであり、通信そのものにも相当する</li>
+  <li>GearsOSのファイルは、ファイル通信そのものにも相当する</li>
   <li>RemoteDGMの仕組みを用いることで遠隔からのファイル読み込み/書き込みを行う</li>
-  <li>readの場合(リモート側に読み込みたいファイルが存在する)
-    <ul>
-      <li>(手順1)ローカル側はLocalDGMの相当する空のファイルを作成し、socketを持つ</li>
-      <li>(手順2)リモート側はローカルの空ファイルのploxyを作成する</li>
-      <li>(手順3)リモート側はploxyに対してデータをputする</li>
-    </ul>
-  </li>
-  <li>writeの場合(リモート側に書き込みたいファイルが存在する)
-    <ul>
-      <li>(手順1)リモート側はファイルのsocketを持つ</li>
-      <li>(手順2)ローカル側はローカルのファイルに接続し、ploxy(RemoteDGM)を作成する</li>
-      <li>(手順3)ローカル側はploxyのkeyに対してデータをputする</li>
-    </ul>
-  </li>
 </ul>
 
+<div style="text-align: center;">
+  　<img src="images/socketCom.pdf" alt="socketを通じたレコード送信" width="800" />
+</div>
+
 
 
 </div>
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="遠隔からのファイル変更">遠隔からのファイル変更</h2>
-<div style="text-align: center;">
-    　<img src="images/socketCom.pdf" alt="socketを通じたレコード送信" width="800" />
-  </div>
+<h2 id="socketからの受信データ取り出し">socketからの受信データ取り出し</h2>
+<ul>
+  <li>socketはImplementに記述される</li>
+  <li>LocalDGMに相当するファイルは、接続先socketから送信されたデータを取り出す</li>
+  <li>APIとして記述される</li>
+  <li>取り出されたデータは次の継続先でQueueに対してputされる</li>
+</ul>
+
+<pre><code>__code getDataLocalDGMQueue(struct LocalDGMQueue* cQueue, __code next(...), __code whenEOF(...), __code whenError(...)){
+    union Data* recv_data;
+    recv_size = recv(cQueue-&gt;socket, recv_data, sizeof(union Data), 0);
+    if (recv_size == -1) {
+        printf("recv error\n");
+        goto whenError(...);
+    }
+    FileString* fileString = NEW(FileString);
+    fileString = recv_data;
+    if (fileString-&gt;EoF) == 1) {
+        send_buf = 0;
+        send_size = send(cQueue-&gt;socket, &amp;send_buf, 1, 0);
+        if (send_size == -1) {
+            printf("send error\n");
+        }
+        close(cQueue-&gt;buffer);
+        goto whenEOF(...);
+    } else {
+        send_buf = 1;
+        send_size = send(cQueue-&gt;socket, &amp;send_buf, 1, 0);
+        if (send_size == -1) {
+            printf("send error\n");
+            goto whenError(...);
+        }
+    }
+
+    Gearef(context, cQueue)-&gt;data = recv_data;
+    goto putLocalDGMQueue(recv_data, next);
+}
+</code></pre>
+
+
+
+</div>
+
+<div class='slide'>
+  <!-- _S9SLIDE_ -->
+<h2 id="remotedgmのsocketによるデータ送信">RemoteDGMのsocketによるデータ送信</h2>
+<ul>
+  <li>RemoteDGM側はsocketを用いてデータを送信する</li>
+  <li>Queueに対してputされたデータを送信する</li>
+  <li>putCodeGearの直後に呼び出される
+    <pre><code>__code sendDataRemoteDGMQueue(struct RemoteDGMQueue* cQueue, union Data* data, __code next(...), __code whenError(...)){
+  send_size = send(cQueue-&gt;socket, data, sizeof(union Data), 0);
+  if (send_size == -1) {
+      printf("send error\n");
+      goto whenError();
+  }
+
+  recv_size = recv(cQueue-&gt;socket, &amp;recv_buf, 1, 0);
+  if (recv_size == -1) {
+      printf("recv error\n");
+      goto whenError();
+  }
+  goto next(...);
+}
+</code></pre>
+  </li>
+</ul>
 
 
 
@@ -550,16 +615,10 @@
 <h2 id="wordcount例題">WordCount例題</h2>
 <ul>
   <li>ChristieAPIの構成をWordCount例題を通して行った</li>
-  <li>ファイルの中を1行ずつ読み取り、ファイル内の文字数、行列を調べる</li>
-  <li>ファイルの読み込みと文字列のカウントをそれぞれ別ノード上で行うことで、ファイル読み込みとファイルレコードの通信の必要が生じる</li>
-  <li>(手順1)ファイル内文字列を1行ずつWordCount関数へ入力する、これをループ</li>
-  <li>(手順2)ファイル内文字列が無くなった場合(EoF)結果を出力し、終了する</li>
+  <li>ファイルの中の文字列を1行ずつ読み取り、ファイル内の文字数と行数を調べる</li>
+  <li>ファイルの送信と文字列のカウントをそれぞれ別ノード上で行うことで、ファイル読み込みとファイルレコードの通信処理が構成できる</li>
 </ul>
 
-<div style="text-align: center;">
-  　<img src="images/wordCountStates.pdf" alt="WordCountの遷移図" width="800" />
-</div>
-
 
 
 </div>
@@ -584,82 +643,6 @@
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="localdgmのsocketの受信データ取り出し">LocalDGMのsocketの受信データ取り出し</h2>
-<ul>
-  <li>socketはImplementに記述される</li>
-  <li>LocalDGMに相当するファイルは、接続先socketから送信されたデータを取り出す</li>
-  <li>取り出されたデータはInputStreamQueueに対してputされる
-    <pre><code>__code getDataLocalDGMQueue(struct LocalDGMQueue* cQueue, __code next(...), __code whenEOF(...), __code whenError(...)){
-  union Data* recv_data;
-  recv_size = recv(cQueue-&gt;socket, recv_data, sizeof(union Data), 0);
-  if (recv_size == -1) {
-      printf("recv error\n");
-      goto whenError(...);
-  }
-  FileString* fileString = NEW(FileString);
-  fileString = recv_data;
-  if (fileString-&gt;EoF) == 1) {
-      send_buf = 0;
-      send_size = send(cQueue-&gt;socket, &amp;send_buf, 1, 0);
-      if (send_size == -1) {
-          printf("send error\n");
-      }
-      close(cQueue-&gt;buffer);
-      goto whenEOF(...);
-  } else {
-      send_buf = 1;
-      send_size = send(cQueue-&gt;socket, &amp;send_buf, 1, 0);
-      if (send_size == -1) {
-          printf("send error\n");
-          goto whenError(...);
-      }
-  }
-
-  Gearef(context, cQueue)-&gt;data = recv_data;
-  goto putLocalDGMQueue(recv_data, next);
-}
-</code></pre>
-  </li>
-</ul>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h2 id="remotedgmのsocketによるデータ送信">RemoteDGMのsocketによるデータ送信</h2>
-<ul>
-  <li>RemoteDGM側はsocketを用いてデータを送信する</li>
-  <li>Queueに対してputされたデータを送信する
-    <ul>
-      <li>putCodeGearの直後に呼び出される
-        <pre><code>__code sendDataRemoteDGMQueue(struct RemoteDGMQueue* cQueue, union Data* data, __code next(...), __code whenError(...)){
-send_size = send(cQueue-&gt;socket, data, sizeof(union Data), 0);
-if (send_size == -1) {
-    printf("send error\n");
-    goto whenError();
-}
-
-recv_size = recv(cQueue-&gt;socket, &amp;recv_buf, 1, 0);
-if (recv_size == -1) {
-    printf("recv error\n");
-    goto whenError();
-}
-goto next(...);
-}
-</code></pre>
-      </li>
-    </ul>
-  </li>
-</ul>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
 <h2 id="gearsfsのディレクトリ">GearsFSのディレクトリ</h2>
 <ul>
   <li>ディレクトリを赤黒木で実装する</li>
@@ -714,8 +697,8 @@
   <li>par gotoを用いる案
     <ul>
       <li>処理速度が遅い</li>
+      <li>トランスコンパイラへの依存度が高い</li>
       <li>現状バグが存在している</li>
-      <li>トランスコンパイラへの依存度が高い</li>
     </ul>
   </li>
   <li>新しく並列処理を開発する</li>
@@ -774,23 +757,24 @@
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="まとめ">まとめ</h2>
+<h2 id="結論">結論</h2>
 <ul>
   <li>GearsFileSystemの設計
     <ul>
       <li>ファイルの構成方法
         <ul>
-          <li>Queueのリストである</li>
+          <li>keyによってアクセスされるQueueのリスト</li>
         </ul>
       </li>
       <li>ファイル操作API
         <ul>
+          <li>ChristieAPI</li>
           <li>レコード単位で操作される</li>
         </ul>
       </li>
       <li>ファイル送受信の実装
         <ul>
-          <li>ファイルploxy</li>
+          <li>RemoteDGM(ファイルploxy)</li>
         </ul>
       </li>
       <li>ディレクトリの仕組み
@@ -829,14 +813,17 @@
 struct Atomic* atomic;
 } SynchronizedQueue;
 </code></pre>
-    
+  </li>
+</ul>
+
+
 
 </div>
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
 <h2 id="研究成果">研究成果</h2>
-  </li>
+<ul>
   <li>連続するレコードで構成されるGearsOSファイルの設計</li>
   <li>keyアクセスを用いたファイルに対するRead, writeAPI</li>
   <li>赤黒木を用いたディレクトリシステムの構築</li>
@@ -844,13 +831,49 @@
   <li>ploxyを用いたファイルの送受信</li>
 </ul>
 
-<p>##
-&lt;!–</p>
+
+
+</div>
+
+<div class='slide'>
+  <!-- _S9SLIDE_ -->
+<h2 id="api手順">API手順</h2>
 <ul>
-  <li>RocalDGMを立ち上げるにはDataSegmentクラスが提供する、connectメソッドを用い、接続したいポートのipアドレスとport番号、そして任意のManager名を指定することで立ち上げる。
-–&gt;</li>
+  <li>readの場合(リモート側に読み込みたいファイルが存在する)
+    <ul>
+      <li>(手順1)ローカル側はLocalDGMの相当する空のファイルを作成し、socketを持つ</li>
+      <li>(手順2)リモート側はローカルの空ファイルのploxyを作成する</li>
+      <li>(手順3)リモート側はploxyに対してデータをputする</li>
+    </ul>
+  </li>
+  <li>writeの場合(リモート側に書き込みたいファイルが存在する)
+    <ul>
+      <li>(手順1)リモート側は対象ファイルにsocketを持たせる</li>
+      <li>(手順2)ローカル側は対象のファイルに対応するploxy(RemoteDGM)を作成する</li>
+      <li>(手順3)ローカル側はploxyのkeyに対してデータをputする</li>
+    </ul>
+  </li>
 </ul>
 
+
+
+</div>
+
+<div class='slide'>
+  <!-- _S9SLIDE_ -->
+<h2 id="wordcount手順">WordCount手順</h2>
+<ul>
+  <li>(手順1)ファイル内文字列を1行ずつWordCount関数へ入力する、これをループ</li>
+  <li>(手順2)ファイル内文字列が無くなった場合(EoF)結果を出力し、終了する</li>
+</ul>
+<div style="text-align: center;">
+  　<img src="images/wordCountStates.pdf" alt="WordCountの遷移図" width="800" />
+</div>
+
+<!--
+- RocalDGMを立ち上げるにはDataSegmentクラスが提供する、connectメソッドを用い、接続したいポートのipアドレスとport番号、そして任意のManager名を指定することで立ち上げる。
+-->
+
 </div>