問題タブ [synchronizationcontext]

ダイアログを表示したい場合、 で例外を取得し、task1そのダイアログから新しい を開始するメソッドを呼び出しますtask2。問題は、実行中にオーナー ウィンドウがフリーズすることtask2です。

簡単なコードを見てください ( Task Parallel Library uses):

私にとっては、最初にbutton1_Clickメソッドでタスクを開始するとUIでは実行されず、次に新しいタスクを開始するとUIスレッドで実行されるため、所有者ウィンドウがフリーズするのは奇妙です。

コードのこの部分が実際にバックグラウンドではなくタスクを開始する理由を誰かが明確にすることができますか?

非同期メソッド M を書きたいとしましょう。それを呼び出すためにどのような種類の同期コンテキスト (UI、ASP.NET、コンソール アプリなど) が使用されるかわかりません。できるだけ使いやすい方法にしたいと思います。つまり、返された Task の Result メンバーにアクセスすることで、誰でも同期的に呼び出すことができるはずです。

問題は、メソッド M の呼び出し元の同期コンテキストが M の呼び出し先にリークすることです。それらのいずれかが、渡された同期コンテキストで続行したい場合、デッドロックする可能性があります (たとえば、UI 同期コンテキストを使用する場合)。

M が呼び出されたときに同期コンテキストを忘れる 1 つの解決策は、M の内容を Task.Run でラップすることです。ただし、M 内のすべてのタスクが完了し、すべてがコンテキスト スイッチなしで同じスレッド上で同期的に実行できる場合を含め、スレッド ジャンプが強制されます。スレッドの同期コンテキストを忘れるためのより良い解決策はありますか? それとも、この質問を無関係にする何かが欠けていますか?

大きな CSV ファイル用のパーサー クラスがあります。大きなファイルを 1 行ずつ読み取る parse メソッドの作業は、backgroundWorker で行われます。完了率の情報は、メソッドを使用して UI スレッドに渡されるbackgroundWorker.ReportProgressため、フォームの進行状況バーがその役割を果たします。それはうまくいっています。

ただし、ドロップダウン リストに配置できるように、CSV ファイルの最初の行から取得したフィールド名のリストを UI (WPF) に送り返すカスタム イベントも発生させたいと思います。また、パーサーが不正な行やその他の障害に遭遇した場合は、イベントを介してユーザーに通知したいと思います。

バックグラウンドで実行されているパーサー プロセスは、単純にイベントを発生させることができますか? または、SynchronizationContext.Current をメイン UI スレッドからパーサー クラスに渡して、Post メソッドを使用する必要がありますか?

私はまだタスクの概念全体と TPL を学んでいます。私の現在の理解では、SynchronizationContext 関数 (存在する場合) はawait、Task を「どこかに」ディスパッチするために使用されます。一方、Taskクラス内の関数はコンテキストを使用しませんよね？

たとえばTask.Run(...)、常にスレッド プールのワーカー スレッドでアクションをディスパッチし、SynchronizationContext.Current完全に無視します。await Foobar()コンテキストを使用して、await?の後に生成されたタスクを実行します。

Taskそれが本当なら、私の質問は次のとおりです。実際にアクションを実行するが、を使用してディスパッチされるを取得するにはどうすればよいSynchronizationContext.Current.Send/Postですか?

SynchronizationContextそして、特にフレームワークの残りの部分でいつ、どのように使用されるかについて、誰でも良い導入を推奨できますか? MSDNはこのクラスについて非常に静かなようです。Google の上位ヒット (こことここ) は、Windows フォームのディスパッチのみに合わせて調整されているようです。Stephen Cleary は、どのコンテキストが既に存在し、どのように機能するかを学ぶのに役立つ記事を書きましたが、実際にいつどこで使用されるかについては理解していません。

私は、VB.Net で記述された Visual Studio 2008 ソリューション内の 2 つのプロジェクトで構成される Windows CE 6 用のプログラムに取り組んでいます。以前、Windows デスクトップ用に同様のプログラムを作成したので、できるだけ多くのコードを再利用したいと考えています。

一般的な構造は次のとおりです。最初のプロジェクトにはフロントエンド GUI が含まれ、2 番目のプロジェクトにはシリアル通信用のライブラリが含まれます。このライブラリは、他の GUI で再利用可能である必要があり、たとえば、グラフィカルなものに依存してはなりませんControl 。

インスタンスを使用している 2 番目のライブラリ プロジェクトではSerialPort、データの受信はSerialPort.DataReceivedイベントを介して処理されます。2 番目のスレッドで発生するようDataReceivedに、私はデスクトップ バリアントで使用SynchronizationContextしていますが、グラフィカルな要素に依存しないと利用できません。以下は簡単な例です。Invoke

このコードを .Net CF に移植する場合、利用できるものはありませSynchronizationContextん。私はネットで検索し、これらを見つけました: http://www.planetgeek.ch/2009/02/03/part-i-mimic-synchronizationcontext-behaviour-on-net-cf/ http://www.planetgeek.ch /2009/02/15/part-ii-mimic-synchronizationcontext-behaviour-on-net-cf/ しかし、作者は私が使いたくない Control.Invoke を使用しています (System.Windows.Forms にあります)。

