Mercurial > hg > Papers > 2022 > ikki-master

changeset 11:a3cda2aa18aa

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
add par goto??
author ichikitakahiro <e165713@ie.u-ryukyu.ac.jp>
date Thu, 27 Jan 2022 22:49:44 +0900
parents 7573c185aecf
children 2c54886cebef
files Paper/chapter/3-GearsOS.tex Paper/chapter/4-Christie.tex Paper/chapter/5-Implementation.tex Paper/chapter/6-Evaluation.tex Paper/images/GearsFile.graffle.graffle Paper/images/GearsFile.pdf Paper/images/QueueElement.graffle.graffle Paper/images/QueueElement.pdf Paper/images/gearsChrsitieCGM.graffle Paper/images/gearsChrsitieCGM.pdf Paper/images/newGearsReletion.graffle.graffle Paper/images/newGearsReletion.pdf Paper/images/workerRun.pdf Paper/master_paper.pdf Paper/src/LocalDGMQueue.cbc
diffstat 15 files changed, 89 insertions(+), 58 deletions(-) [+]
line wrap: on
line diff
--- a/Paper/chapter/3-GearsOS.tex	Tue Jan 25 22:27:17 2022 +0900
+++ b/Paper/chapter/3-GearsOS.tex	Thu Jan 27 22:49:44 2022 +0900
@@ -38,6 +38,8 @@
 また、GearsOSでは後述のContextと呼ばれる環境内に全てのDataGearとCodeGearが保持されている。
 Context内ではInterfaceやImplementで定義されたAPIと変数は構造体として記録され、
 またそれら全ての構造体は共用体(union)のData型に登録されている。
+そのため、InterfaceとImplementはDataGearもしくはCodeGearの一時的な保管場所と見なすこともできる。
+
 
 \section{Implementation}
 GearsOSはInterfaceの実装となるImplementの形定義ファイルが実装されている。
--- a/Paper/chapter/4-Christie.tex	Tue Jan 25 22:27:17 2022 +0900
+++ b/Paper/chapter/4-Christie.tex	Thu Jan 27 22:49:44 2022 +0900
@@ -85,7 +85,7 @@
 
 StartCodeGearを継承したソースコード\ref{src:SHW}、StartHelloWorldはCbCやC言語におけるmain部分に相当する。
 main部分ではCodeGearManagerをポート番号指定することで作成を行う。
-また、CGMに対して処理させたいCodeGearをsetupという処理でCGMが所持するThread Poolに追加、
+また、CGMに対して処理させたいCodeGearをsetupメソッドを用いることで、CGMに対してCGを持たせることができる。
 RemoteDGMの作成などを行う。
 
 CodeGearを継承したソースコード\ref{src:HWCG}、OddCodeGearはCodeGearとなる。
--- a/Paper/chapter/5-Implementation.tex	Tue Jan 25 22:27:17 2022 +0900
+++ b/Paper/chapter/5-Implementation.tex	Thu Jan 27 22:49:44 2022 +0900
@@ -10,60 +10,66 @@
 
 
 \section{GearsFSのファイル構成}
-GearsOSのファイルは単なるDataGearのListQueueとして実装する。
-ファイルのデータはレコードとして特定の型へ断続的に分割されたDataGearとして保存される。
-ファイルの読み込みの際にはQueueに対してレコードが無くなるまでTake処理を繰り返し、レコードを参照してファイルの中身を構築することで実現する。
-
-GearsファイルはDataGearのリストとしてファイルのデータを保持する主要なQueueとは別にinputもしくはoutputStreamとなるQueueを持ち合わせており、
-ファイル読み込みもしくは書き込みの際、それぞれinputもしくはoutputの際にstreamに対してアクセスを行う。
-それぞれのQueueはChristieにおけるkey名を持つDataGearとしてinput/OutputstreamをもつQueueとして呼び出される。
-そのため、GearsFSのファイルはChrsitieにおけるDataGearManagerに相当する。
-GearsOSのファイル構造へのアクセスを図\ref{fig:gearsFile}に示す。
-また、データのリストとなるQueueの構造を図\ref{fig:QueueElement}に示す。
-
-\begin{figure}[h]
-    \begin{center}
-        \includegraphics[width=150mm]{./images/GearsFile.pdf}
-    \end{center}
-    \caption{GearsFSのファイル構造}
-    \label{fig:gearsFile}
-\end{figure}
+GearsOSにおけるファイルのデータは任意の型を持ったレコード(構造体)に断続的に分割されて構成され、
+それを保持するファイルは単なるDataGearのListQueueとして実装される。
+ファイルの読み込みの際はQueueに対して順次データレコードのTake操作を繰り返し、連続したレコードからファイルの中身を構築することで実現する。
+つまり、一見としてChristieのファイルはQueueとその要素(Element)として構成される。
+データのリストとなるQueueの構造を図\ref{fig:QueueElement}に示す。
 
 
 \begin{figure}[h]
     \begin{center}
         \includegraphics[width=150mm]{./images/QueueElement.pdf}
     \end{center}
