Papers/2021/ikki-sigos: Paper/paper.tex comparison

comparison Paper/paper.tex @ 5:16305e9540cc

add about context etc

author	ichikitakahiro <e165713@ie.u-ryukyu.ac.jp>
date	Fri, 30 Apr 2021 16:30:47 +0900
parents	48b77cf5b5cd
children	9cf99ee758a5

comparison

equal deleted inserted replaced

-:48b77cf5b5cd
+:16305e9540cc
 当研究室ではOSの信頼性の検証を目的としたOSであるGearsOSを開発している.
 GearsOSはユーザレベルとメタレベルを分離して記述が行える言語であるContinuation based C(以下CbC)で記述されており, Gearというプログラミング概念を持つ.
 GearsOSは現在開発途上であるため, 現在は言語フレームワークとしてしか動作しない。OSとして起動するためにこれから実装が必要な機能が多く存在しており, その中の一つとして分散ファイルシステムが挙げられる.
 GearsOSの分散ファイルシステムを構成するために、当研究室が開発している分散フレームワークChristieの仕組みを用いようと考えた.
 ChrsitieはGearsOSのもつGearという概念とよく似た, 別のGearというプログラミング概念を持っており, DataGearと呼ばれる変数データを接続されたノード同士が送信しあうことで分散処理を簡潔に記述することができる. DataGearは指定された型と名前を持つkeyに対応しており, プログラムが必要なkeyにデータが揃ってから初めてプログラムが処理される.
 また, ChrisiteはTopologyManagerと呼ばれる機能を持っており, 任意の形でノード同士の配線を行いTopologyを形成する機能を持っている.
 %2
 \section{現代のファイルシステムについて}
 %2.1
 \section{Continuation based C}
 GearsOSはC言語の下位言語であるContinuation based Cを用いて記述されている. CbCは関数呼び出しでなく, 継続を導入しており, スタック領域を用いずjmp命令でコード間を移動することにより軽量な継続を実現している. CbCではこの継続を用いてfor文などのループの代わりに再起呼び出しを行う. 実際のOSやアプリケーションを記述する際にはGCCまたはLLVM/clangのCbC実装を用いる.
-CbCでは関数の代わりにCodeGear(以下CG)という単位でプログラミングを行う. CodeGearは\texttt{\_\_code}で宣言を行い, 各CodeGearはDataGearと呼ばれる変数データを入力として受け取り, その結果を別のDataGearに書き込む. 特に入力のDataGeatをInputDataGear, 出力されるDataGearを OutputDataGearと呼ぶ. CodeGearとDataGearの関係図を図\ref{fig:cgdg}に示す.
+CbCでは関数の代わりにCodeGearという単位でプログラミングを行う. CodeGearは\texttt{\_\_code}で宣言を行い, 各CodeGearはDataGearと呼ばれる変数データを入力として受け取り, その結果を別のDataGearに書き込む. 特に入力のDataGeatをInputDataGear, 出力されるDataGearを OutputDataGearと呼ぶ. CodeGearとDataGearの関係図を図\ref{fig:cgdg}に示す.
 CodeGearは関数呼び出しのスタックを持たないため, 一度CodeGearを遷移すると元の処理に戻ってくることができない.
 CbCコードの例をソースコード\ref{label=src:cbc_example}に示す．%refを使う
 \begin{figure}[tb]
 \end{lstlisting}
 \section{CbCを用いたOSの記述}
-CodeGearの遷移はノーマルレベルから見ると単純にCodeGearがDataGearをInput, Outputをのみ繰り返し, コードブロックを移動しているように見えるが, 実際にはCodeGearからCodeGearへの遷移にはデータの整合性の確認などのメタ計算が必要となる.
+CodeGearの遷移はノーマルレベルから見ると単純にCodeGearがDataGearをInput, Outputをのみ繰り返し, コードブロックを移動しているように見える.
+CodeGearが別のDataGearに遷移する際のDataGearとの関係性を図\ref{fig:meta-cgdg} に示す. ノーマルレベルではDataGearを受け取ったCodeGearを実行, 実行結果をDataGearに書き込み別のCodeGearに継続していると見える.
-\ref{fig:meta-cgdg}
+しかし, 実際にはCodeGearから別のCodeGearへの遷移にはデータの整合性の確認などのメタ計算が必要となる.
+コード間の遷移に必要となるメタ計算は,  MetaCodeGearと呼ばれるCodeGearごとに実装されたCodeGearで行う.
+MetaCodeGearで参照されるDataGearをMetaDataGear呼び, また, CodeGearの直前に実行されるMetaCodeGearをStubCodeGearと呼ぶ.
+これらMeta計算部分を含めたCodeGearの遷移とDataGearの関係性を図示すると図\ref{fig:meta-cgdg} の下段の形に表せる. CordGearの実行前後に実行されるMetaCodeGearや入出力のDataGearをMetaDagaGearから取り出すなどのメタ計算が加わる.
+MetaCodeGearは詳細な処理の変更や, スクリプトに問題がある場合を除き, プログラマが直接実装する必要がなく, GearsOSが持つPerlスクリプトにより, GearsOSがビルドされる際に生成される.
+CodeGearの遷移に重要な役割を持つMetaDataGearとしてcontextが存在する。
+contextは遷移先のCodeGearとMetaDataGearの紐付けや, 計算に必要なDataGearの保存や管理を行う.
+加えてcontextは処理に必要になるCodeGearの番号とMetaCodeGearの対応表や, DataGearの格納場所を持つ. contextと各データ構造の役割を図\ref{fig:context}に示す.
+計算に必要なデータ構造と処理を持つデータ構造であることから, contextは従来のOSのプロセスに相当し, ユーザープログラムごとにcontextが存在している.
 \begin{figure}[tb]
 \begin{center}
 \includegraphics[width=80mm]{images/meta-cg-dg.pdf}
 \end{center}
 \caption{CodeGearとMetaCodeGearの関係図}
 \label{fig:meta-cgdg}
 \end{figure}
+\begin{figure}[tb]
+\begin{center}
+\includegraphics[width=80mm]{images/Context_ref.pdf}
+\end{center}
+\caption{Contextを介したCodeGearの継続}
+\label{fig:context}
+\end{figure}
 %3
 \section{論文フォーマットの指針}
 \label{sec:format}

Mercurial > hg > Papers > 2021 > ikki-sigos

comparison Paper/paper.tex @ 5:16305e9540cc