|
8
|
1 \chapter{Christie}
|
|
|
2
|
|
|
3 ChristieとはJavaで記述された並列分散通信フレームワークである。Aliceという前身のプロジェクトが開発されていたが、以下のような問題があった。
|
|
|
4 データを送受信するAPIはインスタンスを生成して関数を呼び出す様に設計されているが、外部Classからも関数が実行できてしまうため、
|
|
|
5 受信する際どのkeyに紐づいたデータを受け取るのか、直感的にわからない。
|
|
|
6 データを管理しているlocalDataSegmentがシングルトンで設計されており、Localで接続を行う際に複数のアプリケーションで立ち上げる必要がある。
|
|
|
7 データを受け取る際にObject型で受け取っているため、送信元を辿らない限り何の型が送信されているか不明瞭である。
|
|
|
8
|
|
|
9
|
|
13
|
10 それらの問題点を解消するためにAliceを再設計し、作成されたものがChristieである。
|
|
8
|
11 ChristieではAliceの機能や概念を維持しつつ、Aliceで発生していた問題点やプログラムを煩雑さなどを解消している。
|
|
|
12
|
|
|
13
|
|
|
14 \section{Christieの基礎概念}
|
|
|
15 Chrisiteはタスクとデータを細かい単位に分割してそれぞれの依存関係を記述し、
|
|
|
16 タスク実行に必要な入力が揃った順から並列実行するというプログラミング手法を用いている。
|
|
|
17
|
|
|
18 将来的に当研究室で開発しているGearsOSのファイルシステムに組み込まれる予定があるため、GearsOSを構成する言語 Continuation based Cと
|
|
|
19 似た概念を持っている。Christieに存在する概念として以下の様なものがある。
|
|
|
20
|
|
|
21 \begin{itemize}
|
|
|
22 \item CodeGear
|
|
|
23 \item DataGear
|
|
|
24 \item CodeGearManager (以下CGM)
|
|
|
25 \item DataGearManager (以下DGM)
|
|
|
26 \end{itemize}
|
|
|
27
|
|
10
|
28 \begin{figure}[htb]
|
|
|
29 \begin{center}
|
|
|
30 \includegraphics[width=150mm]{images/GearsRelationships.pdf}
|
|
|
31 \end{center}
|
|
|
32 \caption{各Gearの関係性}
|
|
|
33 \label{fig:GearRelationships}
|
|
|
34 \end{figure}
|
|
|
35
|
|
|
36 図\ref{fig:GearRelationships}はそれぞれのGearの関係性を図示したものである。
|
|
8
|
37 CodeGearはクラスやスレッドに相当する。
|
|
10
|
38 DataGearは変数データに相当し、CodeGear内でJavaのannotationの機能を用いてkeyに紐づいた変数データを取得できる。
|
|
8
|
39 CodeGear内に記述した全てのDataGearにデータが格納された際に、初めてそのCodeGearが実行されるという仕組みになっている。
|
|
|
40
|
|
|
41 CGMはノードに相当し、CodeGear、DataGear、DGMを管理している。
|
|
|
42 DGMはDataGearを管理しており、putという操作によって変数データ、つまりDataGearをDGMに格納できる。
|
|
|
43 DGMのput操作を行う際にはLocalとRemoteのどちらかを選び、変数のkeyとデータを引数として渡す。
|
|
|
44 LocalであればLocalのCGMが管理しているDGMに対してDataGearを格納していく。
|
|
|
45 Remoteであれば、接続したRemote先のCGMが管理しているDGMにDataGearを格納する。
|
|
|
46
|
|
|
47 \begin{figure}[htb]
|
|
|
48 \begin{center}
|
|
|
49 \includegraphics[width=150mm]{images/ChristieClass.pdf}
|
|
|
50 \end{center}
|
|
|
51 \caption{同一プロセスでのChristieの複数インスタンス立ち上げ}
|
|
|
52 \label{fig:MultiInstance}
|
|
|
53 \end{figure}
|
|
|
54
|
|
|
55 図\ref{fig:MultiInstance}は、Christieを同一プロセスで複数のインスタンスを生成した際のDGMやCGMの接続構造を示している。
|
|
|
56 全てのCGMはThreadPoolと他のCGMをListとして共有している。
|
|
|
57 ThreadPoolとはCPUに合わせた並列度でqueueに入ったThreadを順次実行していく実行機構である。
|
|
|
58 ThreadPoolが増えると、CPUコア数に合わない量のThreadを管理することになり並列度が下がるため、1つのThreadPoolで全てのCGMを管理している。
|
|
|
59 またCGMのListを共有することでメタレベルで全てのCodeGear/DataGearにアクセス可能となっている。
|
|
9
|
60 CGを記述する際はCodeGear.classを継承する。
|
|
|
61 CodeGearはRunnableインターフェースを持っており、runメソッド内に処理を記述することでマルチスレッドで処理が行われる。
|
|
|
62 CGに記述したkeyと一致するDGが全て揃った時、runに記述された処理が実行される。
|
|
|
63 runメソッドの引数にCGMを指定しており、そのCGMを経由してChristieのAPIにアクセスする。
|
|
|
64 GearsOSではCG間でContextを受け渡すことによってCGはDGにアクセスを行なっているため、Christieでもそのアクセス方法が採用されている。
|
|
|
65
|
|
|
66 通常のRunnableクラスでは引数を受け取ることができないが、
|
|
|
67 CodeGearExecutorというRunnableのMeta Computationを挟んだことでCGMを受け渡しながらの記述を可能にしている。
|
|
|
68
|
|
|
69 DGMに対してput操作を行うことでDGM内のqueueにDGを保管できる。
|
|
|
70 DGを取り出す際には、CG内で宣言した変数データにannotationを付ける。
|
|
13
|
71
|
|
|
72
|
|
|
73 \section{annotationを使用したデータの記述}
|
|
|
74
|
|
|
75 ChristieではDGの指定にannotationを使用する。 annotationとはクラスやメソッド、パッケージに対して付加情報を記述できる
|
|
|
76 Java のMeta Computationである。先頭に@を付けることで記述でき、オリジナルのannotationを定義することもできる。
|
|
|
77 Christieのannotationには以下の4種類がある。
|
|
9
|
78
|
|
10
|
79 \begin{description}
|
|
|
80 \item[Take] 先頭のDGを読み込み、そのDGを削除する。
|
|
|
81 \item[Peek] 先頭のDGを読み込むが、DGは削除されない。そのため、特に操作をしない場合には同じDGを参照し続ける。
|
|
|
82 \item[TakeFrom(Remote DGM name)] Takeと処理動作は同じであるが、Remote DGM nameを指定することで、その接続先(Remote)のDGMからTake操作を行うことができる。
|
|
|
83 \item[PeekFrom(Remote DGM name)] Peekと処理動作は同じであるが、 Remote DGM nameを指定することで、その接続先(Remote)のDGMからPeek操作を行うことができる。
|
|
|
84 \end{description}
|
|
9
|
85
|
|
8
|
86
|
|
11
|
87 DGの宣言には型と変数を直接宣言し、変数名としてkeyを記述する。 そして、その宣言の上にannotationでTakeまたはPeekを指定する(ソースコード\ref{src:TakeExample})。
|
|
8
|
88
|
|
|
89
|
|
11
|
90 \lstinputlisting[label=src:TakeExample, caption=Takeの例]{src/Take.java}
|
|
8
|
91
|
|
11
|
92 annotationで指定したDGはCGを生成した際にCodeGear.class内で待ち合わせの処理が行われる。
|
|
|
93 これにはJavaのreflectionAPIを利用しており、annotationと同時に変数名も取得できるため、面数名によるkeyの指定が可能になっている。
|
|
8
|
94
|
|
11
|
95 Christieのannotationはフィールドに対してのみ記述可能であるため、keyの指定とTake/Peekの指定を必ず一箇所で書くことが明確に決まっている。
|
|
|
96 これより、Aliceの様に外のCGからkeyやデータへの干渉をされることがない。
|
|
|
97 さらにkeyを変数名にしたことで、動的なkeyの指定やkeyと変数名の不一致による可読性の低下を防ぐことが可能となった。
|
|
8
|
98
|
|
11
|
99 リモートノードに対してTake/Peekをする際には、TakeFrom/PeekFrom annotationを用いる(ソースコード\ref{src:TakeFromExample})。
|
|
8
|
100
|
|
11
|
101 \lstinputlisting[label=src:TakeFromExample, caption=TakeFromの例]{src/TakeFrom.java}
|
|
12
|
102
|
|
|
103
|
|
13
|
104 \section{データの型整合性}
|
|
|
105 Aliceでは送受信するデータはReceive型という専用の型を使用していた。
|
|
|
106 内部のデータ自体はobject型だったため、元データの型を知るためには送信元を確認する必要があった。
|
|
|
107 ChristieではannotationでDGの宣言を行っているため、直接変数の型を宣言することが可能となっている。
|
|
|
108 ソースコード\ref{src:InputDGExample}はDGのデータを扱う例である。
|
|
|
109
|
|
|
110 \lstinputlisting[label=src:InputDGExample, caption=DGのデータを扱う例]{src/InputDG.java}
|
|
|
111
|
|
|
112 DGとして宣言した変数の型は、JavaのreflectionAPIを用いてCGMで保存され、LocalやRemoteノードと通信する際に適切な変換が行われれる。
|
|
|
113 この様にプログラマが指定せずとも正しい型でデータを取得できるため、プログラマの負担を減らし信頼性を保証することができる。
|
|
|
114
|
|
|
115 \newpage
|
|
|
116
|
|
|
117 \section{CodeGearの記述方法}
|
|
|
118 以下のソースコード\ref{src:StartCGExample}、\ref{src:CGExample}、\ref{src:CounteObj}はLocalDGMにputしたDGを取り出して表示し、
|
|
|
119 インクリメントして10回繰り返す例題である。
|
|
|
120
|
|
|
121 \lstinputlisting[label=src:StartCGExample, caption=StartCodeGearの記述例]{src/StartCGExample.java}
|
|
|
122 \lstinputlisting[label=src:CGExample, caption=CodeGearの記述例]{src/CodeGearExample.java}
|
|
|
123 \lstinputlisting[label=src:CounteObj, caption=DGとして送信されるオブジェクトのクラス]{src/CountObject.java}
|
|
|
124
|
|
|
125 Chrisiteでは、StartCodeGear(以下StartCG)から処理を開始する。
|
|
|
126 StartCGはStartCodeGear.javaを継承することで記述可能である。
|
|
|
127
|
|
|
128 StartCGを記述する際には、createCGMメソッドによりCGMを生成する必要がある(ソースコード\ref{src:StartCGExample} 5行目)。
|
|
|
129 createCGMの引数にはremoteノードとソケット通信をする際に使用するポート番号を指定する。
|
|
|
130 CGMを生成した際にLocalDGMやremoteと通信を行うためのDaemonも生成される。
|
|
|
131
|
|
|
132
|
|
|
133 CGに対してannotationから待ち合わせを実行する処理はsetupメソッドが行う。
|
|
|
134 そのためソースコード\ref{src:StartCGExample}の6行目、ソースコード\ref{src:CGExample}の10行目のように、
|
|
|
135 CGのインスタンスをCGMのsetupメソッドに渡す必要がある。
|
|
|
136 そのためどこでもCGの待ち合わせを行うことができず、必ずCGMの生成を行う必要がある。
|
|
|
137 その制約により、複雑になりがちな分散プログラミングのコードの可読性を高めている。
|
|
|
138 実行されたCGを再度実行する場合にも、CGのインスタンスを生成してsetupメソッドに渡す。
|
|
|
139
|
|
|
140
|
|
|
141 \section{DataGearManagerの複数立ち上げ}
|
|
|
142 AliceではLocalDGMと同じ機能のLocalDataSegmentManagaer(以下LocalDSM)がstaticで実装されていたため、複数のLocalDSMを立ち上げることができなかった。
|
|
|
143 しかしChristieではCGMの生成に伴いLocalDGMも生成されるため、複数作成が可能である。
|
|
|
144 複数のLocalDGM同士のやり取りも、Remoteへの接続と同じ様に相手をRemoteDGMとしてproxyとして立ち上げることでアクセス可能である(図\ref{fig:LocalRemoteCommunication})。
|
|
|
145
|
|
|
146 \begin{figure}[htb]
|
|
|
147 \begin{center}
|
|
|
148 \includegraphics[width=150mm]{images/LocalRemoteCommunication.pdf}
|
|
|
149 \end{center}
|
|
|
150 \caption{RemoteDGMを介したCGM間の通信}
|
|
|
151 \label{fig:LocalRemoteCommunication}
|
|
|
152 \end{figure}
|
|
|
153
|
|
|
154
|
|
|
155 ソースコード\ref{src:2LocalDGM}はLocalDGMを2つ立ち上げ、お互いをremoteに見立てて通信する例である。
|
|
|
156 6行目にあるように、RemoteDGMを立ち上げるにはCGMが持つcreateRemoteDGMメソッドを用いる。
|
|
|
157 引数にはRemoteDGM名と接続するremoteノードhost名、ポート番号を指定している。
|
|
|
158
|
|
|
159 \lstinputlisting[label=src:2LocalDGM, caption=LocalDGMを2つ作る例]{src/RemoteDGMCommunication.java}
|
|
|
160
|
|
|
161 remoteへの接続と同じ様にアクセスが可能になっており、コードを変更せずに同一マシン上の1つのアプリケーション内で分散アプリケーションのテストが可能となっている。
|
|
|
162
|
|
|
163
|
|
|
164 また、CGMは内部に同一プロセス全てのCGMリストをstaticで持っており、複数生成したCGMを全て管理している。
|
|
|
165 つまり、メタレベルではRemoteDGMを介さずに各LocalDGMに相互アクセス可能である。
|
|
12
|
166
|
|
15
|
167 \newpage
|
|
12
|
168
|
|
13
|
169 \section{通信フロー}
|
|
14
|
170 本章で説明したChristieの設計をいくつか例を挙げてChristieの通信のフローをシーケンス図を用いて解説する。
|
|
|
171 図\ref{fig:LocalTakeSequence}はLocalDGMにTakeを行い、LocalDGM内にDGがあったときの処理の流れである。
|
|
|
172
|
|
|
173
|
|
|
174 \begin{figure}[htb]
|
|
|
175 \begin{center}
|
|
15
|
176 \includegraphics[width=160mm]{images/LocalSequence.pdf}
|
|
14
|
177 \end{center}
|
|
|
178 \caption{LocalDGMにTakeした際のフロー}
|
|
|
179 \label{fig:LocalTakeSequence}
|
|
|
180 \end{figure}
|
|
|
181
|
|
|
182
|
|
|
183 プログラマはmainでCGMを生成する。CGMと同時にLocalDGMが作成される。
|
|
|
184 続いてStartCG内でCGのインスタンスを作成し、setupメソッドが呼ばれると、DGに付与されたannotationからTakeコマンドが作られ実行される。
|
|
|
185 CGは生成したコマンドの総数を初期値としたカウンタを持っており、コマンドが解決される(DGが揃う)度にカウンタは減少する。
|
|
|
186 カウンタが0になると待ち合わせが完了したとなり、run内の処理がThreadPoolへ送られる。
|
|
|
187
|
|
|
188
|
|
|
189 図\ref{fig:RemotePutSequence}は、LocalDGMにTakeを行うが、LocalDGM内にDGがなかったためにPutの待ち合わせを行うときの処理の流れである。
|
|
|
190 mainなどの最初の処理は図\ref{fig:LocalTakeSequence}と同様のため省略する。
|
|
13
|
191
|
|
|
192
|
|
14
|
193 \begin{figure}[htb]
|
|
|
194 \begin{center}
|
|
15
|
195 \includegraphics[width=160mm]{images/RemotePutSequence.pdf}
|
|
14
|
196 \end{center}
|
|
|
197 \caption{RemoteDGMからPutされた際のフロー}
|
|
|
198 \label{fig:RemotePutSequence}
|
|
|
199 \end{figure}
|
|
|
200
|
|
|
201
|
|
|
202 LocalまたはRemoteノードからPutコマンドが実行された際にwaitListを確認し、
|
|
|
203 PutされたDGを待っているコマンドが存在すれば、そのコマンドは実行される。
|
|
|
204
|
|
|
205
|
|
|
206 図\ref{fig:RemoteTakeSequence}はRemoteDGMにTakeを行った際の処理の流れである。
|
|
|
207
|
|
|
208
|
|
|
209 \begin{figure}[htb]
|
|
|
210 \begin{center}
|
|
15
|
211 \includegraphics[width=160mm]{images/RemoteTakeSequence.pdf}
|
|
14
|
212 \end{center}
|
|
|
213 \caption{RemoteDGMにTakeした際のフロー}
|
|
|
214 \label{fig:RemoteTakeSequence}
|
|
|
215 \end{figure}
|
|
|
216
|
|
|
217 プログラマはStartCGで事前にRemoteDGMを生成しておく。
|
|
|
218 続いて、TakeFrom annotationからRemoteDGMに対するTakeコマンドが生成され実行される。
|
|
|
219 TakeFromの様にRemoteからの応答を待つコマンドはLocalDGMではなく、RemoteDGMのwaitListに格納される。
|
|
|
220 RemoteDGMに対するTakeコマンドはMessagePack形式に変換され、RemoteDGMが参照している別ノードのLocalDGMに送信される。
|
|
|
221
|
|
|
222 送信されたTakeコマンドを受け取ったLocalDGMは、要求されたDGがあればReplyコマンドを生成して送り返す。
|
|
|
223 もしDGがなければ、Remoteから来たコマンドもLocalの場合と同様にLocalDGMのwaitListに格納される。
|
|
|
224
|
|
|
225 Replyコマンドを受け取るとRemoteDGMhはwaitListに入っていたコマンドを解決し、待ち合わせが完了する。
|
|
15
|
226
|
|
|
227
|
|
|
228
|
|
|
229
|