-    \caption{DataQueueの構造}
+    \caption{FileData Stacking Queue}
     \label{fig:QueueElement}
 \end{figure}
 
 
+しかし、単純に一つのQueueをファイルとして直接読み書きを行うと、複数のノードからのアクセスされた際の整合性や、セキュリティの面で問題が発生する。
+そのため、GearsFSのファイルは主体となるデータを保持する主要なQueueとは別にinputもしくはoutputStreamとなるQueueを持ち合わせている。
+そのためGearsFSファイルは複数の役割を持ったDataGearを持つリストとして実装される。
+GearsOSのファイル構造へのアクセスを図\ref{fig:gearsFile}に示す。
+ファイル読み込みもしくは書き込みの際にはそれぞれinputもしくはoutputの際にstreamに対してアクセスを行う形でファイルに対する読み書きが行われ、
+それぞれのQueueはリスト内で固有のkeynameを保持している。
+つまり、ファイルに対する読み書きを行う際は、Queueリストに対してinputもしくはoutputのstreamQueueのkeyに対してput操作、もしくはtake操作を行えば良い。
+これは、ChrsitieにおけるDataGearのkeyとその要素に相当し、それらをリストとして持ち合わせているファイルはDataGearManagerに相当する。
+
+\begin{figure}[h]
+    \begin{center}
+        \includegraphics[width=150mm]{./images/GearsFile.pdf}
+    \end{center}
+    \caption{GearsFSのread/writeAPI}
+    \label{fig:gearsFile}
+\end{figure}
+
+
 ファイルに対して書き込み、つまり従来のwriteにあたる処理を行う場合はInputQueueのkeyを指定してput操作を行う。
 最終的にInputQueueに格納されたデータはInputQueueから取り出され、mainQueueに対して格納される。
 
 ファイルの読み込み(read)を行う際はOutputQueueに対してTake操作を行えば良い。
-OutputQueueにはmainQueueの要素が複製されており、OutputQueue内の要素を全てTakeで呼び出す。
-ファイルを呼び出す側は取り出したElementのログを順番に読むことでファイルを構築する。
+OutputQueueにはmainQueueの要素が複製されており、OutputQueue内の要素を全てTakeのループにより呼び出す。
+ファイルを呼び出す側は取り出したレコードを順番に読むことでファイルを構築する。
 
 GearsOSのファイルは大域的な資源として同時に複数のプロセスから参照が可能になる作りにしたい。
-そのため、OutputQueueは複数のプロセスから参照が行われた際に、データの整合性が失われてはならない。
+OutputQueueは複数のプロセスからファイルreadが行われた際に、データの整合性が失われてしまう危険性がある。
 そのため、OutputQueueはCAS(Compare And Swap)を実装したSynchronizedQueueを用いる。
-データアクセスが単一のプロセスからしか許さないもしくは想定されていない環境では容量の軽量化のため、
+しかしファイルのアクセス権限の設定などにより、データアクセスが単一のプロセスからしか許さないもしくは想定されない環境では読み込みの高速化とメモリの軽量化のため、
 SingleLinkedな(単純な)Queueを用いることも考えられる。
 ファイルに対する書き込みやMainQueueは単一プロセスのみからのアクセスとなるためSingleLickedなキューで実装する。
 
 ファイルのレコードは例題中では単純にファイル内文字列を行ごとに区切り、FileString構造体に書き込んだものとなる。
 \ref{src:FS}にFileString構造体を示す。
 str部分にファイル内文字列を格納し、レコードが全て送信したことを示すEoFフラグが付属している。
