Mercurial > hg > Papers > 2022 > ikki-master

Binary file Paper/images/slideGearsWC.pdf has changed
Binary file slide/images/newGearsFile.pdf has changed
Binary file slide/images/slideGearsWC.pdf has changed
--- a/slide/thesis.html	Thu Feb 10 23:55:41 2022 +0900
+++ b/slide/thesis.html	Fri Feb 11 13:14:32 2022 +0900
@@ -123,7 +123,7 @@
       <li>ノーマルレベルでは変更されない(関数型プログラミング)</li>
     </ul>
   </li>
-  <li>C言語を拡張する形でCbC言語により実装される(gcc/llvm)</li>
+  <li>C言語を拡張する形でCbC言語により実装される</li>
 </ul>


@@ -176,7 +176,7 @@
   <li>createで作成する(通常の関数呼び出し)</li>
   <li>DataGearとして作成する場合はnewを使う</li>
   <li>gotoでputAPIを呼び出す(nextは継続)</li>
-  <li>InterfaceなどのDataGearはプロセスに相当するContextにすべて格納される
+  <li>InterfaceなどのDataGearは、プロセスに相当するContextにすべて格納される
     <pre><code>struct Queue* queue = createSychronizedQueue(context);
 struct Task* task = new Task();
 goto queue-&gt;put(task, next(...));
@@ -192,9 +192,9 @@
   <!-- _S9SLIDE_ -->
 <h2 id="interfaceの実装">Interfaceの実装</h2>
 <ul>
-  <li>Interfaceの実装に使われるデータ構造を記述するImplementがある</li>
+  <li>Interfaceの実装に使われるデータ構造を、記述するImplementがある</li>
   <li>実装で使われるDataGearを記述する(ヒープに確保される)</li>
