Mercurial > hg > Papers > 2017 > suruga-sigos
comparison paper/sigos.tex @ 23:b81702f6108a
fix
author | Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
---|---|
date | Mon, 23 Apr 2018 21:47:58 +0900 |
parents | f55662d3643f |
children | 64a017ca89a4 |
comparison
equal
deleted
inserted
replaced
22:f55662d3643f | 23:b81702f6108a |
---|---|
313 もしプログラマが適当に命名してしまえば後々混乱を招くため、待ち合わせるkey名とinput DS の変数名一致を強制させたい。 | 313 もしプログラマが適当に命名してしまえば後々混乱を招くため、待ち合わせるkey名とinput DS の変数名一致を強制させたい。 |
314 | 314 |
315 \section{分散フレームワークChristieの設計} | 315 \section{分散フレームワークChristieの設計} |
316 | 316 |
317 以上の問題を踏まえ、新しい分散フレームワークChristieの設計とプロトタイプの実装を行った。 | 317 以上の問題を踏まえ、新しい分散フレームワークChristieの設計とプロトタイプの実装を行った。 |
318 Christieに必要な要件は以下のように考える。 | 318 Christieに必要な要件は以下のように考えた。 |
319 | 319 |
320 \begin{itemize} | 320 \begin{itemize} |
321 \item {\ttfamily create/setKeyのような煩雑なAPIをシンプルにし可読性を向上させる} | 321 \item {\ttfamily create/setKeyのような煩雑なAPIをシンプルにし可読性を向上させる} |
322 \item {\ttfamily 並列分散環境下での型の整合性を保証する構文と仕組みを提供する} | 322 \item {\ttfamily 並列分散環境下での型の整合性を保証する構文と仕組みを提供する} |
323 \item {\ttfamily 一つのプロセス内で複数のインスタンスを同時に立ち上げられる} | 323 \item {\ttfamily 一つのプロセス内で複数のインスタンスを同時に立ち上げられる} |
324 \item {\ttfamily 木構造などのデータ構造をネットワーク上でやりとりできる} | 324 \item {\ttfamily 木構造などのデータ構造をネットワーク上でやりとりできる} |
325 \item {\ttfamily 通信に用いるキーの階層的管理を提供する} | 325 \item {\ttfamily 通信に用いるキーの階層的管理を提供する} |
326 \item {\ttfamily これらの仕組みを実現するメタ計算機構を提供する} | 326 \item {\ttfamily これらの仕組みを実現するメタ計算機構を提供する} |
327 \end{itemize} | 327 \end{itemize} |
328 | 328 |
329 | 329 Chirstie では、CodeSegment/DataSegment と呼ばずに、CodeGear/DataGear と呼ぶ。これは将来的にはGears OSにより実装するためである。 |
330 | 330 |
331 Alice のAPIの問題は、送信するオブジェクトの型を前もって指定できないことと、記述する場所に自由度があることが問題になっている。 | |
332 そこで、DataGear を Java のAnnoationを用いて宣言することにした。これに関しては、実装を行ない、妥当なAPIを決定した。 | |
333 これについは次節で説明する。 | |
334 | |
335 Alice のSingleton は広範囲で使われており、Refactoring では修正できない。そこで、Christie では基本的な部分を再実装することにした。 | |
336 | |
337 Jungle との整合性では、Alice と Jungle の両方にオブジェクトのデータベースが存在することが良くない。Jungle では変更ログを | |
338 Aliceにより送信しているが、これはリスト構造を送信することに相当する。Jungle では木の変更を伝搬させるが、これは木構造そのものを | |
339 通信しているのと同等である。つまり、Alice の通信を木構造を持つオブジェクトにまで拡張することが可能だと考えられる。 | |
340 | |
341 Jungleの木構造と、AliceのTuple空間の違いは、変更時の同期方法にある。Jungle では木はラベルにより指定されて、その変更はトランザクション | |
342 として失敗と成功がある形で直列化される。Alice の同期機構は、Data Segment の待ち合わせによって行われる。単一のData Segment を | |
343 待ち合わせれば、それは単一のトランザクションと同等になる。複数のData Segmentを待ち合わせる形の同期は Jungle では実現できない。 | |
344 Jungle の木をキーに対応する Data Segment とすることよって、Alice により Jungle のトランザクションを実現できる。 | |
345 | |
346 Jungleの木のラベルは大域的なIDである必要があるが、特に構造を持たせていない。Alice のラベルは、接続された2点間でのみ有効になっている。 | |
347 従って、Jungle の木のラベルは分散システムの中で管理する必要がある。通常のURIのように木構造を持った構造として分散管理することが | |
348 望ましい。つまり、Jungle の木のラベルはJungle 自体で管理される木構造であるべきだと思われる。これはファイルシステムのパスに | |
349 相当する。Christie はGears OSでの分散ファイルシステムとして使えるのが望ましい。 | |
350 | |
351 \section{アノテーションの導入} | |
352 | |
353 InputAPIにはAliceと同じくTakeとPeekを用意した。 | |
354 ChristieではInput DG の指定にはアノテーションを使う。 | |
355 アノテーションとは、クラスやメソッド、パッケージに対して付加情報を記述できるJavaのMeta Computationである。 | |
356 先頭に@をつけることで記述でき、オリジナルのアノテーションを定義することもできる。 | |
357 | |
358 AliceではInputの受け皿であるReceiverを作り後からkeyをセットしていたが、 | |
359 ChristieではInputとなる型の変数を直接宣言し、変数名としてkeyを記述する。 | |
360 そして、その宣言の上にアノテーションでTakeまたはPeekを指定する(ソースコード\ref{src:takeex})。 | |
361 | |
362 \lstinputlisting[label=src:takeex, caption=Takeの例]{src/InputDG.java} | |
363 | |
364 | |
365 アノテーションで指定したInputDGは、CGを生成した際にCodeGear.class内で待ち合わせの処理が行われる。 | |
366 これにはJavaのreflectionAPIを利用しており、アノテーションと同時に変数名も取得できるため、変数名によるkey指定が実現した。 | |
367 | |
368 Christieのこのインプットアノテーションはフィールドに対してしか記述できないため、keyの指定とTake/Peekの指定を必ず一箇所で書くことが明確に決まっている。 | |
369 そのためAliceのように外のCSからのkeyへの干渉をされることがない。 | |
370 このように、アノテーションを用いたことで、Aliceの記述の分離問題が解決された。 | |
371 また、keyを変数名にしたことで、動的なkeyの指定や、keyと変数名の不一致による可読性の低下を防ぐことができた。 | |
372 | |
373 リモートノードに対してTake/Peekする際は、TakeFrom/PeekFromのアノテーションを用いる(ソースコード\ref{src:remotetake})。 | |
374 | |
375 \lstinputlisting[label=src:remotetake, caption=TakeFromの例]{src/RemoteInputDG.java} | |
376 | |
377 なお、圧縮のMeta ComputationはAliceと同様で、指定する際にDGM名の前にcompressedをつける(ソースコード\ref{src:compresslocal})。 | |
378 | |
379 \lstinputlisting[label=src:compresslocal, caption=Remoteから圧縮して受け取る例]{src/CompressLocal.java} | |
380 | |
381 | |
382 OutputAPIにはput/flipを用意した。 | |
383 基本的なシンタックスはAliceと同様だが、Christieではput/flipのメソッドはCodeGear.classに用意されている。 | |
384 そのためCodeGear.classを継承するCGで直接putメソッドを呼ぶことができる(ソースコード\ref{src:remoteput})。 | |
385 | |
386 \lstinputlisting[label=src:remoteput, caption=putの例]{src/RemotePut.java} | |
387 | |
388 そのため、ChristieにはAliceのODSにあたる部分がない。 | |
389 ODSを経由するより直接DGMに書き込むような記述のほうが直感的であると考えたためである。 | |
390 圧縮を指定してのputも、Alice同様DGM名の前にcompressedをつける。 | |
391 | |
392 | |
393 \subsection*{型の整合性の向上} | |
394 ChristieではReceiver型ではなく直接変数を宣言する。 | |
395 そのため他の場所を辿らなくともCGを見るだけでインプットされるデータの型が分かるようになった。 | |
396 また、変数を直接宣言するため、そもそもAliceのようにasClassメソッドで型の取り出す必要がない。 | |
397 ソースコード\ref{src:getdata}はInputDGのデータを扱うである。 | |
398 | |
399 \lstinputlisting[label=src:getdata, caption=InputDGを扱う例]{src/GetData.java} | |
400 | |
401 InputDGとして宣言した変数の型は、reflectionAPIにより内部で保存され、リモートノードと通信する際も適切な変換が行われる。 | |
402 このようにプログラマが指定しなくとも正しい型で取得できるため、プログラマの負担を減らし信頼性を保証することができる。 | |
403 | |
404 以下のコードはLocalDSMにputしたDGを取り出して表示するのを10回繰り返す例題である。 | |
405 | |
406 \lstinputlisting[label=src:StartCodeGear, caption=StartCodeGearの例]{src/StartTest.java} | |
407 \lstinputlisting[label=src:TestCodeGear, caption=CodeGearの例]{src/TestCodeGear.java} | |
408 | |
409 Alice同様、ChristieでもInputDGを持たないStartCGから処理を開始する。 | |
410 StartCGはStartCodeGear.classを継承することで記述できる。 | |
411 AliceではStartCSもCodeSegment.classを継承して書かれていたため、どれがStartCSなのか判別しづらかったが、Christieではその心配はない。 | |
412 | |
413 StartCGを記述する際にはcreateCGMメソッドでCGMを生成してコンストラクタに渡す必要がある。 | |
414 ソースコード\ref{src:StartCodeGear}の8行目でそれが行われている。 | |
415 createCGMの引数にはリモートノードとソケット通信する際使うポート番号を指定する。 | |
416 CGMを生成した際にLocalDGMやリモートと通信を行うためのDaemonも作られる。 | |
417 | |
418 CGに対してアノテーションから待ち合わせを実行する処理はsetupメソッドが行う。 | |
419 そのためソースコード\ref{src:StartCodeGear}の13行目、ソースコード\ref{src:TestCodeGear}の10行目のように、newしたCGをCGMのsetupメソッドに渡す必要がある。 | |
420 AliceではnewすればCGが待ちに入ったが、Christieでは一度CGをnewしないとアノテーションから待ち合わせを行う処理ができないため、newの後にsetupを行う。 | |
421 そのため、CGの生成には必ずCGMが必要になる。 | |
422 runでCGMを受け渡すのはこのためである。 | |
423 なお、StartCGはインプットを持たないため、setupを行う必要がなく、newされた時点でrunが実行される。 | |
424 | |
425 \subject{まとめ} | |
426 | |
427 分散木構造データベースJungleと、分散フレームワークAliceについて考察し、両者を統一する形で、分散フレームワークChristieを | |
428 提案した。 | |
429 | |
430 Christie ではアノテーションを用いて、Aliceの欠点であった記述の分離と型の整合性をコンパイル時に解決できない問題を解決した。 | |
431 | |
432 Jungle の構造をChristieに内蔵することにより、ChristieのData Gear は、分散環境で共有、あるいは、持続性を持つことができるようになる。 | |
433 そのData Gear へのアクセスに、大域的な木構造を持つラベルを用意することで、ChristieのData Gearをファイルシステムのように | |
434 使えるようになる。 | |
435 | |
436 将来的には Gears OS でのファイルシステムとしてChristieを使えるように、持続性、DataGearにアクセスするパスとしての木構造、分散環境での | |
437 同期手法を研究していく予定である。 | |
331 | 438 |
332 | 439 |
333 | 440 |
334 %参考文献 | 441 %参考文献 |
335 \nocite{*} | |
336 \bibliographystyle{ipsjunsrt} | 442 \bibliographystyle{ipsjunsrt} |
337 \bibliography{sigos} | 443 \bibliography{sigos} |
338 | 444 |
339 \end{document} | 445 \end{document} |