-ファイルレコードはGears側のDataGearとして利用も行えるように、ContextにDataGearとして登録された構造体となる。
+ファイルレコードはGears側のDataGearとして利用も行えるように、ContextにDataGearとして登録された構造体である。
 
 FileStringはテストに用いられる単純なレコードである。
 実用性のあるレコードを考察した場合、ファイルに変更が加えられた場合Queueに格納するレコードを行順に構成し直す必要性が生じるなど多くの問題が存在する。
 また、GearsFSではファイルの型をOSが区別できることを目指したい。
 レコードの型を最適な形に変更することによって複数のファイルの型に対応したい。
 例として、テキストデータの場合、変更差分をレコードとしてQueueに格納し、QueueのレコードをTopから参照していくことで構築を行う。
-また、画像ファイルなどファイルの中身の変更が行われない形式は、ファイル内のデータをブロック長に区切り扱うといった手段が考えられる。
+また、画像ファイルなどファイルの中身の変更が行われない形式は、ファイル内のデータをブロック長に区切り扱うといった手段が考えられるなど、
+ファイルの型に応じてレコードの構造体を任意に構成することができる。
 
 \lstinputlisting[label=src:FS, caption=例題のレコードとして使われるFileString構造体]{src/FileString.h}
 
@@ -72,11 +78,11 @@
 \section{WordCount例題}
 GearsFSのAPIの構成をWordCount例題を通して行う。
 WordCount例題とは、指定したファイルの中身を読み取り、文字数と行数列、加えて文字列を出力するという例題である。
-この例題を通すことでファイルに対するAPIを構築する。
+この例題により連続したレコードをQueueから順次読みだすreadAPIを構築した。
 コード\ref{src:WcImpl}にCbCで記述した、Unixファイルに対してWordCountを行うプログラムの一部を示す。
 
-ファイルとWordCountはUNIXのシェルのようにプログラムの外で行われる。
-ファイルは事前にC言語のFILE型構造体を用いて開かれ、行列であるwc->strTableへ内部文字列を行区切りで保存されている。
+ファイルとWordCountの接続はUNIXのシェルのようにプログラムの外で行われる。
+ファイルは事前にC言語のFILE型構造体を用いて開かれ、行列であるwc\texttt{->}strTableへ内部文字列を行区切りで保存されている。
 MainからファイルのOpenが完了した後、CodeGear:putStrinに遷移し、strTableから文字列を行ごと呼び出しCountUpへ入力し遷移する。
 CodeGear:CountUpにて文字列の出力と文字数を読み取り記録、そしてputStringへ遷移する。
 ファイルの文字列がある間はputStringとCountUpをループし続け、
@@ -84,11 +90,9 @@
 図\ref{fig:WordCount}にCGの遷移図を示す。
 このように特定の条件を満たすまであるCodeGear間をループ遷移する構成をGearBoxと名付けている。
 
-
-
 \lstinputlisting[label=src:WcImpl, caption=Unixファイルに対するWordCount.cbcの一部]{src/WcImpl.cbc}
 
-\begin{figure}[tb]
+\begin{figure}[h]
     \begin{center}
         \includegraphics[width=150mm]{./images/UnixWC.pdf}
     \end{center}
@@ -96,15 +100,18 @@
     \label{fig:WordCount}
 \end{figure}
 
-
+\section{ChristieAPIによるWordCount}
+GearsFSはChristieのLocalDataGearManagerとRemoteDataGearManagerによる通信の仕組みを用いてファイルデータの送受信を構成する。これをChristieAPIと呼ぶ。
+ChrstieAPIではファイルをDataGearManagerと見なすことができ、
+Local上にRemote先のファイルのploxyとなるRemoteDGMを作成し、
+これに対しLocalのファイルへの書き込みと同様に操作を行うことで自動的に通信を行ってくれる。
 
