[Kiev] .Netの非同期プログラミングに関するワークショップ

昨日、私は最初の一般的なセミナー、特に.Netに参加しました。たまたまそのセミナーを実施したのです（そうです、私以外にも、本当にそこに人がいました）。 セミナーは、昨日Luxoftトレーニングセンターで開催された.Netプラットフォームでの非同期プログラミングに専念しました。



約20人が参加しましたが、そのほとんどは私が働いていたチームの親しい人でした。 しかし、8人は他のチームからであり、Luxoftからでもないようです。 彼らは基本的にすべて自分自身であるという事実のために、最初から雰囲気は非公式でした：男は私を順番にいじめました。



実際、このセミナーは、非同期プログラミングに関する2つの記事「非同期プログラミングとAsyncEnumerator」と「C＃5での非同期操作の紹介 」 、およびイテレーターの内部構造に関する記事「C＃のイテレーター」に基づいています。 私も検討しようとしていたリアクティブ拡張は、明らかに適合しませんでした。 検討のために、RX-sだけでは2時間では十分ではないため、スプレーしないことにしました。



その結果、50枚のスライドが提示され、およそ次のような構造になりました。





1.知人とそのすべての何とか何とか何とか。



2.例、その長所と短所を備えた同期操作。



非同期プログラミングに進む前に、同期の何が問題なのかを理解する必要があります。 一般に、ほとんどの人はこれらの問題に精通していますが、CPUバウンドやIOバウンド操作などの概念について話すことは、誰もが話していることを理解できるように役立ちました。



3. .Netの非同期プログラミングのパターン：（1） 古典的な非同期パターンおよび（2） イベントベースの非同期パターン 。



ほとんどすべての.NetプログラマーはBeginXXX / EndXXXメソッドを知っており、それらのほとんどはBackgroundWorkerクラスで動作します。 ただし、BeginXXX / EndXXXメソッドが古典的な非同期プログラミングパターンであり、 BackgroundWorkerがイベントベースの非同期パターンの典型的な代表であることを誰もが知っているわけではありません。



4.既存のパターンの欠点



これは1つのスライドにすぎませんが、別のセクションで強調表示するのに十分重要です。 しかし、Jeff RichterやEric Meijerなどの仲間がAsyncEnumeratorクラスやReactive Extensionsなどのライブラリなど、あらゆる種類のくだらないものを思い付くように促したのは、使用の複雑さや実行フローの倒錯など、既存の非同期プログラミングパターンを使用することの欠点です。 いくつかの非常に人気のあるプログラミング言語（*）に非同期のサポートを追加することを決めた一部の個人については、すでに沈黙しています。



5. PowerThreadingライブラリ、特にAsyncEnumeratorクラス。



リヒターの創造の重要性は、このアイデアがC＃5言語の新しい言語構成要素であるawaitとasyncの根底にあるという事実にあります。 ただし、このクラスは最小限の追加の言語構成に基づいて構築され、他のサードパーティライブラリを使用しないため、待機して非同期に進むよりも実行フローを「まっすぐにする」方法を見つける方がはるかに簡単です。 実際、マスターする必要がある唯一の概念は、イテレータブロックです。



5.1。 トピックからの注意散漫：イテレーターブロック。



イテレータブロックの動作を理解せずにAsyncEnumeratorクラスの動作を説明することは不可能だと思いました。 そして、このセクションをレポートに追加することで、正しいことをしたようです。 多くの人はイテレータブロックが何であるかをよく知っており、多かれ少なかれそれらがどのように配置されているかを表していますが、全員がリターンスーツをもたらす「テンプレートブレーク」の結果を理解しているわけではありません。 レポート全体を通して、イテレーターのトピックに戻り、イテレーターの内部構造を思い出しました。



6. C＃での非同期操作5.キーワードasyncおよびawait。



ここで、私はおそらく最も重大な間違いを犯しました。 タスククラスの考慮にあまり注意を払いませんでした。 実際、非同期プログラミングの新しい機能は、2つの概念に基づいています。（1）実行スレッドの「転位」は、イテレータブロックに非常に似ています。（2）「タスク」のクラス（ タスクおよびタスク<T> ）。 しかし、多かれ少なかれ、私は最初のコンポーネントのみを調べ、2番目のコンポーネントは表面的にのみ調べました。 したがって、すべての継続、同期のコンテキスト、BeginXXX / EndXXXとの相互接続とともに、外出先でのタスクの例を挙げて、指で見せなければなりませんでした。



awaitおよびasync機能の主な考慮事項は、既に学習した資料のコンテキストで実行されました。IEnumerator<int>をasyncに置き換え、returnをawaitに戻し、AsyncEnumeratorからC＃5.0の新しい機能に移行します。



7.結論、質問など



ワークショップ概要



今日、同僚とのフライトの追加分析が行われ、その結果、次の結論が出されました。 取り組む必要があるもの：



1.私は時折スライドで得点し、自分で話しました。時には、スライドの前を走り回りました。



2.私が使用したすべての用語が人々に理解可能であったわけではありません。 たとえば、同期コンテキストについて話し、誰もがこれらの概念に精通していることを意味します。 これは常にそうではなかったので、聴衆の一部は失われました。



3.単純なものから複雑なものへ、そしてその逆ではない。 最初はいくつかのトピックを表面的に処理し、それから詳細に調べただけの場合がありました。 このため、連中はさらに質問をし、いくつかの誤解が現れました。



4.聴衆ともっとコミュニケーションをとる。 私は質問をしようとしましたが、時には冗談を言うのは馬鹿げていますが、観客をもっと関与させる価値はあります。



5.より多くの写真とより少ないコード。 一般的に、スライドには多くのコードがあり、追加資料ではさらに多くのコードがありました。 多くの概念、特にイテレータブロック、したがって、このすべての非同期がらくたをより強く視覚化する必要があります。 コードは、非同期コード実行の複雑なスレッドの最良のデモンストレーションではありません。



6.はい、タスク（タスクのクラス、タスク<T>など）にあまり注意を払いませんでした。 あらゆる種類のContinueWithなどを含むより多くの例が必要であり、より良い描画の形で、実行の流れを明示的に示します。



7.コード例では、行番号が十分ではありませんでしたが、レーザーポインターがありませんでした。 このため、時にはホールを走り回って指で何かを話す必要がありました。



8.次回からこのケースを記録して、自分を横から見てエラーのより詳細な分析を行う必要がある場合。



何が好きでしたか：



取り組むべき多くの問題があるという事実にもかかわらず、セミナー全体は成功しました。 私はこのセミナーを実施するのが好きで、聴衆はそれを聞くのが好きだったという事実が好きでした。 リスナーは反応がよく理解していました。 確かに、「自分の」だけが議論に加わりましたが、私を知らない人は、うなずき、「リヒターが誰なのか知っていますか？」のような質問に手を挙げました。



一般に、このトピックをもう一度繰り返し検討するか、多くの人が興味を持っているジェット拡張機能に触れる準備ができています。



ここからダウンロードできます：（1） プレゼンテーション ; （2） テスト投影 。



-----------------------------



（*）これは、C＃およびVB.NETで非同期プログラミングの機能を追加する会社とのAnders Halesbergの微妙な暗示です。