Mercurial > hg > Papers > 2021 > anatofuz-master
changeset 66:ae6f626e8816
...
author | anatofuz <anatofuz@cr.ie.u-ryukyu.ac.jp> |
---|---|
date | Wed, 03 Feb 2021 16:46:23 +0900 |
parents | e88c0e26d331 |
children | 1a2b09854938 |
files | paper/chapter/03-gears.tex paper/chapter/04-interface.tex paper/master_paper.pdf paper/master_paper.tex |
diffstat | 4 files changed, 49 insertions(+), 1 deletions(-) [+] |
line wrap: on
line diff
--- a/paper/chapter/03-gears.tex Wed Feb 03 15:44:54 2021 +0900 +++ b/paper/chapter/03-gears.tex Wed Feb 03 16:46:23 2021 +0900 @@ -16,6 +16,8 @@ \section{Context} Contextとは従来のOSのプロセスに相当する概念である。 GearsOSでのデータの単位から見ると、 MetaDataGearに相当する。 +その為ノーマルレベルのCodeGearからはcontextは直接参照しない。 +contextの操作をしてしまうと、メタレベルとノーマルレベルの分離をした意味がなくなってしまう為である。 ContextはGearsOSの計算で使用されるすべてのDataGearとCodeGearを持つ。 各CodeGear、DataGearはContextはそれぞれ配列形式でContextにデータを格納する場所が用意されている。 @@ -31,6 +33,39 @@ 計算で必要なDataGearは、 CbCの中でアロケーションした場合はContextにヒープに書き込まれる。 ヒープにはDataGearと、書き込んだDataGearのメタ情報が記載されているMetaDataGearで構成されている。 +Contextはプロセスに相当するので、ユーザープログラムごとにCotnextが存在する。 +このContextをUser Contextと呼ぶ。 +さらに実行しているGPUやCPUごとにContextが必要となる。 +これらはCPU Contextと呼ばれる。 +GearsOSはOSであるため、全体を管理するKernelのContextも必要となる。 +これはKernelContextやKContextと呼ばれる。 +KContextはすべてのContextを参照する必要がある。 +OSが持たなければならない割り込みのフラグなどはKContextに置かれている。 +GearsOSのメタレベルのプログラミングでは、 今処理をしているContextが誰のContextであるかを強く意識する必要がある。 + +GearsOSではCodeGearの入力は、 メタレベルから見るとContextのみである。 +実際にCodeGearを実行する際は、Contextから計算に必要なDataGearを取得する必要がある。 +これはStubCodeGearと呼ばれるMetaCodeGearが実行する。 + +\section{TaskManager} +TaskManagerは性質上シングルトンである。 +その為、複数Workerを走らせた場合でも1全体で1つのみの値を持っていたいものはTaskManagerが握っている必要がある。 +例えばモデル検査用の状態保存用のデータベース情報は、 TaskManagerが所有している。 + +\section{Worker} +WorkerはWorkerの初期化にスレッドを作る。 +GearsOSではスレッドごとにそれぞれContextが生成される。 +Workerはスレッド作製後にContextの初期化APIを呼び出し、自分のフィールドにContextのアドレスを書き込む。 + +スレッド作製後はTaskManagerからTaskを取得する。 +TaskはContextの形で表現されているために、WorkerのContextをTaskに切り替え、 Taskの次の継続に実行する。 +OutputDataGearがある場合は、Task実行後にDataGearの書き出しが行われる。 + +WorkerはCodeGearの前後で確実に呼び出される。 +この性質を利用すると、 CodeGearの実行の前後での状態を記録することが可能である。 +つまりモデル検査が可能である為、モデル検査用のWorkerを定義して入れ替えるとコードに変更を与えずに実行できる。 +Worker自体はInterfaceで表現されているために、入れ替えは容易となっている。 +GearsOSでは通常のWorkerとしてCPUWorkerを、GPUに関連した処理をするCUDAWorker、合間にモデル検査関連のメタ計算をはさむMCWorkerが定義されている。 \section{union Data型} ContextはすべてのDataGearの型定義を持っている。
--- a/paper/chapter/04-interface.tex Wed Feb 03 15:44:54 2021 +0900 +++ b/paper/chapter/04-interface.tex Wed Feb 03 16:46:23 2021 +0900 @@ -104,6 +104,8 @@ このCodeGearのことをprivate CodeGearと呼ぶ。 privateCodeGearにgotoする場合、 goto元のCodeGearからは\texttt{goto meta}経由で遷移する。 goto metaが発行されるとStub Code Gearに遷移するが、現在のシステムではInterfaceから値を取得しに行く。 +private CodeGearの入力もStubから取得したいと考え、 ImplementをInterfaceのつもりでGearsOSのコードを記述した。 + \section{Interfaceの実装のCbCファイルへの構文の導入}
--- a/paper/master_paper.tex Wed Feb 03 15:44:54 2021 +0900 +++ b/paper/master_paper.tex Wed Feb 03 16:46:23 2021 +0900 @@ -1,13 +1,24 @@ \documentclass[12pt,a4paper,uplatex]{ujreport} \usepackage{master_paper} \usepackage{ascmac} -\usepackage[dvipdfmx]{graphicx} +\usepackage[dvipdfmx]{hyperref,graphicx} \usepackage{here} \usepackage{listings} \usepackage{comment} \usepackage{url} \usepackage[deluxe, multi]{otf} +% for hyperref +\usepackage{pxjahyper} +\hypersetup{ + colorlinks=false, % リンクに色をつけない設定 + bookmarks=true, % 以下ブックマークに関する設定 + bookmarksnumbered=true, + pdfborder={0 0 0}, + bookmarkstype=toc +} + + %\input{dummy.tex} %% font