Mercurial > hg > Papers > 2018 > nozomi-master
changeset 184:62595752c948
honban
author | Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp> |
---|---|
date | Wed, 07 Feb 2018 11:58:26 +0900 |
parents | b62fc3a499f9 |
children | 8ba51e2a1ea5 |
files | presen/sample.html presen/sample.markdown |
diffstat | 2 files changed, 96 insertions(+), 73 deletions(-) [+] |
line wrap: on
line diff
--- a/presen/sample.html Wed Feb 07 10:07:30 2018 +0900 +++ b/presen/sample.html Wed Feb 07 11:58:26 2018 +0900 @@ -87,7 +87,7 @@ <!-- === begin markdown block === generated by markdown/1.2.0 on Ruby 2.1.0 (2013-12-25) [x86_64-darwin13.0] - on 2018-02-07 10:05:26 +0900 with Markdown engine kramdown (1.5.0) + on 2018-02-07 11:58:16 +0900 with Markdown engine kramdown (1.5.0) using options {} --> @@ -313,25 +313,15 @@ </div> <div class='slide '> <!-- _S9SLIDE_ --> -<h1 id="topology-manager">複数のTopology Managerへの対応</h1> -<ul> - <li>この機能を実現するにはノードに割り当てられたnodeNameの衝突を避けなければならない</li> - <li>通常のLocal DSMとは別にTopology ManagerごとのLocal DSMを作成しnodeNameを管理</li> - <li>Tpology Manager/Nodeの働きはそのままに、指定するLocal DSMを変えるだけでTopology Managerの複数対応が可能<br /> -<img src="./pictures/somehostname2.svg" alt="opt" width="50%" /></li> -</ul> - - -</div> -<div class='slide '> -<!-- _S9SLIDE_ --> <h1 id="alice---localdsm">Aliceの問題点 - LocalDSMを複数立ち上げられない</h1> <ul> + <li>TopologyManagerはLocalDSMに対応して接続される</li> + <li>TopologyManagerに複数接続するには複数のLocalDSMを立ち上げる必要がある</li> <li>AliceではDSMを管理するクラスがstaticで書かれていたためLocal DSMを複数立ち上げることができない</li> <li>このstaticを抜くにはAliceのコード全体を大きく変更しなければならない</li> - <li>現状ではNAT越えのMeta Computationの追加が困難</li> - <li>複数インスタンスを立ち上げての分散プログラムのテストが書けない</li> - <li>再設計の必要がある</li> + <li>よって現状ではNAT越えのMeta Computationの追加が困難</li> + <li>また、複数インスタンスを立ち上げての分散プログラムのテストが書けない</li> + <li>Singltonやstaticをなくした再設計の必要がある</li> </ul> @@ -339,19 +329,23 @@ <div class='slide '> <!-- _S9SLIDE_ --> <h1 id="alice---api">Aliceの問題点 - APIシンタックスの分離</h1> -<ul> +<ul lang="java"> <li>setKeyは記述場所が決まっておらず、待ち合わせを行っているCSの外からも呼べる <ul> - <li>どのkeyを待っているのか不明なCSが生まれてしまう</li> - </ul> - </li> - <li>setKeyではkeyを動的に指定することができる - <ul> - <li>どんな処理を行っているかわかりづらい</li> - <li>対応するput箇所も修正しなければならない</li> + <li>createしたときにどのkeyを待つのかが不明</li> + <li>setKeyしたときにtakeかpeekかがわからない</li> </ul> </li> </ul> +<pre><code>class TestCG extends CodeSegment{ + private Receiver input1 = ids.create(CommandType.TAKE); + + void run() { + CodeSegment cg = new TestCG(); + cg.input1.setKey("hoge"); + } +} +</code></pre> </div> @@ -360,7 +354,8 @@ <h1 id="alice---api-1">Aliceの問題点 - APIシンタックスの分離</h1> <ul lang="java"> <li>setKeyは全てのcreateが終わった最後に呼ばなければならない</li> - <li>このように交互に書くと実行時データを取り出すときにNullPointerExeptionになる</li> + <li>このように交互に書くと実行時データを取り出すときにinput2が指定される前にinput1だけで入力が揃ったと判定され、実行されてしまうことがある</li> + <li>この状態でinput2にアクセスするとエラーとなる</li> </ul> <pre><code>class TestCG extends CodeSegment{ private Receiver input1; @@ -379,18 +374,11 @@ </div> <div class='slide '> <!-- _S9SLIDE_ --> -<h1 id="alice---api-2">Aliceの問題点 - APIシンタックスの分離</h1> -<p><img src="./pictures/nullpo.svg" alt="opt" width="60%" /></p> - - -</div> -<div class='slide '> -<!-- _S9SLIDE_ --> <h1 id="alice---">Aliceの問題点 - 型が推測できない</h1> <ul> - <li>Input DSをReceiver型でcreateするため、どの型のデータを待っているのかわからない</li> - <li>しかしReceiverからデータを取り出すにはasClass()で型を指定する必要がある</li> - <li>型をDSをputした箇所までコードをたどる必要がある</li> + <li>Input DSをReceiver型でcreateするため、任意の型を格納できる</li> + <li>Receiverからデータを取り出すにはasClass()で型を指定する必要がある</li> + <li>格納した型と取り出した型の不一致は実行時に検出される</li> </ul> @@ -403,7 +391,8 @@ <ul> <li>Local DSMを複数立ち上げられないため、Topology Managerの拡張やテストが困難</li> <li>インプットAPIが分離しているためCSでどんな処理が行われているかわかりづらい</li> - <li>setKeyの記述順序や型を気にしてプログラミングをしなくてはならない</li> + <li>setKeyの記述順序によって挙動が変わる</li> + <li>型を気にしてプログラミングをしなくてはならない</li> </ul> </li> <li>これらを踏まえフレームワークChristieを設計する</li> @@ -549,14 +538,7 @@ </div> <div class='slide '> <!-- _S9SLIDE_ --> -<h1 id="christie----4">Christie - アノテーションを用いたインプット記述</h1> -<p><img src="./pictures/setup.svg" alt="opt" width="70%" /></p> - - -</div> -<div class='slide '> -<!-- _S9SLIDE_ --> -<h1 id="christie----5">Christie - アノテーションによるシンタックスの分離阻止</h1> +<h1 id="christie----4">Christie - アノテーションによるシンタックスの分離阻止</h1> <ul> <li>アノテーションは必ずフィールドに付けなければならない <ul> @@ -574,7 +556,7 @@ </div> <div class='slide '> <!-- _S9SLIDE_ --> -<h1 id="christie----6">Christie - 型を指定しないデータ取り出し</h1> +<h1 id="christie----5">Christie - 型を指定しないデータ取り出し</h1> <ul lang="java"> <li>InputDGを宣言する際には必ず型の指定が必要となるため、CG内で型を把握できる</li> <li>DataGearはJavaの総称型を用いて<>内に指定した型を受け取る</li> @@ -587,7 +569,7 @@ </div> <div class='slide '> <!-- _S9SLIDE_ --> -<h1 id="christie----7">Christie - 型を指定しないデータ取り出し</h1> +<h1 id="christie----6">Christie - 型を指定しないデータ取り出し</h1> <ul lang="java"> <li>reflectionAPIを使えばアノテーションのついているフィールドの情報もとれる</li> <li>型を判断できる</li> @@ -609,7 +591,7 @@ </div> <div class='slide '> <!-- _S9SLIDE_ --> -<h1 id="christie----8">Christie - まとめ</h1> +<h1 id="christie----7">Christie - まとめ</h1> <ul> <li>CodeGearManagerというDGMの管理機構を作ったことでLocalDGM複数立ち上げが可能になり、NAT越えなどの機能拡張やテストをしやすくなった</li> <li>アノテーションを用いたことでDG生成とkey指定の分離問題を解決し、処理の見通しを良くした</li> @@ -676,7 +658,7 @@ </div> <div class='slide '> <!-- _S9SLIDE_ --> -<h1 id="christie----9">Christieと他フレームワークの比較 - 設計思想</h1> +<h1 id="christie----8">Christieと他フレームワークの比較 - 設計思想</h1> <ul> <li>AkkaやHazelcastはロケーション透過性が高く、分散プログラムの煩雑な処理を抽象度を高めることで隠している</li> <li>Christieでは分散性を明示的に意識しながら記述できるためチューニングしやすい</li> @@ -687,7 +669,7 @@ </div> <div class='slide '> <!-- _S9SLIDE_ --> -<h1 id="christie----10">Christieと他フレームワークの比較 - 記述性</h1> +<h1 id="christie----9">Christieと他フレームワークの比較 - 記述性</h1> <ul> <li>アノテーションを使ったインプットの指定はAkkaやHazelcastにはない</li> <li>複数のインプットを待ち合わせして処理を行いたい場合 @@ -764,6 +746,32 @@ </li> </ul> + +</div> +<div class='slide '> +<!-- _S9SLIDE_ --> +<h1 id="topology-manager">複数のTopology Managerへの対応</h1> +<ul> + <li>この機能を実現するにはノードに割り当てられたnodeNameの衝突を避けなければならない</li> + <li>通常のLocal DSMとは別にTopology ManagerごとのLocal DSMを作成しnodeNameを管理</li> + <li>Tpology Manager/Nodeの働きはそのままに、指定するLocal DSMを変えるだけでTopology Managerの複数対応が可能<br /> +<img src="./pictures/somehostname2.svg" alt="opt" width="50%" /></li> +</ul> + + +</div> +<div class='slide '> +<!-- _S9SLIDE_ --> +<h1 id="alice---api-2">Aliceの問題点 - APIシンタックスの分離</h1> +<p><img src="./pictures/nullpo.svg" alt="opt" width="60%" /></p> + + +</div> +<div class='slide '> +<!-- _S9SLIDE_ --> +<h1 id="christie----10">Christie - アノテーションを用いたインプット記述</h1> +<p><img src="./pictures/setup.svg" alt="opt" width="70%" /></p> + <style type="text/css"> <!-- *{
--- a/presen/sample.markdown Wed Feb 07 10:07:30 2018 +0900 +++ b/presen/sample.markdown Wed Feb 07 11:58:26 2018 +0900 @@ -120,30 +120,36 @@ * Aliceではトポロジー管理がアプリケーションから分離しているため、コードを大きく変更しなくとも複数のTopology Managerを立ち上げることでNAT越えが可能 ![opt](./pictures/overNAT.svg){:width="70%"} -# 複数のTopology Managerへの対応 -* この機能を実現するにはノードに割り当てられたnodeNameの衝突を避けなければならない -* 通常のLocal DSMとは別にTopology ManagerごとのLocal DSMを作成しnodeNameを管理 -* Tpology Manager/Nodeの働きはそのままに、指定するLocal DSMを変えるだけでTopology Managerの複数対応が可能 -![opt](./pictures/somehostname2.svg){:width="50%"} - # Aliceの問題点 - LocalDSMを複数立ち上げられない +* TopologyManagerはLocalDSMに対応して接続される +* TopologyManagerに複数接続するには複数のLocalDSMを立ち上げる必要がある * AliceではDSMを管理するクラスがstaticで書かれていたためLocal DSMを複数立ち上げることができない * このstaticを抜くにはAliceのコード全体を大きく変更しなければならない -* 現状ではNAT越えのMeta Computationの追加が困難 -* 複数インスタンスを立ち上げての分散プログラムのテストが書けない -* 再設計の必要がある +* よって現状ではNAT越えのMeta Computationの追加が困難 +* また、複数インスタンスを立ち上げての分散プログラムのテストが書けない +* Singltonやstaticをなくした再設計の必要がある # Aliceの問題点 - APIシンタックスの分離 * setKeyは記述場所が決まっておらず、待ち合わせを行っているCSの外からも呼べる - * どのkeyを待っているのか不明なCSが生まれてしまう -* setKeyではkeyを動的に指定することができる - * どんな処理を行っているかわかりづらい - * 対応するput箇所も修正しなければならない + * createしたときにどのkeyを待つのかが不明 + * setKeyしたときにtakeかpeekかがわからない +```java +class TestCG extends CodeSegment{ + private Receiver input1 = ids.create(CommandType.TAKE); + + void run() { + CodeSegment cg = new TestCG(); + cg.input1.setKey("hoge"); + } +} +``` + # Aliceの問題点 - APIシンタックスの分離 * setKeyは全てのcreateが終わった最後に呼ばなければならない -* このように交互に書くと実行時データを取り出すときにNullPointerExeptionになる +* このように交互に書くと実行時データを取り出すときにinput2が指定される前にinput1だけで入力が揃ったと判定され、実行されてしまうことがある +* この状態でinput2にアクセスするとエラーとなる ```java class TestCG extends CodeSegment{ private Receiver input1; @@ -158,20 +164,18 @@ } ``` -# Aliceの問題点 - APIシンタックスの分離 -![opt](./pictures/nullpo.svg){:width="60%"} - # Aliceの問題点 - 型が推測できない -* Input DSをReceiver型でcreateするため、どの型のデータを待っているのかわからない -* しかしReceiverからデータを取り出すにはasClass()で型を指定する必要がある -* 型をDSをputした箇所までコードをたどる必要がある +* Input DSをReceiver型でcreateするため、任意の型を格納できる +* Receiverからデータを取り出すにはasClass()で型を指定する必要がある +* 格納した型と取り出した型の不一致は実行時に検出される # Aliceの問題点 - まとめ * 以下の問題がAliceの信頼性・拡張性を下げている * Local DSMを複数立ち上げられないため、Topology Managerの拡張やテストが困難 * インプットAPIが分離しているためCSでどんな処理が行われているかわかりづらい - * setKeyの記述順序や型を気にしてプログラミングをしなくてはならない + * setKeyの記述順序によって挙動が変わる + * 型を気にしてプログラミングをしなくてはならない * これらを踏まえフレームワークChristieを設計する # Christie - 基本設計(1) @@ -243,9 +247,6 @@ `cgm.setup(new TestCodeGear());` * フィールドがnewされたあとでないとrefrectionAPIで取れない -# Christie - アノテーションを用いたインプット記述 -![opt](./pictures/setup.svg){:width="70%"} - # Christie - アノテーションによるシンタックスの分離阻止 * アノテーションは必ずフィールドに付けなければならない * InputDGの生成とkeyの指定を一箇所に書ける @@ -346,6 +347,20 @@ * モデル検査機構akasyaの搭載など、より信頼性の高い記述環境 * 将来GearsOSの分散部分にChristieを移植できると良い +# 複数のTopology Managerへの対応 +* この機能を実現するにはノードに割り当てられたnodeNameの衝突を避けなければならない +* 通常のLocal DSMとは別にTopology ManagerごとのLocal DSMを作成しnodeNameを管理 +* Tpology Manager/Nodeの働きはそのままに、指定するLocal DSMを変えるだけでTopology Managerの複数対応が可能 +![opt](./pictures/somehostname2.svg){:width="50%"} + +# Aliceの問題点 - APIシンタックスの分離 +![opt](./pictures/nullpo.svg){:width="60%"} + +# Christie - アノテーションを用いたインプット記述 +![opt](./pictures/setup.svg){:width="70%"} + + + <style type="text/css"> <!-- *{