# HG changeset patch
# User autobackup
# Date 1621782604 -32400
# Node ID 937323467f4db139ba3ac9876a1789328c5366a8
# Parent bc17d71e22eb79dc7e9780f7a2d6424fb416e711
backup 2021-05-24
diff -r bc17d71e22eb -r 937323467f4d user/Itsuki.md
--- a/user/Itsuki.md Sun May 23 00:10:03 2021 +0900
+++ b/user/Itsuki.md Mon May 24 00:10:04 2021 +0900
@@ -1,152 +1,1 @@
-# GearsOSの分散ファイルシステムの設計
-author: Takahiro Ikki, Shinji Kono
-profile: 琉球大学
-lang: Japanese
-code-engine: coderay
-
-## メモ
-従来のファイルシステムの問題を加える、
-
-
-
-
-## 研究概要
-- 当研究室ではOSの信頼性と拡張性の保証を目的としたGearsOSを開発している。
- - GearsOSは開発途上であり、実装が必要な機能が複数存在している。
-- GearsOSの分散ファイルシステムを開発したい。
-- 分散フレームワークChristieの構成をもとにGearsファイルシステムを構築する。
-
-
-## GearsOS概要
-- GearsOSの目的を説明したい。証明やモデル検査に適した構成にetc
-- メタとノーマルの分離など
-#
-- コンピュータの土台となるOSは高い信頼性が保証されている必要がある。
-- OSのコードや処理の量は膨大となる。
- - したがって定理支援証明やモデル検査などの形式手法を用いて検証したい。
-- メタレベルとノーマルレベルの計算を分離して記述が行える。
- - メタレベルの計算でプログラムの整合性を検証する。
-
-## Continuation based C(CbC)
-- CbCとは当研究室で開発しているC言語の下位言語である。
-- CbCは関数呼び出しでなく継続を導入している。
- - スタック領域を用いずjmp命令でコード間を移動することにより軽量な継続を実現している。
--
-
-
-## Gearの概念
-
-## Christie
-- 過去の記述↓
-- Christieは当研究室で開発している分散フレームワークである.
-- ChristieではデータをGearという単位で分割して記述を行う。
- - Codegear、DataGear、CodeGearManager、DagaGearManagerの四種類が存在しする。
- - CodeGear = スレッド、クラス
- - DataGear = 変数データ
- - CodeGearManager = ノード
- - DataGearManager = データプール
-
-## Christie's Gear
-### CodeGear(以下CG)
-- 設定されたkeyに全てのDGが格納されると動作し、DGを参照しながらクラス部分を実行できる。
-
-### DataGear(以下DG)
-- CGに指定されたkeyに差し込まれる。
-- アノテーションを使って記述する。
-- ノードの同士がこのDGを差し込み合うことで通信を構成する。
-
-### CodeGearManager(以下CGM)
-- CGを指定してsetupすることでCGを動かすことができる。
-- putという操作でDGを対応したDGMに格納する。
-### DataGearManager(以下DGM)
-- CGMが所持している。
-- プールになっておりputされたDGが保存され、keyとデータが結び付けられる。
-
-
-
-
-
-
-
-#### LocalDGMとRemoteDGM
-- CGMはDGをputという操作を使って、自身や他ノードのDGMにDGを書き込ませる。
-- DGMにはLocalDGMとRemoteDGMが存在する。
- - LocalDGMは各ノード固有のデータベースである。
- - RemoteDGMは他ノードのLocalDGMに対応するプールであり、接続しているノードの数だけ存在する。
-- DGMのput操作を行う際にはLocalとRemoteのどちらかを選ぶ.
- - Localであれば、LocalのCGMが管理するDGMに対しDGを格納。
- - RemoteDGMを指定してputすることで、接続している任意のノードにDGを差し込ませることができる。
-
-## DataGearのアノテーション
-- DGを取り出す際にはCG内で宣言した変数にアノテーションをつける。
-- DGアノテーションにはTake、Peek、TakeFrom、PeekFrom、の4つがある。
- - Take
- - DGMに保管された先頭のDGを読み込み、そのDGを削除する。
- - Peek
- - DGMに保管された先頭のDGを読み込むが、DGが消去されない。そのため特に操作をしない場合、同じデータを参照し続ける。
- - TakeFrom
- - Remote DGM nameを指定することで、その接続先のDGM からTake操作をおこえる。
- - PeekFrom
- - Remote DGM nameを指定することで、その接続先のDGM からPeek操作をおこえる。
-
-
-## TopologyManager
-- 通信形成をより簡潔に行ってくれる機能である。
- - Topologyに参加を表明したノードを自動的に配線する。
- - 自動的に接続しているノードに相対的にラベルをつける。
-- 静的Topology形成
- - dotファイルを与えることノード関係の構築を行う。
- - ノード数が想定と一致しないと動作しない。
-- 動的Topology形成
- - 参加を表明したノードに対し、動的にノード同士の関係を作る。
- - 例えばTreeを構成する場合、参加したノードから順にrootに近い役割を与える。
-
-```Code
-digraph test {
- node0 -> node1 [label="right"]
- node1 -> node2 [label="right"]
- node2 -> node0 [label="right"]
-}
-```
-
-## Christieのコード例
-- メインがDGMなのでいらないかも
-```
-public class StartHelloWorld extends StartCodeGear {
-
- public static void main(String[] args){
- CodeGearManager cgm = createCGM(10000);
- cgm.setup(new HelloWorldCodeGear());
- cgm.getLocalDGM().put("helloWorld","hello");
- cgm.getLocalDGM().put("helloWorld","world");
- }
-}
-```
-```
-hello world
-```
-
-
-```
-public class HelloWorldCodeGear extends CodeGear {
-
- @Take
- String helloWorld;
-
- @Override
- protected void run(CodeGearManager cgm) {
- System.out.print(helloWorld + " ");
- cgm.setup(new HelloWorldCodeGear());
- }
-}
-```
-
-## GearsOSのファイルアクセス
-
-## ChristieAPI
-
-## FileSystem Implementation
-
-## 競合的アクセスを含む分散計算の検証
-
-## 比較とまとめ
\ No newline at end of file
+ss
\ No newline at end of file
diff -r bc17d71e22eb -r 937323467f4d user/Itsuki/sigos2021.md
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/user/Itsuki/sigos2021.md Mon May 24 00:10:04 2021 +0900
@@ -0,0 +1,202 @@
+# GearsOSの分散ファイルシステムの設計
+author: Takahiro Ikki, Shinji Kono
+profile: 琉球大学
+lang: Japanese
+code-engine: coderay
+
+## メモ
+従来のファイルシステムの問題を加える、
+
+
+
+
+## 研究概要
+- 当研究室ではOSの信頼性と拡張性の保証を目的としたGearsOSを開発している。
+ - GearsOSは開発途上であり、実装が必要な機能が複数存在している。
+- GearsOSの分散ファイルシステムを開発したい。
+- 分散フレームワークChristieの構成をもとにGearsファイルシステムを構築する。
+
+
+## GearsOS概要
+- GearsOSの目的を説明したい。証明やモデル検査に適した構成にetc
+- メタとノーマルの分離など
+#
+- コンピュータの土台となるOSは高い信頼性が保証されている必要がある。
+- OSのコードや処理の量は膨大となる。
+ - したがって定理支援証明やモデル検査などの形式手法を用いて検証したい。
+- OSを形式手法にて証明するには状態遷移単位での記述が求められる。
+- メタレベルとノーマルレベルの計算を分離して記述が行える。
+ - メタレベルの計算でプログラムの整合性を検証する。
+
+## Continuation based C(CbC)
+- CbCとは当研究室で開発しているC言語の下位言語である。
+- CbCは関数呼び出しでなく継続を導入している。
+ - スタック領域を用いずjmp命令でコード間を移動することにより軽量な継続を実現している。
+- 関数の代わりにCodeGearという単位でプログラムを行う
+
+## Gearの概念
+- CodeGearはDataGearと呼ばれる変数データを入力として受け取り、その結果を別のDataGear に書き込む.
+-
+ - 入力のDataGearをInputDataGear、出力されるDataGearをOutputDataGearと呼ぶ。
+ - CodeGearが参照できるDataGearはInput/output DataGearに限定される。
+- CbCではこの軽量継続を用いてfor 文などのループ文を実装する。
+- CodeGearは関数呼び出しのスタックを持たないため、一度CodeGearを遷移すると元の処理に戻ってくることができない。
+
+## CbC記述例
+- CbCを利用したシステムコール のディスパッチ部分を示す。
+ - 特定のシステムコール の場合、CbCで実装された処理にgoto文を使って継続する。
+- CodeGearへのアドレス配列がcbccodesに格納されている。
+- 引数として渡しているcbc_retは、システムコールの返り値をレジスタに代入するCodeGearである。
+
+```code
+void syscall(void)
+{
+ int num;
+ int ret;
+ if((num >= NELEM(syscalls)) && (num <= NELEM(cbccodes)) &&
+ cbccodes[num]) {
+ proc->cbc_arg.cbc_console_arg.num = num;
+ goto (cbccodes[num])(cbc_ret);
+ }
+```
+
+
+
+システムコールディスパッチの状態遷移図
+
+
+## GearsOS
+- CbCを用いて記述された、CodeGearとその入出力であるDataGearを基本としたOSである。
+- 現在は並列フレームワークとして実装されており、実用的なOSのプロトタイプとして実装を目指している。
+- 遷移する各CodeGearの実行に必要となるメタ計算は、MetaCodeGearと呼ばれるCodeGearごとに実装されたCodeGearで計算する。
+ - MetaCodeGear内で参照されるDataGearをMetaDataGearと呼ぶ。
+- MetaCodeGearやMetaDataGearはプログラマが直接実行することはなく、現在はPerlスクリプトにより、GearsOSのビルド時に実行される。
+
+
+
+CodeGearから別のCodeGearへ遷移する際のDataGearなどの関係性
+
+
+- 実際には CodeGear の実行の前後に実行される MetaCodeGear や入出力の DataGear を MetaDataGear から取り出すなどのメタ計算が加わる。
+
+## Context
+- 遷移先の CodeGear と MetaCodeGear の紐付けや、計算 に必要な DataGear を保存や管理を行う MetaDataGear と して context がある。
+ - 処理に必要なCodeGearの番号と MetaCodeGear の対応表や、DataGearの格納場所を持つ。
+ - 計算に必要なデータ構造と処理を持つデータ構造であることから、contextは従来のOSのプロセスに相当するものと言える。
+
+
+
+
+
+## Christie
+- Christieはjava言語で記述された分散フレームワークである.
+- GearsOSのとは異なる、Gearというプログラミング概念をもつ。
+ - Codegear、DataGear、CodeGearManager、DagaGearManagerの四種類が存在しする。
+ - CodeGear (CG) : スレッド、クラス
+ - DataGear (DG) : 変数データ
+ - CodeGearManager (CGM) : ノード
+ - DataGearManager (DGM) : データプール
+
+
+### CodeGear(以下CG)
+- プログラム(CG)内に記述された全てのDataGearのkeyにデータが格納されると動作し、DGを参照しながらプログラムを実行する。
+
+
+### DataGear(以下DG)
+- keyと変数データの組み合わせで構成される。
+- プリミティブ型を指定する必要がある。(int, string...)
+- アノテーションを用いて記述する。(後述)
+
+### CodeGearManager(以下CGM)
+- CG,DG,DGMを管理する。
+- 分散処理のノードに相当するため、それぞれポートを持つ。
+- putという操作でDGを任意のCGMの持つDGMに格納する。
+### DataGearManager(以下DGM)
+- 格CodeGearManagerが1つづつ所持している。
+- データプールになっておりCGMが利用するDGを全て保持している。
+- LocalDGMとRemoteDGMの二種類存在する。(後述)
+
+
+## DataGearのアノテーション
+- DGを取り出す際にはCG内で宣言した変数にアノテーションをつける。
+- DGアノテーションにはTake、Peek、TakeFrom、PeekFrom、の4つがある。
+ - Take
+ - DGMに保管された先頭のDGを読み込み、そのDGを削除する。
+ - Peek
+ - DGMに保管された先頭のDGを読み込むが、DGが消去されない。そのため特に操作をしない場合、同じデータを参照し続ける。
+ - TakeFrom
+ - Remote DGM nameを指定することで、その接続先のDGM からTake操作をおこえる。
+ - PeekFrom
+ - Remote DGM nameを指定することで、その接続先のDGM からPeek操作をおこえる。
+
+## Christieのコード例
+- Christieを用いてHelloWorldを記述した際のコードが以下となる。
+```
+public class StartHelloWorld extends StartCodeGear {
+
+ public static void main(String[] args){
+ CodeGearManager cgm = createCGM(10000); //CGMの作成
+ cgm.setup(new HelloWorldCodeGear()); //CGMにCGをsetupする
+ cgm.getLocalDGM().put("hellokey","hello"); //setupされたCGが持つDGのkeyにデータを設定する
+ cgm.getLocalDGM().put("hellokey","world");//同上
+ }
+}
+```
+
+```
+public class HelloWorldCodeGear extends CodeGear {
+
+ @Take //アノテーション
+ String hellokey;
+
+ @Override
+ protected void run(CodeGearManager cgm) { //CGの処理内容
+ System.out.print(hellokey + " ");
+ cgm.setup(new HelloWorldCodeGear());
+ }
+}
+```
+
+
+#### LocalDGMとRemoteDGM
+- CGMはDGをputという操作を使って、自身や他ノードのDGMにDGを書き込ませる。
+- DGMにはLocalDGMとRemoteDGMが存在する。
+ - LocalDGMは各ノード固有のデータベースである。
+ - RemoteDGMは他ノードのLocalDGMに対応するプールであり、接続しているノードの数だけ存在する。
+- DGMのput操作を行う際にはLocalとRemoteのどちらかを選ぶ.
+ - Localであれば、LocalのCGMが管理するDGMに対しDGを格納。
+ - RemoteDGMを指定してputすることで、接続している任意のノードにDGを差し込ませることができる。
+
+
+
+
+## TopologyManager
+- 通信形成をより簡潔に行ってくれる機能である。
+ - Topologyに参加を表明したノードを自動的に配線する。
+ - 自動的に接続しているノードに相対的にラベルをつける。
+- 静的Topology形成
+ - dotファイルを与えることノード関係の構築を行う。
+ - ノード数が想定と一致しないと動作しない。
+- 動的Topology形成
+ - 参加を表明したノードに対し、動的にノード同士の関係を作る。
+ - 例えばTreeを構成する場合、参加したノードから順にrootに近い役割を与える。
+
+```Code
+digraph test {
+ node0 -> node1 [label="right"]
+ node1 -> node2 [label="right"]
+ node2 -> node0 [label="right"]
+}
+```
+
+
+
+## GearsOSのファイルアクセス
+
+## ChristieAPI
+
+## FileSystem Implementation
+
+## 競合的アクセスを含む分散計算の検証
+
+## 比較とまとめ
\ No newline at end of file
diff -r bc17d71e22eb -r 937323467f4d user/riono210/sigos2021.md
--- a/user/riono210/sigos2021.md Sun May 23 00:10:03 2021 +0900
+++ b/user/riono210/sigos2021.md Mon May 24 00:10:04 2021 +0900
@@ -173,7 +173,7 @@
---
-### Christie on Unityのコード例
+### Christie \# on Unityのコード例
```cs:UnityStartHelloWorld.cs
public class StartHelloWorld : StartCodeGear {
@@ -202,8 +202,10 @@
### Take annotationの実装
* Christie ではDGを取得するためにannotation を使用している
- * C# ではannotation と同様の機能にattribute がある
- * Take annotationの実装と比較を行う
+ * C# ではannotation と同様の機能にattribute があり、Take をattribute で実装した
+
+* Take はフィールド変数に対して適用する
+
```java:Take.java
@Target(ElementType.FIELD)
@@ -216,11 +218,74 @@
public class Take : Attribute { }
```
+---
+
### MessagePackの相違点
+
+---
+
+### ThreadPoolからTaskへの書き換え
+* Christie ではThreadPool を使用していた
+ * Christie # ではThreadPoolより高機能なTask を用いて書き換えを行った
+
+* Task は複雑な非同期処理を通常のコーディングと同じ感覚で直感的に記述できる
+
+* 裏でThreadPool が動くようになっている
+ * 大きく動作は変わらない
+
+---
+
### ThreadPoolからTaskへの書き換え
+```java:PriorityThreadPoolExecutors.java
+public class PriorityThreadPoolExecutors {
+
+ private static class PriorityThreadPoolExecutor extends ThreadPoolExecutor {
+ private static final int DEFAULT_PRIORITY = 0;
+ private static AtomicLong instanceCounter = new AtomicLong();
+
+ public PriorityThreadPoolExecutor(int corePoolSize, int maximumPoolSize,
+ int keepAliveTime, TimeUnit unit) {
+ super(corePoolSize, maximumPoolSize, keepAliveTime, unit, (BlockingQueue) new PriorityBlockingQueue(10,
+ ComparableTask.comparatorByPriorityAndSequentialOrder()));
+ }
+
+ @Override
+ public void execute(Runnable command) {
+ super.execute(command);
+ }
+ }
+}
+```
+
+
+
+```cs:ThreadPoolExecuters.cs
+public class ThreadPoolExecutors {
+
+ public ThreadPoolExecutors(int nWorkerThreads, int nIOThreads) {
+ ThreadPool.SetMinThreads(nWorkerThreads, nIOThreads);
+ }
+
+ public void Execute(CodeGearExecutor command) {
+ Task.Factory.StartNew(() => command.Run());
+ }
+}
+```
+
+---
+
### Unityで使用されているライブラリとの比較
+Unityで使用されている既存のライブラリとして、Photon Unity Networking 2(PUN2)、MLAPIと、Christie # の比較を行う。
+
+| | Christie # | PUN2 | MLAPI |
+|--- |--- | --- |---|
+|通信方式 |p2p |クライアントサーバ方式 | クライアントサーバ方式|
+|プロトコル | TCP | TCP | TCP |
+|特徴 |通信のためのIP address がプログラム直接記述されていない |Photon Cloud でサーバを自前で用意する必要がない | Unity公式でサポートされている RPC が使用可能|
+
+
### 実装の現状