1
|
1 \chapter{Continuation based C}
|
4
|
2 Continuation based C(CbC)\cite{cbcllvm,cbc}とはCの下位言語である.
|
|
3 function callの代わりにgotoによる継続を用いる.
|
|
4 CbCのプログラムはCodeGearと呼ばれる処理の単位で記述し,ノーマルレベルとメタレベルの処理を切り分けることが可能である.
|
|
5
|
1
|
6 \section{CodeGearとDataGear}
|
4
|
7 CbCでは関数の代わりにCodeGearという単位でプログラミングを行う.
|
|
8 CodeGearは\emph{\_\_code}という記述で宣言することができる.
|
|
9 データの単位にはDataGearと呼ばれる変数データを用いる.
|
|
10 DataGearを入力として受け取り,別のDataGearに書き込み出力することができる.
|
|
11 特に入力のDataGearをInput DataGear,出力のDataGearをOutput DataGearと呼ぶ.
|
|
12 gotoで次のCodeGearに遷移することができ,その際Output DataGearを次のCodeGearのInput DataGearとして渡すことができる.
|
|
13
|
|
14 \section{継続}
|
|
15 CodeGearから次のCodeGearに遷移していく一連の動作を継続と呼ぶ.
|
|
16 CbCの継続はfunction callをせずにgotoによるjmpで行われる.
|
|
17 function callによる継続と異なり,jmpによる継続はstackなどの環境を保存しないことから軽量である.
|
|
18 そのことからCbCにおける継続を特に軽量継続と呼ぶ.
|
|
19
|
|
20 \section{CbCの記述例}
|
|
21 CbCのプログラム例をソースコード\ref{src:cbc}に示す.まずmain関数においてadd1 CodeGearへgotoを行う.
|
|
22 その際add1へInput DataGearとしてnを渡す.
|
|
23 add1は処理の最後にadd2 CodeGearへgotoを行う.
|
|
24 その際Output DataGear out\_nをadd2のInput DataGearとして渡す.
|
|
25 このようにCbCではCodeGearのOutput DataGearを次のCodeGearのInput DataGearとして渡すことを繰り返すことで処理を進める.
|
|
26
|
|
27 \lstinputlisting[caption=CbCのプログラム例,label=src:cbc]{src/hello.cbc}
|
|
28
|
1
|
29
|
|
30 \chapter{GearsOS}
|
4
|
31 GearsOS\cite{gears,gearsos,cr}は 信頼性と拡張性の両立を目的として,開発されている.
|
|
32 Gearという概念があり,実行の単位をCodeGear,データの単位をDataGearと呼ぶ.
|
|
33 軽量継続を基本とし,stackを持たない代わりに全てをContext経由で実行する.
|
|
34 ノーマルレベルとメタレベルの処理を切り分けることができ,同様にGearの概念を持つCbC(Continuation based C)で記述されている.
|
|
35 GearsOSは現在開発途上であり,OSとして動作するために今後実装しなければならない機能がいくつか残っている.
|
5
|
36
|
|
37 \section{stubCodeGear}
|
|
38 図\ref{fig:meta-cgdg}はCodeGearの遷移とMetaCodeGearの関係を表している.
|
|
39 ノーマルレベルで見るとCodeGearがDataGearを受け取り,
|
|
40 処理後,DataGearを次のCodeGearに渡すという動作をしているように見える.
|
|
41 実際にはデータの整合性の確認や資源管理などのメタレベルの処理が存在し,
|
|
42 それらの計算はMetaCodeGearで行われる.
|
|
43 その際,MetaCodeGearに渡されるDataGearのことは特にMetaDataGearと呼ばれる.
|
|
44 CodeGearの前に実行されるMetaCodeGearは特にstubCodeGearと呼ばれ,
|
|
45 メタレベルを含めるとstubCodeGearとCodeGearを交互に実行する形で遷移していく.
|
|
46 \begin{figure}[h]
|
|
47 \begin{center}
|
|
48 \includegraphics[width=100mm]{figs/meta-cg-dg.pdf}
|
|
49 \end{center}
|
|
50 \caption{CodeGearとMetaCodeGearの関係}
|
|
51 \label{fig:meta-cgdg}
|
|
52 \end{figure}
|
|
53
|
|
54 \section{Context}
|
|
55 Contextは全てのCodeGear,DataGearを参照することができるMetaDataGearで,従来OSのプロセスに相当する.
|
|
56 OS全体のContextを管理するKernel Contextやユーザープログラムごとに存在するUser Contextなどがある.
|
|
57 ノーマルレベルのCodeGearがContextを直接参照してしまうと,メタレベルを切り分けた意味がなくなってしまう.
|
|
58 そのためContextは必ずMetaDataGearとしてMetaCodeGearから参照される.
|
1
|
59
|
|
60 \chapter{Christie}
|
4
|
61 Christieは当研究室で開発を行っているJavaで記述された分散フレームワークである.
|
5
|
62 CbCと似ているが別物のGearという概念や,任意のTopologyを形成するためのTopologyManagerがある.
|
|
63
|
|
64 \section{Gearの概念}
|
|
65 Christieには以下の4つのGearという概念が存在する.
|
|
66
|
|
67 \begin{itemize}
|
|
68 \item CodeGear
|
|
69 \item DataGear
|
|
70 \item CodeGearManager(以下CGM)
|
|
71 \item DataGearManager(以下DGM)
|
|
72 \end{itemize}
|
|
73
|
4
|
74 CodeGearはクラスやスレッドに相当する.DataGearは変数データに相当し,Javaのアノテーションを用いて記述される.
|
5
|
75 CGMはいわゆるノードに相当し,CodeGear,DataGear,DGMを管理する.
|
|
76 複数のCGM同士が配線され,DataGearを送信し合うことで分散処理を実現している.
|
|
77 DGMはDataGearを管理しているもので変数プールに相当する.
|
|
78
|
1
|
79 \section{DataGearManager}
|
5
|
80 DataGearManagerはkey value storeの構造を持つ.
|
|
81 CGMが利用するCGのkeyとputされたDataGearの組み合わせでDataGearを管理する.
|
|
82 DGMはLocalDGMとRemoteDGMに区別することができる.
|
|
83 LocalDGMはCGM自身が所持するDataGearのプールである.
|
|
84 ReomoteDGMはCGMが配線されている別のCGMがもつDGのプールである.
|
|
85
|
|
86 \section{Topology-Manager}
|
|
87 Christieには任意のtopologyを生成し,ノード同士の通信接続を管理ことができるTopology-Managerという機能が存在する.
|
|
88 Topology-Managerで生成できるtopologyには静的topologyと動的topologyの2つがある.
|
|
89 静的topologyはプログラマが任意のtopologyとノードの配線を行うことができる.
|
|
90 dotファイルにノードの配線を記述し,Topology-Managerに参照させることで生成する.
|
|
91 dotファイルに記述したノードの数と参加ノードの数が一致した場合に動作する.
|
|
92 動的topologyは参加を表明したノードに対し,自動的に配線を行う.
|
1
|
93
|
|
94 \chapter{UnixのFileSystem}
|
|
95 \section{inode}
|
6
|
96 主にUnix系のファイルシステムで用いられる,ファイルの属性情報が書かれたデータである.
|
|
97 inodeにおけるファイルの属性情報は表\ref{table:inode}のようなものがある.
|
|
98 またinodeは識別番号としてinode numberを持つ.
|
|
99 inode numberは一つのファイルシステム内で一意の番号であり,\emph{ls -l}コマンドで確認可能である.
|
|
100 inodeはファイルシステム始動時にinode領域をディスク上に確保する.
|
|
101 そのためinode numberには上限があり,それに伴いファイルシステム上で扱えるファイル数の上限も決まる.
|
|
102 inode numberの最大値は\emph{df -i}コマンドで確認可能である.
|
|
103
|
|
104 \begin{table}[htpb]
|
|
105 \begin{center}
|
|
106 \small
|
|
107 \begin{tabular}[htpb]{|c||c|}
|
|
108 \hline
|
|
109 File Types & directoryやregular fileなど,ファイルの種類 \\
|
|
110 \hline
|
|
111 Permissions & read write executeの実行可否\\
|
|
112 \hline
|
|
113 UID & ファイル所有者のID \\
|
|
114 \hline
|
|
115 GID & ファイル所有グループのID \\
|
|
116 \hline
|
|
117 File Size & ファイルのサイズ \\
|
|
118 \hline
|
|
119 Time Stamps & ファイル作成,編集日時 \\
|
|
120 \hline
|
|
121 Number of link & ハードリンクの数 \\
|
|
122 \hline
|
|
123 Location on hard disk & データのアドレス\\
|
|
124 \hline
|
|
125 \end{tabular}
|
|
126 \caption{inodeでのファイル属性情報}
|
|
127 \label{table:inode}
|
|
128 \end{center}
|
|
129 \end{table}
|
1
|
130
|
|
131 \chapter{GearsFileSystemのdirectory}
|
|
132 \section{Treeによるdirectory構造}
|
|
133 \section{Unix Like な interface}
|
|
134 \subsection{mkdir}
|
|
135 \subsection{ls}
|
|
136 \subsection{cd}
|
|
137 \section{inodeを用いたdirectory entry}
|
|
138 \section{非破壊的編集によるBackup}
|
|
139
|
|
140 \chapter{File構造}
|
|
141 \section{I/O Stream}
|
|
142 \section{logによるバージョン管理}
|
|
143
|
|
144 \chapter{WordCount}
|
4
|
145 WordCount例題\cite{file}はGearsOSのファイルシステムを構築する際に用いてる例題である.
|
|
146 指定したファイルの文字数や行数,ファイルの内の文字列を出力する.
|
|
147 図\ref{fig:WCStates}はWordCount例題の処理の流れを示している.
|
|
148 大きく分けて,指定したファイルをFile構造体としてopenするFileOpenスレッド,
|
|
149 File構造体を受け取り文字数と行数をcountUpするWordCountスレッドの二つのCodeGearで記述することができる.
|
|
150 ファイル内の文字列を行ごとにCountUpに送信し,EOFを受け取ったらループを抜けfinishに移行する.
|
1
|
151 \section{API}
|
|
152 \section{GearBox的な処理}
|
|
153
|
|
154 \chapter{今後の課題}
|
|
155 \section{分散ファイルシステム}
|
|
156 \section{GearsAgda}
|
|
157 \section{shell}
|
|
158 \section{モデル検査} |