-\section{ChristieAPによるWordCount}
 ChiristieのDataGearManagerの仕組みを基準としたChristieAPIによるWordCountの設計を行った。
 図\ref{fig:ChristieAPI}にChristieAPIによるWordCountを示す。
 ChristieAPIによるファイルデータ通信は2ペアのLocal/RemoteDGMを通して行われる。
 RemoteDGMは接続先のノードが持つLocalDGMのプロキシであり、RemoteDGMに対してput操作を行うことで、相手の持つLocalDGMへのデータの送信が行える。
 NodeA側が任意のファイルを開き、ファイル内の行ごとの文字列をデータとしてNodeB側に対応するRemoteDGMにputする。
-NodeB側は自身のLocalなDGMからデータを得て、WordCountの処理を行ったのちに
+NodeB側は自身のLocalDGMからデータを得て、WordCountの処理を行ったのちに
 NodeAに対応するRemoteDGMに対してそのデータに対する処理が完了したことを通知するAck(acknowledgement)をputする。
 Ackを受け取ったOpen側のノードBは再び続きのファイル内文字列をデータとして送信する。
 ここまでの処理が繰り返され、ファイル内の文字列が全て処理されたら、Open側はEoF(End of File)をCount側に対して通知、
@@ -127,23 +134,22 @@
 
 
 \section{Socket付きQueue}
-ChristieにおけるLocalDataGearManagerはプログラム内で使われるDataGearのkeyとデータを全て所持したコレクションにあたる。
-keyとデータの組み合わせは、keyの名前がつけられたQueueに対して保存される、
-TakeコマンドではそのkeyのQueueからデータを取り出し、Peekの場合は先頭のデータを取り出さず参照のみを行っている。
-つまりChristieのDGMは詳細には単純なQueueの集合であると言える。
-RemoteDGMとLocalDGMの通信の際にはLocalDGMが持つsocketに対してRemoteDGMが接続を行い、putされたkeyとDataをsocket経由でコマンドとして送信する。
+RemoteDGMとLocalDGMの接続の際にはLocalDGMが持つsocketに対してRemoteDGMが接続を行い、Dataの書き込み先のkeyを指定してsocket経由でコマンドとして送信する。
 
-
-GearsOSのChristieAPIの定義のためにsocketに接続されたQueueによるWordCount例題を作成した。
+socketを所有したQueueによるWordCount例題の記述を行うことでGearsOSにおけるsocketの取り扱いと実用性を検証した。
+接続元と接続先のsocketは、Queueの作成時に行われ、
+socketへのアクセスはQueueにCodeGearとして実装を行った。
 ソースコード\ref{src:LDGMQueue}にLocalDGM側にあたる、Socket付きのQueueのCodeGear:getData部分を示す。
 加えてソースコード\ref{src:RDGMQueue}にRemoteDGM側にあたるSocket付きのQueueのCodeGear:sendData部分を示す。
-二つのQueueはmainプログラムによりsocketの接続が行われ、一方が文字列の送信を行い、もう一方がCount処理を行うことによってWordCountが行われる。
+CodeGear:getDataではsocketなどによるError発生時やEoFフラグがあるデータを受信した場合の遷移先を指定する必要ある。
 
+二つのQueueはmainプログラムによりsocketの接続が行われ、一方が文字列の送信を行い、もう一方がCount処理を行うことによってWordCountが行われる。
 socketはC言語のSocketインターフェースを用いており、
-ImplementのコンストラクタにあたるcreateLocalDGMQueueにて呼び出され、
+socketのImplementのコンストラクタにあたるcreateLocalDGMQueueにて呼び出され、
 Implのメンバ変数であるsocketに置かれている。
 ソースコード\ref{src:LDGQh}に受信側となるLocalなQueueのImplementを示す。
-socketはint型での取り扱いが行われる。Impl部分へ保存をすることで、Implを実装したプログラム内ならどのCodeGearからでもsocketの参照が行える。
+socketはint型で宣言されている。Implで宣言したsocket変数へsocketを保存をすることで、
+Implの実装となるプログラム内ならどのCodeGearからでもsocketの参照が行える。
 
 また、既存のQueueから新たなAPIを追加するためにQueueInterfaceを新しく書き換えたcQueue(Communicate Queue)Interfaceを継承している。
 Local側のgetDataはAPIとしての呼び出しが可能となっている。socketが受け取ったデータを最終的にdataとしてQueueに対してputを行う。
