__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 +__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)でノードが別れる -- (手順1)FileOpen側はFilePloxyにDataRecordをputする -- (手順2)WordCount側は処理の後、ackを返信する -<div style="text-align: center;"> - 　<img src="images/slideGearsWC.pdf" alt=ChristieAPIによるWordCount width="800"> -</div> +

+ +

並列処理構文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を返信する

+ + + +

-## GearsFile APIによるWordCount(2/3) -- (手順3)1,2をループし、FileOpen側はEoFならフラグを送信する -<div style="text-align: center;"> - 　<img src="images/slideGearsWC.pdf" alt=ChristieAPIによるWordCount width="800"> -</div> +

+ +

GearsFile APIによるWordCount(2/3)

(手順3)1,2をループし、FileOpen側はEoFならフラグを送信する

+ + + +

-## GearsFile APIによるWordCount(3/3) -- (手順4)EoFを受信したWordCountは結果を返信し、双方の処理を終了させる -<div style="text-align: center;"> - 　<img src="images/slideGearsWC.pdf" alt=ChristieAPIによるWordCount width="800"> -</div> +

+ +

GearsFile APIによるWordCount(3/3)

(手順4)EoFを受信したWordCountは結果を返信し、双方の処理を終了させる

-## 以下返答用 + + +

-## PeekのImplementation -- QueueからElement経由でDataGearを取り出す -- Takeとは異なり、Queueのリンクを修正せずに、取り出されるデータをnextへ引き渡す +

+ +

以下返答用

+ + + +

+ +

PeekのImplementation

QueueからElement経由でDataGearを取り出す
Takeとは異なり、Queueのリンクを修正せずに、取り出されるデータをnextへ引き渡す +
```
__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, ...);
+}
 
```
-
__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, …); -} -```
+

@@ -738,7 +794,7 @@

DataGearの型

union Data は一つのプロセス(Context)で使われるすべてのDataGearのUnion
メタ部分に型に対応する番号を持っている
GearsOSはメタ部分に型に対応する番号を持っている
番号を使って型を識別することができる
任意の型を格納できるQueueやStackを作成することが可能
メタレベルではunion Dataを使ってDataGearの詳細に立ち入らず処理できる

RemoteDGMとacknowledge

Take/Put/Peekのコマンドは TCP上でacknowledgeを使って通信されている
これとは別に自分と相手のCodeGearどうしのacknowledgeが必要
RemoteDataGearManager経由でacknowledgeを返すのが正しい
しかし、acknowledgeが重複してしまう
メタプログラミングを利用してこの重複を消すことは可能 +
Take/Put/Peekのコマンドは TCP上でacknowledgeを使って通信されている +
- これとは別に自分と相手のCodeGearどうしのacknowledgeが必要
+
RemoteDataGearManager経由でacknowledgeを返すのが正しい
- しかし煩雑
- acknowledgeが重複してしまう
- メタプログラミングを利用してこの重複を消すことは可能 +
  - 煩雑な処理
  +

GearsOSのファイルシステムの設計と実装

DataGearとCodeGearという単位を用いるOS
従来のファイルシステムには型とTransactionが無い
DataGear単位のTransactionとしてファイルシステムを設計
DataGear単位のTransactionとしてファイルシステムを設計 +
- 従来のOSのファイルシステムには型とTransactionが無い
+
APIとしてTake/Put/Peekを採用した
通信としてもDBアクセスとしても使える(メモリからSSDへの通信に見える)
本研究ではsocket baseな通信とWordCountの例題を作成した

GearsOSのファイルシステムの設計

DataGearの単位でデータを操作したい
通信データに対応した複数のストリームを持つ
ファイルは通信データに対応した複数のストリームを持つ
Transactionとしてatomicに操作したい
- 従来のファイルシステムはTransactionはUserレベルで実装される
- 従来のファイルシステムのTransactionはUserレベルで実装される
ファイル操作と通信を同じAPIで実現する
- Take/Put/Peek
- ChristieのDataGearManagerを参考にする
- Take/Put/Peek

ファイルシステム向けの機能を追加したい
- DNS
- 中枢としてのTopologyのノード監視
- 中枢としてのTopologyノード監視

Securityシステムの追加
- ファルパーミッション
- 不正な分散ファイルシステムへのアクセスの防止
- ファイルpermission
- 分散ファイルシステムへの不正なアクセスの防止

@@ -596,72 +599,125 @@

トランスコンパイラのバグの例

ContextからのDataGearの取り出し方が間違っている -``` -__code Task3(TQueue* localDGMQueue, FileString* string){ - goto Task4(); -}
ContextからのDataGearの取り出し方が間違っている