何日も他のアプローチを見つけられなかったので、私の質問は次のとおりです。これをどのように解決できますか?

ありがとう、

クリストフ

以前のバージョンの MonoTouch では、監視されていない例外を無視するためにこれを行っていました。

それが良い習慣であるかどうかは議論の余地がありますが、 Xamarin.iOS 6.4 で正式にサポートされるasyncようになった/awaitキーワードで同じ効果を達成する方法を知りたいです。

テストに使用するコードは次のとおりです。

実行すると、デバッガーが一時停止しAsyncVoidMethodBuilderます:

.NET 4.5では動作が変更されたため、監視されていない例外によってアプリがクラッシュしないようになっていると読みましたが、例外が処理できない UIKit 同期コンテキストにポストされた場合、これは役に立ちません。

awaitMonoTouch で監視されていない例外を無視する方法はありますか?

SynchronizationContext について読んだ各記事では、フォームのコントロールの処理について説明しています。それが SynchronizationContext の唯一の目的ですか?

また、基本的なことも質問する必要があります。UI スレッドが使用する場合、使用する前に各コントロールをロックできないのはなぜですか? コントロールと通信するために、このすべての「SynchronizationContext」が必要なのはなぜですか? つまり、コントロールを伝達するためのより良い方法ではありませんか? （私はそれがうまくいかないことを知っています）。

記事:

http://blogs.msdn.com/b/csharpfaq/archive/2010/06/18/parallel-programming-task-schedulers-and-synchronization-context.aspx

http://reedcopsey.com/2010/03/18/parallelism-in-net-part-15-making-tasks-run-the-taskscheduler/

..

従業員が残高に応じて顧客からお金を集めるのに役立つアプリを構築しています。アプリはインターネットからオフラインで動作する必要があります。そして、オンラインになると、収集レコードをメイン サーバーのデータベースに送信する必要があります。

メイン DB には 5,000 人の顧客がいて、顧客の残高は常に変化しています。モバイルアプリのデータベースとメインサーバーのデータベースを同期するにはどうすればよいですか? モバイル アプリのデータベースを切り捨てて、メイン サーバーからすべてのレコードを取得し、それらをモバイルに挿入する必要がありますか? または、クライアントごとに更新操作を行う必要がありますか? ところで、新しいクライアントもいつでも作成できますか?

どちらの方法がより効率的ですか?

私はマルチプレイヤー ゲーム サーバーを作成しており、新しい C# の async/await 機能が役立つ方法を検討しています。サーバーのコアは、ゲーム内のすべてのアクターを可能な限り高速に更新するループです。

このループは、何千ものアクターを処理し、ゲームをスムーズに実行し続けるために毎秒複数回更新するために必要です。一部のアクターは、データベースからデータをフェッチするなど、更新機能で低速のタスクを実行することがあります。これは、非同期を使用したい場合です。このデータが取得されると、アクターはゲームの状態を更新しようとしますが、これはメイン スレッドで行う必要があります。

これはコンソール アプリケーションであるため、保留中のデリゲートをメイン ループにディスパッチできる SynchronizationContext を作成する予定です。これにより、これらのタスクが完了するとゲームが更新され、未処理の例外がメイン ループにスローされるようになります。私の質問は、非同期更新関数をどのように書くのですか? これは非常にうまく機能しますが、async void を使用しないという推奨事項を破っています。

Update() を非同期にして、タスクをメイン ループに戻すこともできますが、次のようになります。

• それを決して使用しない何千もの更新にオーバーヘッドを追加したくありません。
• メインループでも、タスクを待機してループをブロックしたくありません。
• タスクを待機すると、待機中のスレッドで完了する必要があるため、とにかくデッドロックが発生します。

待ちきれないこれらすべてのタスクをどうすればよいですか? それらがすべて完了したことを知りたいのは、サーバーをシャットダウンするときだけですが、おそらく数週間分の更新によって生成されたすべてのタスクを収集したくありません.

これによると

BackgroundWorker がその DoWork ハンドラーから別の BackgroundWorker を開始する場合、ネストされた BackgroundWorker は UI SynchronizationContext をキャプチャしません

ただし、.NET 4.0、特に 4.5 以降では、次のようなサンプル コードを多数見てきました。

したがって、タスクを使用して非同期呼び出しをネストできるように見え、SynchronizationContext はネストされた呼び出しをフロートダウンします。これは正しいです？

もしそうなら、誰かがTAPがこれを非常に高いレベルでどのように行うかを説明してもらえますか.

そうでない場合、ネストされた呼び出しが UI スレッドに投稿できるようにするために何をする必要がありますか?

それとも、元の記事に対する私の理解が完全に間違っているのでしょうか? 新しいタスクを作成すると、デフォルトで現在の同期コンテキストが取得されますか? もしそうなら、明示的に新しい同期コンテキストを与えない限り、元の同期コンテキスト以外でどのように実行できますか?

混乱を解消するのを手伝ってください。