@@ -159,8 +165,6 @@
 将来的にはmessagePackなどによるシリアライズしたデータを送信する形にする。
 Socketの処理中に問題が発生した場合はinputDataGearとして指定した\texttt{\_\_}code whenError()として入力されたCodeGearに対して遷移する。
 
-GearsOSにおけるファイルはChristieのDGMとして見なすことができ、今回作成したQueueはそれぞれInput/OutputStreamに相当する。
-
 
 \lstinputlisting[label=src:LDGMQueue, caption=LocaDGMQueueのgetData]{src/LocalDGMQueue.cbc}
 \lstinputlisting[label=src:RDGMQueue, caption=RemoteDGMQueueのsendData]{src/RemoteDGMQueue.cbc}
@@ -177,12 +181,12 @@
 赤黒木は平衡二分木であり、木に対する操作時に行われる操作によりノードの階層が平衡化される
 そのため各操作の最悪時間計算量O(logN)となり、二分木の中でも実用性を備えている。
 
-DataGearはkeyごとに作られたQueueに保存される、従ってQueueのstoreとなる赤黒木にはkeyごとのQueueがノードとして保持される。
+DataGearはkeyごとに作られたQueueに保存される、従ってQueueのリストとなる赤黒木にはkeyごとのQueueがノードとして保持される。
 図\ref{fig:GearsDGM}にファイルとなるDataGearManagerの任意のkeyに対してput/take操作を行う際の処理を示す。
-いずれの場合もStoreとなる赤黒木に対して任意のkeyのQueueのget操作を行い、そのQueueに対してputもしくはtake操作を行う。
+いずれの場合もリストとなる赤黒木に対して任意のkeyのQueueのget操作を行い、そのQueueに対してputもしくはtake操作を行う。
 あくまでこのDGMはファイルに相当するものなので、
 赤黒木に含まれているQueueはInput/OutputStreamと実際にファイルデータを保持しておくmainDataQueueの三つとなる。
-しかしWordCount例題のackや結果出力の通信など用途を持つ、Streamとなるkey以外を用いるために、
+しかしWordCount例題のackや結果出力の通信など用途に用いるDataGearが必要な場合、Streamとなるkey以外を用いるために、
 ファイルに関連するkey以外にも任意にQueueを追加することもできる。
 任意のQueueを追加したい場合はstoreとなるTreeに対して、
 Treeが保持していないkeyへputが行われた場合は新しくそのkeyを持つQueueを生成しTreeに持たせる処理を追加すれば良い。
@@ -190,9 +194,7 @@
 図に示した手順のDataアクセスではファイルの呼び出しなどDataGearの断続的な参照が行われる場合、
 Treeへの探索処理がボトルネックになってしまう可能性が考えられる。
 これは特定のkeyのQueueをmain部分で直接参照できるように、
-TreeにQueue自体のポインタをOutputさせるAPIを記述することで解決が行える。
-
-
+TreeにQueue自体のポインタをOutputさせるAPIを実装することで解決が行える。
 
 \begin{figure}[h]
     \begin{center}
@@ -208,7 +210,7 @@
 
 \section{ディレクトリシステム}
 本研究と並行する形で又吉雄斗によるGearsFileSystemのディレクトリ構造の構築が行われている。[論文No.]
-GearsFSのディレクトリシステムはUnixOSのディレクトリシステムと同じ仕組みを用いて再現することを試みている。
+GearsFSのディレクトリシステムはUnixOSのディレクトリシステムのinodeの仕組みを用いて再現することを試みている。
 通常のUnixのディレクトリシステムと異なる点として、ディレクトリを赤黒木(RedBlackTree)を用いて構成する。
 
 図\ref{fig:GearsDirectory}にGearsFSの構成図を示す。
@@ -253,11 +255,11 @@
 変更日時を保持させることで可能となると考えられる。
 特定の時点のファイルとDirectoryの状態を呼び出す際は、レコードの変更日時を確認し、参照するべきTree構造とレコードを呼び出す形となる。
 