__code Task3_stub(struct Context* context){ //正しいstub - TQueue* localDGMQueue = (struct TQueue)Gearef(context, TQueue)->tQueue; - FileString string = Gearef(context, TQueue)->data; +

__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
+__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)でノードが別れる -- (手順1)FileOpen側はFilePloxyにDataRecordをputする -- (手順2)WordCount側は処理の後、ackを返信する -<div style="text-align: center;"> - 　<img src="images/slideGearsWC.pdf" alt=ChristieAPIによるWordCount width="800"> -</div> + + +並列処理構文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を返信する + + + 　 + + + + + -## GearsFile APIによるWordCount(2/3) -- (手順3)1,2をループし、FileOpen側はEoFならフラグを送信する -<div style="text-align: center;"> - 　<img src="images/slideGearsWC.pdf" alt=ChristieAPIによるWordCount width="800"> -</div> + + +GearsFile APIによるWordCount(2/3) + + (手順3)1,2をループし、FileOpen側はEoFならフラグを送信する + + + 　 + + + + + -## GearsFile APIによるWordCount(3/3) -- (手順4)EoFを受信したWordCountは結果を返信し、双方の処理を終了させる -<div style="text-align: center;"> - 　<img src="images/slideGearsWC.pdf" alt=ChristieAPIによるWordCount width="800"> -</div> + + +GearsFile APIによるWordCount(3/3) + + (手順4)EoFを受信したWordCountは結果を返信し、双方の処理を終了させる + + + 　 + -## 以下返答用 + + + -## PeekのImplementation -- QueueからElement経由でDataGearを取り出す -- Takeとは異なり、Queueのリンクを修正せずに、取り出されるデータをnextへ引き渡す + + +以下返答用 + + + + + + + +PeekのImplementation + + QueueからElement経由でDataGearを取り出す + Takeとは異なり、Queueのリンクを修正せずに、取り出されるデータをnextへ引き渡す + __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, ...); +} -__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, …); -} -``` + + @@ -722,7 +778,7 @@ DataGearの型 union Data は一つのプロセス(Context)で使われるすべてのDataGearのUnion - メタ部分に型に対応する番号を持っている + GearsOSはメタ部分に型に対応する番号を持っている番号を使って型を識別することができる任意の型を格納できるQueueやStackを作成することが可能メタレベルではunion Dataを使ってDataGearの詳細に立ち入らず処理できる @@ -736,13 +792,19 @@ RemoteDGMとacknowledge - Take/Put/Peekのコマンドは TCP上でacknowledgeを使って通信されている - これとは別に自分と相手のCodeGearどうしのacknowledgeが必要 - RemoteDataGearManager経由でacknowledgeを返すのが正しい - しかし、acknowledgeが重複してしまう - メタプログラミングを利用してこの重複を消すことは可能 + Take/Put/Peekのコマンドは TCP上でacknowledgeを使って通信されている + + これとは別に自分と相手のCodeGearどうしのacknowledgeが必要 + + + RemoteDataGearManager経由でacknowledgeを返すのが正しい - しかし煩雑 + acknowledgeが重複してしまう + メタプログラミングを利用してこの重複を消すことは可能 + + 煩雑な処理 + +