|
8
|
1 \chapter{Christie}
|
|
|
2
|
|
|
3 ChristieとはJavaで記述された並列分散通信フレームワークである。Aliceという前身のプロジェクトが開発されていたが、以下のような問題があった。
|
|
|
4 データを送受信するAPIはインスタンスを生成して関数を呼び出す様に設計されているが、外部Classからも関数が実行できてしまうため、
|
|
|
5 受信する際どのkeyに紐づいたデータを受け取るのか、直感的にわからない。
|
|
|
6 データを管理しているlocalDataSegmentがシングルトンで設計されており、Localで接続を行う際に複数のアプリケーションで立ち上げる必要がある。
|
|
|
7 データを受け取る際にObject型で受け取っているため、送信元を辿らない限り何の型が送信されているか不明瞭である。
|
|
|
8
|
|
|
9
|
|
|
10 それらの問題点を解消するためにAliceを再設計され、作成されたものがChristieである。
|
|
|
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
|
|
|
28 CodeGearはクラスやスレッドに相当する。
|
|
|
29 DataGearは変数データに相当し、CodeGear内でJavaのannotationの機能を用いて変数データを取得できる。
|
|
|
30 CodeGear内に記述した全てのDataGearにデータが格納された際に、初めてそのCodeGearが実行されるという仕組みになっている。
|
|
|
31
|
|
|
32
|
|
|
33 CGMはノードに相当し、CodeGear、DataGear、DGMを管理している。
|
|
|
34 DGMはDataGearを管理しており、putという操作によって変数データ、つまりDataGearをDGMに格納できる。
|
|
|
35 DGMのput操作を行う際にはLocalとRemoteのどちらかを選び、変数のkeyとデータを引数として渡す。
|
|
|
36 LocalであればLocalのCGMが管理しているDGMに対してDataGearを格納していく。
|
|
|
37 Remoteであれば、接続したRemote先のCGMが管理しているDGMにDataGearを格納する。
|
|
|
38
|
|
|
39 %図欲しい DG CG CGM DGMの関係性を説明した図
|
|
|
40
|
|
|
41
|
|
|
42
|
|
|
43 \begin{figure}[htb]
|
|
|
44 \begin{center}
|
|
|
45 \includegraphics[width=150mm]{images/ChristieClass.pdf}
|
|
|
46 \end{center}
|
|
|
47 \caption{同一プロセスでのChristieの複数インスタンス立ち上げ}
|
|
|
48 \label{fig:MultiInstance}
|
|
|
49 \end{figure}
|
|
|
50
|
|
|
51 図\ref{fig:MultiInstance}は、Christieを同一プロセスで複数のインスタンスを生成した際のDGMやCGMの接続構造を示している。
|
|
|
52 全てのCGMはThreadPoolと他のCGMをListとして共有している。
|
|
|
53 ThreadPoolとはCPUに合わせた並列度でqueueに入ったThreadを順次実行していく実行機構である。
|
|
|
54 ThreadPoolが増えると、CPUコア数に合わない量のThreadを管理することになり並列度が下がるため、1つのThreadPoolで全てのCGMを管理している。
|
|
|
55 またCGMのListを共有することでメタレベルで全てのCodeGear/DataGearにアクセス可能となっている。
|
|
9
|
56 CGを記述する際はCodeGear.classを継承する。
|
|
|
57 CodeGearはRunnableインターフェースを持っており、runメソッド内に処理を記述することでマルチスレッドで処理が行われる。
|
|
|
58 CGに記述したkeyと一致するDGが全て揃った時、runに記述された処理が実行される。
|
|
|
59 runメソッドの引数にCGMを指定しており、そのCGMを経由してChristieのAPIにアクセスする。
|
|
|
60 GearsOSではCG間でContextを受け渡すことによってCGはDGにアクセスを行なっているため、Christieでもそのアクセス方法が採用されている。
|
|
|
61
|
|
|
62 通常のRunnableクラスでは引数を受け取ることができないが、
|
|
|
63 CodeGearExecutorというRunnableのMeta Computationを挟んだことでCGMを受け渡しながらの記述を可能にしている。
|
|
|
64
|
|
|
65
|
|
|
66 DGMに対してput操作を行うことでDGM内のqueueにDGを保管できる。
|
|
|
67 DGを取り出す際には、CG内で宣言した変数データにannotationを付ける。
|
|
|
68 DGのannotationには以下の4種類がある。
|
|
|
69
|
|
|
70 \begin{flushleft}
|
|
|
71 \begin{itemize}
|
|
|
72 \setlength{\leftmargin}{0pt}
|
|
|
73 \item[Take] 先頭のDGを読み込み、そのDGを削除する。
|
|
|
74 \item[Peek] 先頭のDGを読み込むが、DGは削除されない。そのため、特に操作をしない場合には同じDGを参照し続ける。
|
|
|
75 \item[TakeFrom]\mbox{}\\
|
|
|
76 Takeと処理動作は同じであるが、Remote DGM nameを指定することで、その接続先(Remote)のDGMからTake操作を行うことができる。
|
|
|
77 \item[PeekFrom]\mbox{}\\
|
|
|
78 Peekと処理動作は同じであるが、 Remote DGM nameを指定することで、その接続先(Remote)のDGMからPeek操作を行うことができる。
|
|
|
79 \end{itemize}
|
|
|
80 \end{flushleft}
|
|
|
81
|
|
|
82 \section{}
|
|
8
|
83
|
|
|
84
|
|
|
85
|
|
|
86
|
|
|
87
|
|
|
88
|
|
|
89
|
|
|
90
|
|
|
91
|