-  <li>create時にAPIを実装するCodeGearをInterfaceの構造体に代入される
+  <li>create時にAPIを実装するCodeGearが、Interfaceの構造体に代入される
     <pre><code>typedef struct SynchronizedQueue &lt;&gt; impl Queue {
 struct Element* top;
 struct Element* last;
@@ -269,7 +269,11 @@
   <li>ファイルはQueueで構成される</li>
   <li>putでQueueに追加</li>
   <li>takeでQueueからの取り出し</li>
-  <li>peekでQueueから取り出さない読み出し</li>
+  <li>peekでQueueから取り出さない読み出し
+    <ul>
+      <li>次にTakeされるDataGearを先読みする</li>
+    </ul>
+  </li>
 </ul>
 <div style="text-align: center;">
   　<img src="images/QueueElement.pdf" alt="Queueの構造" width="800" />
@@ -313,20 +317,24 @@
   <!-- _S9SLIDE_ -->
 <h2 id="putのimplementation">PutのImplementation</h2>
 <ul>
-  <li>QueueのElementをnewで作成する</li>
+  <li>QueueのElementをnewで作成する
+    <ul>
+      <li>Elementには任意の型のDataGearが格納されている</li>
+    </ul>
+  </li>
   <li>Queueのリンクを構築する</li>
-  <li>継続nextに跳ぶ
-    <pre><code>__code putSingleLinkedQueue(struct SingleLinkedQueue* queue, union Data* data, __code next(...)) {
-  Element* element = new Element();
-  element-&gt;data = data;
-  element-&gt;next = NULL;
-  queue-&gt;last-&gt;next  = element;
-  queue-&gt;last = element;
-  goto next(...);
+  <li>継続nextに跳ぶ</li>
+</ul>
+
+<pre><code>__code putSingleLinkedQueue(struct SingleLinkedQueue* queue, union Data* data, __code next(...)) {
+    Element* element = new Element();
+    element-&gt;data = data;
+    element-&gt;next = NULL;
+    queue-&gt;last-&gt;next  = element;
+    queue-&gt;last = element;
+    goto next(...);
 }
 </code></pre>
-  </li>
-</ul>


@@ -337,8 +345,7 @@
 <h2 id="takeのimplementation">TakeのImplementation</h2>
 <ul>
   <li>QueueからElement経由でDataGearを取り出す</li>
-  <li>Queueのリンクを修正し、nextでデータを引き渡す</li>
-  <li>Elementには任意の型のDataGearが格納されている
+  <li>Queueのリンクを修正し、取り出されるデータをnextへ引き渡す
     <pre><code>__code takeSingleLinkedQueue(struct SingleLinkedQueue* queue, __code next(union Data* data, ...)) {
   printf("take\n");
   struct Element* top = queue-&gt;top;
@@ -361,13 +368,16 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="datagearmanager">DataGearManager</h2>
+<h2 id="gearsosのdatagearmanager">GearsOSのDataGearManager</h2>
 <ul>
   <li>Take/Put/PeekはDataGearManagerに対して行う</li>
-  <li>メモリ上のQueueはLocalDGMになる</li>
-  <li>RemoteDGMは他のノードやプロセスあるいはストレージデバイスをあらわす</li>
-  <li>一つのDataGearManager上に複数のQueueがあり、keyで識別する</li>
-  <li>RemoteDGMに書き込むと相手のLocalDGMに書き込まれる</li>
+  <li>LocalDGM:メモリ上のQueue</li>
+  <li>RemoteDGM:他のノードやプロセスあるいはストレージデバイスをあらわす
+    <ul>
+      <li>RemoteDGMは対応する相手のLocalDGMと接続される</li>
+    </ul>
+  </li>
+  <li>DataGearManager上には複数のQueueがあり、keyで識別する</li>
   <li>Take/Peekは書き込みを待ち合わせる</li>
   <li>複数のTakeを待ち合わせることができる</li>
 </ul>
@@ -381,12 +391,11 @@
 <h2 id="datagearmanagerによる通信構成">DataGearManagerによる通信構成</h2>
 <ul>
   <li>任意の相手のRemoteDGMを作成することでTopologyが形成される</li>
-  <li>手元のRemoteDGMに書き込むと相手のLocalDGMに書き込まれる</li>
-  <li>RemoteDGMはproxyとして動作する</li>
+  <li>RemoteDGMはproxy(RemoteDGMに書き込むと相手のLocalDGMに書き込める)</li>
   <li>この構成は分散フレームワークChristie(当研究室作成)と同じ</li>
 </ul>
 <div style="text-align: center;">
-　<img src="images/Remote_DataGearManager.pdf" alt="RemoteDGMの関係図" width="800" />
+　<img src="images/Remote_DataGearManager.pdf" alt="RemoteDGMの関係図" width="550" />
 </div>


@@ -398,10 +407,8 @@
 <h2 id="socket通信によるremotedgmの実装">socket通信によるRemoteDGMの実装</h2>
 <ul>
   <li>GearsOSはUnix上の言語フレームワークとして実装されている</li>
-  <li>Unixのsocket通信を使ってQueueのputを実装する</li>
-  <li>proxy側はQueueにputされたDataをsocketで送信する</li>
-  <li>送信されたDataはLocal側でgetDataAPIで取り出される</li>
-  <li>send/recvはUnixのAPI
+  <li>Unixのsocket通信を使ってQueueのputを実装する(send/recvはUnixのAPI)</li>
+  <li>proxy側はQueueにputされたDataをsocketで送信する
     <pre><code>__code sendDataRemoteDGMQueue(struct RemoteDGMQueue* cQueue, union Data* data, __code next(...), __code whenError(...)){
   char recv_buf;
   int send_size, recv_size;
@@ -448,31 +455,14 @@
   <!-- _S9SLIDE_ -->
 <h2 id="複数のストリームから構成されるファイル">複数のストリームから構成されるファイル</h2>
 <ul>
-  <li>入力されるデータに応じた個別のstreamを備えたい
-    <ul>
-      <li>例えばUSBは複数のチャネルを持つ</li>
-      <li>メタデータの取り出しは別streamになる</li>
-      <li>通信として使う場合に複数のプロトコルがある方が良い(FTP)</li>
-    </ul>
-  </li>
+  <li>入力されるデータに応じた個別のstreamを備えたい</li>
   <li>Streamはkey nameを持ち、keyでアクセスを行う</li>
-  <li>赤黒木を用いる</li>
+  <li>Queueのリストとして赤黒木を用いる</li>
   <li>DataのTake/Put時には必ずkey nameの指定が必要となる</li>
 </ul>

-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h2 id="socketを使ったremotedgm">socketを使ったRemoteDGM</h2>
-<ul>
-  <li>RemoteDGMに書き込みが行われるとsocketで通信が起きる</li>
-  <li>受信側はLocalDGMにDataGearを書き込む</li>
-</ul>
 <div style="text-align: center;">
-  　<img src="images/socketCom.pdf" alt="socketを通じたレコード送信" width="800" />
+　<img src="images/newGearsFile.pdf" alt="複数ストリームの設計" width="300" />
 </div>


@@ -485,11 +475,9 @@
 <ul>
   <li>ファイル内の文字列を1行づつ受け取り、文字列,行数をカウントする例題</li>
   <li>文字列送信側とCount側を別ノード上で行うことで、ファイルの呼び出しと通信処理が構成できる</li>
-  <li>RemoteDGMへの書き込みで通信する</li>
-  <li>acknowredgeを逆方向のRemoteDGMによる通信で実現する(現在は直接送信)</li>
 </ul>
 <div style="text-align: center;">
-　<img src="images/slideGearsWC.pdf" alt="リモートDGMによるWordCount" width="800" />
+　<img src="images/slideGearsWC.pdf" alt="リモートDGMによるWordCount" width="550" />
 </div>


@@ -498,42 +486,13 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="gearsfile-apiによるwordcount13">GearsFile APIによるWordCount(1/3)</h2>
+<h2 id="wordcountの例題-1">wordCountの例題</h2>
 <ul>
-  <li>FileOpen側(NodeA)とWordCount側(NodeB)でノードが別れる</li>
-  <li>(手順1)FileOpen側はFilePloxyにDataRecordをputする</li>
-  <li>(手順2)WordCount側は処理の後、ackを返信する</li>
+  <li>二つのDataGearManagerのペアで構成される</li>
+  <li>acknowledgeを逆方向のRemoteDGMによる通信で実現する(現在は直接送信)</li>
 </ul>
 <div style="text-align: center;">
-  　<img src="images/slideGearsWC.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/slideGearsWC.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;">
-  　<img src="images/slideGearsWC.pdf" alt="ChristieAPIによるWordCount" width="800" />
+　<img src="images/slideGearsWC.pdf" alt="リモートDGMによるWordCount" width="550" />
 </div>


@@ -546,17 +505,13 @@
 <ul>
   <li>実装ずみ
     <ul>
-      <li>keyアクセスに対応したファイル通信
+      <li>API:put/takeに対応したファイル通信
         <ul>
-          <li>単一のQueueによる通信の記述</li>
+          <li>単一のQueueによる通信の記述をした</li>
         </ul>
       </li>
-      <li>リストとなるTree
-        <ul>
-          <li>赤黒木</li>
-        </ul>
-      </li>
-      <li>atomicな操作が行えるQueue
+      <li>QueueのリストとなるTree(赤黒木)</li>
+      <li>atomicな操作が行えるQueue(SynchronizedQueue)
         <ul>
           <li>複数からのアクセス時にデータ整合を保つ</li>
         </ul>
@@ -565,8 +520,8 @@
   </li>
   <li>実装中
     <ul>
-      <li>keyアクセスが行えるQueueのリスト</li>
-      <li>リスト単位での通信の記述</li>
+      <li>key指定による任意なstreamの操作が行えるファイル</li>
+      <li>ファイル単位での通信の記述(Queue単体でない)</li>
     </ul>
   </li>
 </ul>
@@ -596,10 +551,9 @@
           <li>Proxyによるファイル通信</li>
         </ul>
       </li>
-      <li>GearsOSの調査</li>
     </ul>
   </li>
-  <li>Streamのリスト単位での通信の完成</li>
+  <li>Queue(stream)単位でない、ファイル単位の通信</li>
 </ul>


@@ -623,8 +577,8 @@
   </li>
   <li>Securityシステムの追加
     <ul>
-      <li>証明書などによるファイル操作制限</li>
-      <li>不正な分散ファイルシステムへのアクセス</li>
+      <li>ファルパーミッション</li>
+      <li>不正な分散ファイルシステムへのアクセスの防止</li>
     </ul>
   </li>
 </ul>
@@ -650,61 +604,80 @@
   </li>
 </ul>

-<pre><code>__code Task2(TQueue* localDGMQueue){
-    goto localDGMQueue-&gt;take(Task3);
-}
-
-__code Task3(TQueue* localDGMQueue, FileString* string){
-    printf("take[%s] [num:%d]\n", string-&gt;str, string-&gt;size);
-    goto getData();
-}
-
-//プログラマが実装したいstub
-__code Task3_stub(struct Context* context){
-    TQueue* localDGMQueue = (struct TQueue*)Gearef(context, TQueue)-&gt;tQueue;
-    FileString* string = Gearef(context, TQueue)-&gt;data;
-    goto Task3(context, localDGMQueue, string);
-}
-
-//自動生成されたErrorなstub
-__code Task3_stub(struct Context* context) {
-	TQueue* localDGMQueue = Gearef(context, TQueue);
-	FileString* string = Gearef(context, FileString);
-	goto Task3(context, localDGMQueue, string);
-}
-</code></pre>
-


 </div>

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="並列処理構文par-gotoが持つ問題">並列処理構文par gotoが持つ問題</h2>
+<h2 id="トランスコンパイラのバグの例">トランスコンパイラのバグの例</h2>
 <ul>
-  <li>par gotoとはGearsOSに実装された並列処理構文である</li>
-  <li>StreamQueueに対するput/takeの並列処理の実装をpar goto構文で試みた</li>
-  <li>par gotoはトランスコンパイラへの依存性が高い
-    <ul>
-      <li>stubCodeGearのように任意な書き換えが行えない</li>
-    </ul>
-  </li>
-  <li>特定のCodeGearの宣言のみでしか正常な処理が生成されない
-    <ul>
-      <li>Interfaceに記述されたAPICodeGearではバグが生じる</li>
-      <li>par gotoでの使用を前提としたCodeGearを書かなくてはならない</li>
-    </ul>
-  </li>
-  <li>処理が重いという問題点も存在する</li>
+  <li>ContextからのDataGearの取り出し方が間違っている
+```
+__code Task3(TQueue* localDGMQueue, FileString* string){
+  goto Task4();
+}</li>
 </ul>

-
+<p>__code Task3_stub(struct Context* context){   //正しいstub
+  TQueue* localDGMQueue = (struct TQueue<em>)Gearef(context, TQueue)-&gt;tQueue;
+  FileString</em> string = Gearef(context, TQueue)-&gt;data;
+  goto Task3(context, localDGMQueue, string);
+}</p>

-</div>
+<p>__code Task3_stub(struct Context* context) {  //自動生成されたErrorなstub
+	TQueue* localDGMQueue = Gearef(context, TQueue);
+	FileString* string = Gearef(context, FileString);
+	goto Task3(context, localDGMQueue, string);
+}</p>
+<pre><code>
+## 並列処理構文par gotoが持つ問題
+- par gotoとはGearsOSに実装された並列処理構文である
+- StreamQueueに対するput/takeの並列処理の実装をpar goto構文で試みた
+- par gotoはトランスコンパイラへの依存性が高い
+  - stubCodeGearのように任意な書き換えが行えない
+- 特定のCodeGearの宣言のみでしか正常な処理が生成されない
+  - Interfaceに記述されたAPICodeGearではバグが生じる
+  - par gotoでの使用を前提としたCodeGearを書かなくてはならない
+- 処理が重いという問題点も存在する
+
+##  GearsFile APIによるWordCount(1/3)
+- FileOpen側(NodeA)とWordCount側(NodeB)でノードが別れる
+- (手順1)FileOpen側はFilePloxyにDataRecordをputする
+- (手順2)WordCount側は処理の後、ackを返信する
+&lt;div style="text-align: center;"&gt;
+  　&lt;img src="images/slideGearsWC.pdf" alt=ChristieAPIによるWordCount width="800"&gt;
+&lt;/div&gt;

-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h2 id="以下返答用">以下返答用</h2>
+##  GearsFile APIによるWordCount(2/3)
+- (手順3)1,2をループし、FileOpen側はEoFならフラグを送信する
+&lt;div style="text-align: center;"&gt;
+  　&lt;img src="images/slideGearsWC.pdf" alt=ChristieAPIによるWordCount width="800"&gt;
+&lt;/div&gt;
+
+##  GearsFile APIによるWordCount(3/3)
+- (手順4)EoFを受信したWordCountは結果を返信し、双方の処理を終了させる
+&lt;div style="text-align: center;"&gt;
+  　&lt;img src="images/slideGearsWC.pdf" alt=ChristieAPIによるWordCount width="800"&gt;
+&lt;/div&gt;
+
+## 以下返答用
+
+## PeekのImplementation
+- QueueからElement経由でDataGearを取り出す
+- Takeとは異なり、Queueのリンクを修正せずに、取り出されるデータをnextへ引き渡す
+</code></pre>
+<p>__code peekSingleLinkedQueue(struct SingleLinkedQueue* queue, __code next(union Data* data, …)) {
+    struct Element* top = queue-&gt;top;
+    struct Element* nextElement = top-&gt;next;
+    if (queue-&gt;top == queue-&gt;last) {
+        data = NULL;
+    } else {
+        data = nextElement-&gt;data;
+    }
+    goto next(data, …);
+}
+```</p>


@@ -715,7 +688,7 @@
 <h2 id="takeputpeek-1">Take/Put/Peek</h2>
 <ul>
   <li>PeekはReadOnly (最新の設定を読みこむなど)</li>
-  <li>Take/PutはDGが一つならUpDataに相当する</li>
+  <li>Take/PutはDataGearが一つならUpdateに相当する</li>
   <li>書き込みが単一スレッドなら順序は保証される</li>
   <li>書き込みが複数の場合、Putの順序は保証されない</li>
   <li>データベースとの違い
@@ -790,6 +763,27 @@
   </li>
 </ul>

+
+
+</div>
+
+<div class='slide'>
+  <!-- _S9SLIDE_ -->
+<h2 id="複数のストリームによる利点">複数のストリームによる利点</h2>
+<ul>
+  <li>例えばUSBは複数のチャネルを持つ
+    <ul>
+      <li>メタデータの取り出しは別streamになる</li>
+    </ul>
+  </li>
+  <li>複数の通信によりファイル通信の制御を行う場合がある
+    <ul>
+      <li>通信の停止などのための通信</li>
+    </ul>
+  </li>
+  <li>通信として使う場合に複数のプロトコルがある方が良い(FTP)</li>
+</ul>
+
 </div>
--- a/slide/thesis.md	Thu Feb 10 23:55:41 2022 +0900
+++ b/slide/thesis.md	Fri Feb 11 13:14:32 2022 +0900
@@ -7,8 +7,8 @@

 ## GearsOSのファイルシステムの設計と実装
 - DataGearとCodeGearという単位を用いるOS
-- 従来のファイルシステムには型とTransactionが無い
 - DataGear単位のTransactionとしてファイルシステムを設計
+  - 従来のOSのファイルシステムには型とTransactionが無い
 - APIとしてTake/Put/Peekを採用した
 - 通信としてもDBアクセスとしても使える(メモリからSSDへの通信に見える)
 - 本研究ではsocket baseな通信とWordCountの例題を作成した
@@ -23,7 +23,7 @@
 - DataGear
   - Cの構造体に相当する
   - ノーマルレベルでは変更されない(関数型プログラミング)
-- C言語を拡張する形でCbC言語により実装される(gcc/llvm)
+- C言語を拡張する形でCbC言語により実装される


 ## CodeGearとDataGear
@@ -54,7 +54,7 @@
 - createで作成する(通常の関数呼び出し)
 - DataGearとして作成する場合はnewを使う
 - gotoでputAPIを呼び出す(nextは継続)
-- InterfaceなどのDataGearはプロセスに相当するContextにすべて格納される
+- InterfaceなどのDataGearは、プロセスに相当するContextにすべて格納される
 ```
 struct Queue* queue = createSychronizedQueue(context);
 struct Task* task = new Task();
@@ -63,9 +63,9 @@


 ## Interfaceの実装
-- Interfaceの実装に使われるデータ構造を記述するImplementがある
+- Interfaceの実装に使われるデータ構造を、記述するImplementがある
 - 実装で使われるDataGearを記述する(ヒープに確保される)
-- create時にAPIを実装するCodeGearをInterfaceの構造体に代入される
+- create時にAPIを実装するCodeGearが、Interfaceの構造体に代入される
 ```
 typedef struct SynchronizedQueue <> impl Queue {
   struct Element* top;
@@ -105,6 +105,7 @@
 - putでQueueに追加
 - takeでQueueからの取り出し
 - peekでQueueから取り出さない読み出し
+  - 次にTakeされるDataGearを先読みする
 <div style="text-align: center;">
   　<img src="images/QueueElement.pdf" alt=Queueの構造 width="800">
 </div>
@@ -122,8 +123,10 @@

 ## PutのImplementation
 - QueueのElementをnewで作成する
+  - Elementには任意の型のDataGearが格納されている
 - Queueのリンクを構築する
 - 継続nextに跳ぶ
+
 ```
 __code putSingleLinkedQueue(struct SingleLinkedQueue* queue, union Data* data, __code next(...)) {
     Element* element = new Element();
@@ -137,8 +140,7 @@

 ## TakeのImplementation
 - QueueからElement経由でDataGearを取り出す
-- Queueのリンクを修正し、nextでデータを引き渡す
-- Elementには任意の型のDataGearが格納されている
+- Queueのリンクを修正し、取り出されるデータをnextへ引き渡す
 ```
 __code takeSingleLinkedQueue(struct SingleLinkedQueue* queue, __code next(union Data* data, ...)) {
     printf("take\n");
@@ -154,31 +156,30 @@
 }
 ```

-## DataGearManager
+
+
+## GearsOSのDataGearManager
 - Take/Put/PeekはDataGearManagerに対して行う
-- メモリ上のQueueはLocalDGMになる
-- RemoteDGMは他のノードやプロセスあるいはストレージデバイスをあらわす
-- 一つのDataGearManager上に複数のQueueがあり、keyで識別する
-- RemoteDGMに書き込むと相手のLocalDGMに書き込まれる
+- LocalDGM:メモリ上のQueue
+- RemoteDGM:他のノードやプロセスあるいはストレージデバイスをあらわす
+  - RemoteDGMは対応する相手のLocalDGMと接続される
+- DataGearManager上には複数のQueueがあり、keyで識別する
 - Take/Peekは書き込みを待ち合わせる
 - 複数のTakeを待ち合わせることができる

 ## DataGearManagerによる通信構成
 - 任意の相手のRemoteDGMを作成することでTopologyが形成される
-- 手元のRemoteDGMに書き込むと相手のLocalDGMに書き込まれる
-- RemoteDGMはproxyとして動作する
+- RemoteDGMはproxy(RemoteDGMに書き込むと相手のLocalDGMに書き込める)
 - この構成は分散フレームワークChristie(当研究室作成)と同じ
 <div style="text-align: center;">
-　<img src="images/Remote_DataGearManager.pdf" alt="RemoteDGMの関係図" width="800">
+　<img src="images/Remote_DataGearManager.pdf" alt="RemoteDGMの関係図" width="550">
 </div>


 ## socket通信によるRemoteDGMの実装
 - GearsOSはUnix上の言語フレームワークとして実装されている
-- Unixのsocket通信を使ってQueueのputを実装する
+- Unixのsocket通信を使ってQueueのputを実装する(send/recvはUnixのAPI)
 - proxy側はQueueにputされたDataをsocketで送信する
-- 送信されたDataはLocal側でgetDataAPIで取り出される
-- send/recvはUnixのAPI
 ```
 __code sendDataRemoteDGMQueue(struct RemoteDGMQueue* cQueue, union Data* data, __code next(...), __code whenError(...)){
     char recv_buf;
@@ -210,31 +211,100 @@

 ## 複数のストリームから構成されるファイル
 - 入力されるデータに応じた個別のstreamを備えたい
-  - 例えばUSBは複数のチャネルを持つ
-  - メタデータの取り出しは別streamになる
-  - 通信として使う場合に複数のプロトコルがある方が良い(FTP)
 - Streamはkey nameを持ち、keyでアクセスを行う
-- 赤黒木を用いる
+- Queueのリストとして赤黒木を用いる
 - DataのTake/Put時には必ずkey nameの指定が必要となる

-## socketを使ったRemoteDGM
-- RemoteDGMに書き込みが行われるとsocketで通信が起きる
-- 受信側はLocalDGMにDataGearを書き込む
 <div style="text-align: center;">
-  　<img src="images/socketCom.pdf" alt=socketを通じたレコード送信 width="800">
+　<img src="images/newGearsFile.pdf" alt="複数ストリームの設計" width="300">
 </div>

-
 ## wordCountの例題
 - ファイル内の文字列を1行づつ受け取り、文字列,行数をカウントする例題
 - 文字列送信側とCount側を別ノード上で行うことで、ファイルの呼び出しと通信処理が構成できる
-- RemoteDGMへの書き込みで通信する
-- acknowredgeを逆方向のRemoteDGMによる通信で実現する(現在は直接送信)
 <div style="text-align: center;">
-　<img src="images/slideGearsWC.pdf" alt="リモートDGMによるWordCount" width="800">
+　<img src="images/slideGearsWC.pdf" alt="リモートDGMによるWordCount" width="550">
+</div>
+
+## wordCountの例題
+- 二つのDataGearManagerのペアで構成される
+- acknowledgeを逆方向のRemoteDGMによる通信で実現する(現在は直接送信)
+<div style="text-align: center;">
+　<img src="images/slideGearsWC.pdf" alt="リモートDGMによるWordCount" width="550">
 </div>


+## 現在のGearsFile APIの開発状況
+- 実装ずみ
+  - API:put/takeに対応したファイル通信
+    - 単一のQueueによる通信の記述をした
+  - QueueのリストとなるTree(赤黒木)
+  - atomicな操作が行えるQueue(SynchronizedQueue)
+    - 複数からのアクセス時にデータ整合を保つ
+- 実装中
+  - key指定による任意なstreamの操作が行えるファイル
+  - ファイル単位での通信の記述(Queue単体でない)
+
+
+## 結論
+- GearsOSのファイルの設計を行った
+  - ファイルの構造の設計
+    - DataGear単位での操作が行える
+  - socketによる通信部分の実装
+    - GearsOS上でのソケット通信の記述
+  - APIの段階的な設計記述
+    - Proxyによるファイル通信
+- Queue(stream)単位でない、ファイル単位の通信
+
+## 将来的な課題
+- TopoplogyManagerの設計
+  - 参加したノードを任意の形のTopologyに接続する機能
+  - ファイルシステム向けの機能を追加したい
+    - DNS
+    - 中枢としてのTopologyのノード監視
+- Securityシステムの追加
+  - ファルパーミッション
+  - 不正な分散ファイルシステムへのアクセスの防止
+
+
+
+## GearsOSの生成形の問題点
+- GearsOSのメタレベルの処理の記述はトランスコンパイラにより行われる
+- 場合によりメタレベルの記述を行わなくてはならない
+  - 他のInterfaceを継承したオブジェクトからのDataGear継承
+    - 例)Queueからのデータ取り出し
+    - トランスコンパイラはどのInterfaceに記述されたDataGearを参照するべきか判断が難しい
+
+
+## トランスコンパイラのバグの例
+- ContextからのDataGearの取り出し方が間違っている
+```
+__code Task3(TQueue* localDGMQueue, FileString* string){
+    goto Task4();
+}
+
+__code Task3_stub(struct Context* context){   //正しいstub
+  TQueue* localDGMQueue = (struct TQueue*)Gearef(context, TQueue)->tQueue;
+  FileString* string = Gearef(context, TQueue)->data;
+  goto Task3(context, localDGMQueue, string);
+}
+
+__code Task3_stub(struct Context* context) {  //自動生成されたErrorなstub
+	TQueue* localDGMQueue = Gearef(context, TQueue);
+	FileString* string = Gearef(context, FileString);
+	goto Task3(context, localDGMQueue, string);
+}
+```
+
+## 並列処理構文par gotoが持つ問題
+- par gotoとはGearsOSに実装された並列処理構文である
+- StreamQueueに対するput/takeの並列処理の実装をpar goto構文で試みた
+- par gotoはトランスコンパイラへの依存性が高い
+  - stubCodeGearのように任意な書き換えが行えない
+- 特定のCodeGearの宣言のみでしか正常な処理が生成されない
+  - Interfaceに記述されたAPICodeGearではバグが生じる
+  - par gotoでの使用を前提としたCodeGearを書かなくてはならない
+- 処理が重いという問題点も存在する

 ##  GearsFile APIによるWordCount(1/3)
 - FileOpen側(NodeA)とWordCount側(NodeB)でノードが別れる
@@ -256,91 +326,27 @@
   　<img src="images/slideGearsWC.pdf" alt=ChristieAPIによるWordCount width="800">
 </div>

-
-## 現在のGearsFile APIの開発状況
-- 実装ずみ
-  - keyアクセスに対応したファイル通信
-    - 単一のQueueによる通信の記述
-  - リストとなるTree
-    - 赤黒木
-  - atomicな操作が行えるQueue
-    - 複数からのアクセス時にデータ整合を保つ
-- 実装中
-  - keyアクセスが行えるQueueのリスト
-  - リスト単位での通信の記述
-
-
-## 結論
-- GearsOSのファイルの設計を行った
-  - ファイルの構造の設計
-    - DataGear単位での操作が行える
-  - socketによる通信部分の実装
-    - GearsOS上でのソケット通信の記述
-  - APIの段階的な設計記述
-    - Proxyによるファイル通信
-  - GearsOSの調査
-- Streamのリスト単位での通信の完成
+## 以下返答用

-## 将来的な課題
-- TopoplogyManagerの設計
-  - 参加したノードを任意の形のTopologyに接続する機能
-  - ファイルシステム向けの機能を追加したい
-    - DNS
-    - 中枢としてのTopologyのノード監視
-- Securityシステムの追加
-  - 証明書などによるファイル操作制限
-  - 不正な分散ファイルシステムへのアクセス
-
-
-
-## GearsOSの生成形の問題点
-- GearsOSのメタレベルの処理の記述はトランスコンパイラにより行われる
-- 場合によりメタレベルの記述を行わなくてはならない
-  - 他のInterfaceを継承したオブジェクトからのDataGear継承
-    - 例)Queueからのデータ取り出し
-    - トランスコンパイラはどのInterfaceに記述されたDataGearを参照するべきか判断が難しい
-
+## PeekのImplementation
+- QueueからElement経由でDataGearを取り出す
+- Takeとは異なり、Queueのリンクを修正せずに、取り出されるデータをnextへ引き渡す
 ```
-__code Task2(TQueue* localDGMQueue){
-    goto localDGMQueue->take(Task3);
-}
-
-__code Task3(TQueue* localDGMQueue, FileString* string){
-    printf("take[%s] [num:%d]\n", string->str, string->size);
-    goto getData();
-}
-
-//プログラマが実装したいstub
-__code Task3_stub(struct Context* context){
-    TQueue* localDGMQueue = (struct TQueue*)Gearef(context, TQueue)->tQueue;
-    FileString* string = Gearef(context, TQueue)->data;
-    goto Task3(context, localDGMQueue, string);
-}
-
-//自動生成されたErrorなstub
-__code Task3_stub(struct Context* context) {
-	TQueue* localDGMQueue = Gearef(context, TQueue);
-	FileString* string = Gearef(context, FileString);
-	goto Task3(context, localDGMQueue, string);
+__code peekSingleLinkedQueue(struct SingleLinkedQueue* queue, __code next(union Data* data, ...)) {
+    struct Element* top = queue->top;
+    struct Element* nextElement = top->next;
+    if (queue->top == queue->last) {
+        data = NULL;
+    } else {
+        data = nextElement->data;
+    }
+    goto next(data, ...);
 }
 ```

-## 並列処理構文par gotoが持つ問題
-- par gotoとはGearsOSに実装された並列処理構文である
-- StreamQueueに対するput/takeの並列処理の実装をpar goto構文で試みた
-- par gotoはトランスコンパイラへの依存性が高い
-  - stubCodeGearのように任意な書き換えが行えない
-- 特定のCodeGearの宣言のみでしか正常な処理が生成されない
-  - Interfaceに記述されたAPICodeGearではバグが生じる
-  - par gotoでの使用を前提としたCodeGearを書かなくてはならない
-- 処理が重いという問題点も存在する
-
-## 以下返答用
-
-
 ## Take/Put/Peek
 - PeekはReadOnly (最新の設定を読みこむなど)
-- Take/PutはDGが一つならUpDataに相当する
+- Take/PutはDataGearが一つならUpdateに相当する
 - 書き込みが単一スレッドなら順序は保証される
 - 書き込みが複数の場合、Putの順序は保証されない
 - データベースとの違い
@@ -375,3 +381,10 @@
 - しかし、acknowledgeが重複してしまう
 - メタプログラミングを利用してこの重複を消すことは可能
   - しかし煩雑
+
+## 複数のストリームによる利点
+- 例えばUSBは複数のチャネルを持つ
+  - メタデータの取り出しは別streamになる
+- 複数の通信によりファイル通信の制御を行う場合がある
+  - 通信の停止などのための通信
+- 通信として使う場合に複数のプロトコルがある方が良い(FTP)
--- a/slide/thesis.pdf.html	Thu Feb 10 23:55:41 2022 +0900
+++ b/slide/thesis.pdf.html	Fri Feb 11 13:14:32 2022 +0900
@@ -107,7 +107,7 @@
       <li>ノーマルレベルでは変更されない(関数型プログラミング)</li>
     </ul>
   </li>
-  <li>C言語を拡張する形でCbC言語により実装される(gcc/llvm)</li>
+  <li>C言語を拡張する形でCbC言語により実装される</li>
 </ul>


@@ -160,7 +160,7 @@
   <li>createで作成する(通常の関数呼び出し)</li>
   <li>DataGearとして作成する場合はnewを使う</li>
   <li>gotoでputAPIを呼び出す(nextは継続)</li>
-  <li>InterfaceなどのDataGearはプロセスに相当するContextにすべて格納される
+  <li>InterfaceなどのDataGearは、プロセスに相当するContextにすべて格納される
     <pre><code>struct Queue* queue = createSychronizedQueue(context);
 struct Task* task = new Task();
 goto queue-&gt;put(task, next(...));
@@ -176,9 +176,9 @@
   <!-- _S9SLIDE_ -->
 <h2 id="interfaceの実装">Interfaceの実装</h2>
 <ul>
-  <li>Interfaceの実装に使われるデータ構造を記述するImplementがある</li>
+  <li>Interfaceの実装に使われるデータ構造を、記述するImplementがある</li>
   <li>実装で使われるDataGearを記述する(ヒープに確保される)</li>
-  <li>create時にAPIを実装するCodeGearをInterfaceの構造体に代入される
+  <li>create時にAPIを実装するCodeGearが、Interfaceの構造体に代入される
     <pre><code>typedef struct SynchronizedQueue &lt;&gt; impl Queue {
 struct Element* top;
 struct Element* last;
@@ -253,7 +253,11 @@
   <li>ファイルはQueueで構成される</li>
   <li>putでQueueに追加</li>
   <li>takeでQueueからの取り出し</li>
-  <li>peekでQueueから取り出さない読み出し</li>
+  <li>peekでQueueから取り出さない読み出し
+    <ul>
+      <li>次にTakeされるDataGearを先読みする</li>
+    </ul>
+  </li>
 </ul>
 <div style="text-align: center;">
   　<img src="images/QueueElement.pdf" alt="Queueの構造" width="800" />
@@ -297,20 +301,24 @@
   <!-- _S9SLIDE_ -->
 <h2 id="putのimplementation">PutのImplementation</h2>
 <ul>
-  <li>QueueのElementをnewで作成する</li>
+  <li>QueueのElementをnewで作成する
+    <ul>
+      <li>Elementには任意の型のDataGearが格納されている</li>
+    </ul>
+  </li>
   <li>Queueのリンクを構築する</li>
-  <li>継続nextに跳ぶ
-    <pre><code>__code putSingleLinkedQueue(struct SingleLinkedQueue* queue, union Data* data, __code next(...)) {
-  Element* element = new Element();
-  element-&gt;data = data;
-  element-&gt;next = NULL;
-  queue-&gt;last-&gt;next  = element;
-  queue-&gt;last = element;
-  goto next(...);
+  <li>継続nextに跳ぶ</li>
+</ul>
+
+<pre><code>__code putSingleLinkedQueue(struct SingleLinkedQueue* queue, union Data* data, __code next(...)) {
+    Element* element = new Element();
+    element-&gt;data = data;
+    element-&gt;next = NULL;
+    queue-&gt;last-&gt;next  = element;
+    queue-&gt;last = element;
+    goto next(...);
 }
 </code></pre>
-  </li>
-</ul>


@@ -321,8 +329,7 @@
 <h2 id="takeのimplementation">TakeのImplementation</h2>
 <ul>
   <li>QueueからElement経由でDataGearを取り出す</li>
-  <li>Queueのリンクを修正し、nextでデータを引き渡す</li>
-  <li>Elementには任意の型のDataGearが格納されている
+  <li>Queueのリンクを修正し、取り出されるデータをnextへ引き渡す
     <pre><code>__code takeSingleLinkedQueue(struct SingleLinkedQueue* queue, __code next(union Data* data, ...)) {
   printf("take\n");
   struct Element* top = queue-&gt;top;
@@ -345,13 +352,16 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="datagearmanager">DataGearManager</h2>
+<h2 id="gearsosのdatagearmanager">GearsOSのDataGearManager</h2>
 <ul>
   <li>Take/Put/PeekはDataGearManagerに対して行う</li>
-  <li>メモリ上のQueueはLocalDGMになる</li>
-  <li>RemoteDGMは他のノードやプロセスあるいはストレージデバイスをあらわす</li>
-  <li>一つのDataGearManager上に複数のQueueがあり、keyで識別する</li>
-  <li>RemoteDGMに書き込むと相手のLocalDGMに書き込まれる</li>
+  <li>LocalDGM:メモリ上のQueue</li>
+  <li>RemoteDGM:他のノードやプロセスあるいはストレージデバイスをあらわす
+    <ul>
+      <li>RemoteDGMは対応する相手のLocalDGMと接続される</li>
+    </ul>
+  </li>
+  <li>DataGearManager上には複数のQueueがあり、keyで識別する</li>
   <li>Take/Peekは書き込みを待ち合わせる</li>
   <li>複数のTakeを待ち合わせることができる</li>
 </ul>
@@ -365,12 +375,11 @@
 <h2 id="datagearmanagerによる通信構成">DataGearManagerによる通信構成</h2>
 <ul>
   <li>任意の相手のRemoteDGMを作成することでTopologyが形成される</li>
-  <li>手元のRemoteDGMに書き込むと相手のLocalDGMに書き込まれる</li>
-  <li>RemoteDGMはproxyとして動作する</li>
+  <li>RemoteDGMはproxy(RemoteDGMに書き込むと相手のLocalDGMに書き込める)</li>
   <li>この構成は分散フレームワークChristie(当研究室作成)と同じ</li>
 </ul>
 <div style="text-align: center;">
-　<img src="images/Remote_DataGearManager.pdf" alt="RemoteDGMの関係図" width="800" />
+　<img src="images/Remote_DataGearManager.pdf" alt="RemoteDGMの関係図" width="550" />
 </div>


@@ -382,10 +391,8 @@
 <h2 id="socket通信によるremotedgmの実装">socket通信によるRemoteDGMの実装</h2>
 <ul>
   <li>GearsOSはUnix上の言語フレームワークとして実装されている</li>
-  <li>Unixのsocket通信を使ってQueueのputを実装する</li>
-  <li>proxy側はQueueにputされたDataをsocketで送信する</li>
-  <li>送信されたDataはLocal側でgetDataAPIで取り出される</li>
-  <li>send/recvはUnixのAPI
+  <li>Unixのsocket通信を使ってQueueのputを実装する(send/recvはUnixのAPI)</li>
+  <li>proxy側はQueueにputされたDataをsocketで送信する
     <pre><code>__code sendDataRemoteDGMQueue(struct RemoteDGMQueue* cQueue, union Data* data, __code next(...), __code whenError(...)){
   char recv_buf;
   int send_size, recv_size;
@@ -432,31 +439,14 @@
   <!-- _S9SLIDE_ -->
 <h2 id="複数のストリームから構成されるファイル">複数のストリームから構成されるファイル</h2>
 <ul>
-  <li>入力されるデータに応じた個別のstreamを備えたい
-    <ul>
-      <li>例えばUSBは複数のチャネルを持つ</li>
-      <li>メタデータの取り出しは別streamになる</li>
-      <li>通信として使う場合に複数のプロトコルがある方が良い(FTP)</li>
-    </ul>
-  </li>
+  <li>入力されるデータに応じた個別のstreamを備えたい</li>
   <li>Streamはkey nameを持ち、keyでアクセスを行う</li>
-  <li>赤黒木を用いる</li>
+  <li>Queueのリストとして赤黒木を用いる</li>
   <li>DataのTake/Put時には必ずkey nameの指定が必要となる</li>
 </ul>

-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h2 id="socketを使ったremotedgm">socketを使ったRemoteDGM</h2>
-<ul>
-  <li>RemoteDGMに書き込みが行われるとsocketで通信が起きる</li>
-  <li>受信側はLocalDGMにDataGearを書き込む</li>
-</ul>
 <div style="text-align: center;">
-  　<img src="images/socketCom.pdf" alt="socketを通じたレコード送信" width="800" />
+　<img src="images/newGearsFile.pdf" alt="複数ストリームの設計" width="300" />
 </div>


@@ -469,11 +459,9 @@
 <ul>
   <li>ファイル内の文字列を1行づつ受け取り、文字列,行数をカウントする例題</li>
   <li>文字列送信側とCount側を別ノード上で行うことで、ファイルの呼び出しと通信処理が構成できる</li>
-  <li>RemoteDGMへの書き込みで通信する</li>
-  <li>acknowredgeを逆方向のRemoteDGMによる通信で実現する(現在は直接送信)</li>
 </ul>
 <div style="text-align: center;">
-　<img src="images/slideGearsWC.pdf" alt="リモートDGMによるWordCount" width="800" />
+　<img src="images/slideGearsWC.pdf" alt="リモートDGMによるWordCount" width="550" />
 </div>


@@ -482,42 +470,13 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="gearsfile-apiによるwordcount13">GearsFile APIによるWordCount(1/3)</h2>
+<h2 id="wordcountの例題-1">wordCountの例題</h2>
 <ul>
-  <li>FileOpen側(NodeA)とWordCount側(NodeB)でノードが別れる</li>
-  <li>(手順1)FileOpen側はFilePloxyにDataRecordをputする</li>
-  <li>(手順2)WordCount側は処理の後、ackを返信する</li>
+  <li>二つのDataGearManagerのペアで構成される</li>
+  <li>acknowledgeを逆方向のRemoteDGMによる通信で実現する(現在は直接送信)</li>
 </ul>
 <div style="text-align: center;">
-  　<img src="images/slideGearsWC.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/slideGearsWC.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;">
-  　<img src="images/slideGearsWC.pdf" alt="ChristieAPIによるWordCount" width="800" />
+　<img src="images/slideGearsWC.pdf" alt="リモートDGMによるWordCount" width="550" />
 </div>


@@ -530,17 +489,13 @@
 <ul>
   <li>実装ずみ
     <ul>
-      <li>keyアクセスに対応したファイル通信
+      <li>API:put/takeに対応したファイル通信
         <ul>
-          <li>単一のQueueによる通信の記述</li>
+          <li>単一のQueueによる通信の記述をした</li>
         </ul>
       </li>
-      <li>リストとなるTree
-        <ul>
-          <li>赤黒木</li>
-        </ul>
-      </li>
-      <li>atomicな操作が行えるQueue
+      <li>QueueのリストとなるTree(赤黒木)</li>
+      <li>atomicな操作が行えるQueue(SynchronizedQueue)
         <ul>
           <li>複数からのアクセス時にデータ整合を保つ</li>
         </ul>
@@ -549,8 +504,8 @@
   </li>
   <li>実装中
     <ul>
-      <li>keyアクセスが行えるQueueのリスト</li>
-      <li>リスト単位での通信の記述</li>
+      <li>key指定による任意なstreamの操作が行えるファイル</li>
+      <li>ファイル単位での通信の記述(Queue単体でない)</li>
     </ul>
   </li>
 </ul>
@@ -580,10 +535,9 @@
           <li>Proxyによるファイル通信</li>
         </ul>
       </li>
-      <li>GearsOSの調査</li>
     </ul>
   </li>
-  <li>Streamのリスト単位での通信の完成</li>
+  <li>Queue(stream)単位でない、ファイル単位の通信</li>
 </ul>


@@ -607,8 +561,8 @@
   </li>
   <li>Securityシステムの追加
     <ul>
-      <li>証明書などによるファイル操作制限</li>
-      <li>不正な分散ファイルシステムへのアクセス</li>
+      <li>ファルパーミッション</li>
+      <li>不正な分散ファイルシステムへのアクセスの防止</li>
     </ul>
   </li>
 </ul>
@@ -634,61 +588,80 @@
   </li>
 </ul>

-<pre><code>__code Task2(TQueue* localDGMQueue){
-    goto localDGMQueue-&gt;take(Task3);
-}
-
-__code Task3(TQueue* localDGMQueue, FileString* string){
-    printf("take[%s] [num:%d]\n", string-&gt;str, string-&gt;size);
-    goto getData();
-}
-
-//プログラマが実装したいstub
-__code Task3_stub(struct Context* context){
-    TQueue* localDGMQueue = (struct TQueue*)Gearef(context, TQueue)-&gt;tQueue;
-    FileString* string = Gearef(context, TQueue)-&gt;data;
-    goto Task3(context, localDGMQueue, string);
-}
-
-//自動生成されたErrorなstub
-__code Task3_stub(struct Context* context) {
-	TQueue* localDGMQueue = Gearef(context, TQueue);
-	FileString* string = Gearef(context, FileString);
-	goto Task3(context, localDGMQueue, string);
-}
-</code></pre>
-


 </div>

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="並列処理構文par-gotoが持つ問題">並列処理構文par gotoが持つ問題</h2>
+<h2 id="トランスコンパイラのバグの例">トランスコンパイラのバグの例</h2>
 <ul>
-  <li>par gotoとはGearsOSに実装された並列処理構文である</li>
-  <li>StreamQueueに対するput/takeの並列処理の実装をpar goto構文で試みた</li>
-  <li>par gotoはトランスコンパイラへの依存性が高い
-    <ul>
-      <li>stubCodeGearのように任意な書き換えが行えない</li>
-    </ul>
-  </li>
-  <li>特定のCodeGearの宣言のみでしか正常な処理が生成されない
-    <ul>
-      <li>Interfaceに記述されたAPICodeGearではバグが生じる</li>
-      <li>par gotoでの使用を前提としたCodeGearを書かなくてはならない</li>
-    </ul>
-  </li>
-  <li>処理が重いという問題点も存在する</li>
+  <li>ContextからのDataGearの取り出し方が間違っている
+```
+__code Task3(TQueue* localDGMQueue, FileString* string){
+  goto Task4();
+}</li>
 </ul>

-
+<p>__code Task3_stub(struct Context* context){   //正しいstub
+  TQueue* localDGMQueue = (struct TQueue<em>)Gearef(context, TQueue)-&gt;tQueue;
+  FileString</em> string = Gearef(context, TQueue)-&gt;data;
+  goto Task3(context, localDGMQueue, string);
+}</p>

-</div>
+<p>__code Task3_stub(struct Context* context) {  //自動生成されたErrorなstub
+	TQueue* localDGMQueue = Gearef(context, TQueue);
+	FileString* string = Gearef(context, FileString);
+	goto Task3(context, localDGMQueue, string);
+}</p>
+<pre><code>
+## 並列処理構文par gotoが持つ問題
+- par gotoとはGearsOSに実装された並列処理構文である
+- StreamQueueに対するput/takeの並列処理の実装をpar goto構文で試みた
+- par gotoはトランスコンパイラへの依存性が高い
+  - stubCodeGearのように任意な書き換えが行えない
+- 特定のCodeGearの宣言のみでしか正常な処理が生成されない
+  - Interfaceに記述されたAPICodeGearではバグが生じる
+  - par gotoでの使用を前提としたCodeGearを書かなくてはならない
+- 処理が重いという問題点も存在する
+
+##  GearsFile APIによるWordCount(1/3)
+- FileOpen側(NodeA)とWordCount側(NodeB)でノードが別れる
+- (手順1)FileOpen側はFilePloxyにDataRecordをputする
+- (手順2)WordCount側は処理の後、ackを返信する
+&lt;div style="text-align: center;"&gt;
+  　&lt;img src="images/slideGearsWC.pdf" alt=ChristieAPIによるWordCount width="800"&gt;
+&lt;/div&gt;

-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h2 id="以下返答用">以下返答用</h2>
+##  GearsFile APIによるWordCount(2/3)
+- (手順3)1,2をループし、FileOpen側はEoFならフラグを送信する
+&lt;div style="text-align: center;"&gt;
+  　&lt;img src="images/slideGearsWC.pdf" alt=ChristieAPIによるWordCount width="800"&gt;
+&lt;/div&gt;
+
+##  GearsFile APIによるWordCount(3/3)
+- (手順4)EoFを受信したWordCountは結果を返信し、双方の処理を終了させる
+&lt;div style="text-align: center;"&gt;
+  　&lt;img src="images/slideGearsWC.pdf" alt=ChristieAPIによるWordCount width="800"&gt;
+&lt;/div&gt;
+
+## 以下返答用
+
+## PeekのImplementation
+- QueueからElement経由でDataGearを取り出す
+- Takeとは異なり、Queueのリンクを修正せずに、取り出されるデータをnextへ引き渡す
+</code></pre>
+<p>__code peekSingleLinkedQueue(struct SingleLinkedQueue* queue, __code next(union Data* data, …)) {
+    struct Element* top = queue-&gt;top;
+    struct Element* nextElement = top-&gt;next;
+    if (queue-&gt;top == queue-&gt;last) {
+        data = NULL;
+    } else {
+        data = nextElement-&gt;data;
+    }
+    goto next(data, …);
+}
+```</p>


@@ -699,7 +672,7 @@
 <h2 id="takeputpeek-1">Take/Put/Peek</h2>
 <ul>
   <li>PeekはReadOnly (最新の設定を読みこむなど)</li>
-  <li>Take/PutはDGが一つならUpDataに相当する</li>
+  <li>Take/PutはDataGearが一つならUpdateに相当する</li>
   <li>書き込みが単一スレッドなら順序は保証される</li>
   <li>書き込みが複数の場合、Putの順序は保証されない</li>
   <li>データベースとの違い
@@ -774,6 +747,27 @@
   </li>
 </ul>

+
+
+</div>
+
+<div class='slide'>
+  <!-- _S9SLIDE_ -->
+<h2 id="複数のストリームによる利点">複数のストリームによる利点</h2>
+<ul>
+  <li>例えばUSBは複数のチャネルを持つ
+    <ul>
+      <li>メタデータの取り出しは別streamになる</li>
+    </ul>
+  </li>
+  <li>複数の通信によりファイル通信の制御を行う場合がある
+    <ul>
+      <li>通信の停止などのための通信</li>
+    </ul>
+  </li>
+  <li>通信として使う場合に複数のプロトコルがある方が良い(FTP)</li>
+</ul>
+
 </div>