-非破壊的木構造の編集と変更履歴式のデータレコードはディレクトリやファイルの容量が変更が行われるたびに増加していくという問題が存在する。
+変更ログデータを定期的に任意または一定期間ごとに別のストレージに保存することでバックアップを実現する。
+また、非破壊的木構造の編集と変更履歴式のデータレコードは変更が行われるたびに、ディレクトリTreeやファイルの容量増加していくという問題が存在する。
 この点については任意の期間経過、もしくはユーザの操作により定期的に過去のデータを自動削除もしくは整形することで容量がある程度の削減が望める。
 また、近年の電子記録媒体の容量増加に伴い問題の重要性が低下していくことが期待できる。
 
-
 \begin{figure}[h]
     \begin{center}
         \includegraphics[width=150mm]{./images/nonDestroyTreeEdit.pdf}
@@ -266,6 +268,7 @@
     \label{fig:TreeEdit}
 \end{figure}
 
+
 \section{GearsFSの分散処理}
 分散フレームワークChristieとGearsOSFileSystemにおける分散処理について考察する。
 GearsFSではファイルはDataGearのリストとして実装される。
@@ -278,3 +281,24 @@
 そのため、ChristieDGMのように一つのスレッド(CGM)により管理されるものではなく、複数のスレッドから競合的にアクセスが行われるDGMである。
 よってDataGearを保持するQueueは純粋なQueueでなく複数のアクセスが行われても、
 データの整合性が保たれるSynchronizedなQueueを用いる必要が生じる場面がある。
+
+Christieのでは分散されたTask(CodeGear)はCodeGearManagerにより実行が行われる。
+GearsFSでは分散処理をCodeGearManagerを用いた実装に代わり、GearsOSに搭載されたpar gotoを利用するという手段が考えられる。
+par gotoとはGearsOSにおける並列処理構文である。
+par gotoによる並列処理ではTaskをContextで表現し、TaskのInputDataGearが揃ったTaskをWorkerで処理を行う。
+図\ref{fig:WorkerRun}にpar goto構文による並列処理を示す。
+GearsFSではファイル送受信自体をTaskの一つとして実装する他に、
+socketに対してファイルデータの確認と取り出しを行う待ち合わせの処理を一つのTaskとする必要がある。
+
+
+
+\begin{figure}[h]
+    \begin{center}
+        \includegraphics[width=170mm]{./images/WorkerRun.pdf}
+    \end{center}
+    \caption{par gotoによる並列処理}
+    \label{fig:WorkerRun}
+\end{figure}
+
+
+\section{GearsOSの持続性}
--- a/Paper/chapter/6-Evaluation.tex	Tue Jan 25 22:27:17 2022 +0900
+++ b/Paper/chapter/6-Evaluation.tex	Thu Jan 27 22:49:44 2022 +0900
@@ -0,0 +1,5 @@
+\chapter{GearsOSとそのファイルシステムの評価}
+\section{GearsFileSystemのAPI}
+GearsOSに導入する分散ファイルシステムのAPIの設計を行った。
+GearsOSのファイルシステムは大域的な資源として同時に複数のプロセスからの参照が可能である。
+GearsFSはデータをレコードとして扱うことができ、
Binary file Paper/images/GearsFile.graffle.graffle has changed
Binary file Paper/images/GearsFile.pdf has changed
Binary file Paper/images/QueueElement.graffle.graffle has changed
Binary file Paper/images/QueueElement.pdf has changed
Binary file Paper/images/gearsChrsitieCGM.graffle has changed
Binary file Paper/images/gearsChrsitieCGM.pdf has changed
Binary file Paper/images/newGearsReletion.graffle.graffle has changed
Binary file Paper/images/newGearsReletion.pdf has changed
Binary file Paper/images/workerRun.pdf has changed
Binary file Paper/master_paper.pdf has changed
--- a/Paper/src/LocalDGMQueue.cbc	Tue Jan 25 22:27:17 2022 +0900
+++ b/Paper/src/LocalDGMQueue.cbc	Thu Jan 27 22:49:44 2022 +0900
@@ -6,11 +6,11 @@
     recv_size = recv(cQueue->socket, recv_data, sizeof(union Data), 0);
     if (recv_size == -1) {
         printf("recv error\n");
-        goto whenEOF(...);
+        goto whenError(...);
     }
     if (recv_size == 0) {
         printf("connection ended\n");
-        goto next(...);
+        goto whenError(...);
     }