問題タブ [begininvoke]

スレッドセーフであるはずのこの小さなメソッドがあります。void ではなく戻り値が必要になるまで、すべてが機能します。BeginInvoke が呼び出されたときに戻り値を取得するにはどうすればよいですか?

編集:スレッドを続行する前に GUI からの値が必要なため、この場合、BeginInvoke は必要ではないと思います。そのため、Invoke を使用することも有効です。次の例でそれを使用して値を返す方法の手がかりはありません。

しかし、そのコードを使用して値を取得する方法もわかりません;)

Async と呼ぶ予定のデリゲートを作成しました。

モジュールレベル

メソッドで使用する次のコード

メソッドが実行され、必要なことを行います

Asyn コールバックは、EndInvoke を実行する完了時に発生します

これは、デリゲートで BeginInvoke を開始するメソッドが、BeginInvoke/Thread 操作がまだ実行されていないときにのみ実行される限り機能します。問題は、デリゲートの別のスレッドがまだ実行中で、まだ EndInvoke されていないときに、新しいスレッドが呼び出される可能性があることです。

プログラムは、必要に応じて一度に複数のインスタンスでデリゲートを実行できる必要があり、それらすべてが完了して EndInvoke が呼び出される必要があります。別の BeginInvoke を開始すると、最初の BeginInvoke への参照が失われるため、EndInvoke で新しいスレッドをクリーンアップできません。

この問題を解決するためのクリーンなソリューションとベスト プラクティスは何ですか?

私は他の人のコードを調べていますが、マルチスレッドに関係する経験はあまりありません。このコード行に出くわしました：

BeginInvoke((MethodInvoker)delegate() { btnCalibrate.PerformClick(); });

これだけでうまくいくのに、なぜこれを行うのだろうと思っていました：btnCalibrate.PerformClick();

回答ありがとうございます。

以下のこのコードの何が問題になっていますか? conn_PageDeleted はバックグラウンド スレッドから来ており、コールバックを受けるたびにラベルを更新しようとしています。エラーが表示されます

パラメータ数が一致しません。

コードは次のとおりです。

同じデリゲートインスタンスで複数回呼び出すBeginInvokeと問題が発生すると思いましたが、試してみましたが、うまくいきました。何故ですか？

IAsyncResultオブジェクトは、デリゲートの各インスタンスではなく、一意と呼ばれるそれぞれで返されますBeginInvokeか？

つまり、デリゲートの1つのインスタンスだけで、その関数への複数の呼び出しを生成できますか？

BeginInvoke がメイン スレッドから呼び出されるコードを継承しました (通常はパターンであるバックグラウンド スレッドではありません)。このシナリオで実際に何をするのかを理解しようとしています。

BeginInvoke で呼び出されているメソッドは、ウィンドウに表示されるメッセージの行に入りますか? ドキュメントによるとasynchronously、それが私の仮定です。

フレームワークは、BeginInvoke によって呼び出されたメソッドを開始するタイミングをどのように優先しますか?

編集: コードは次のようになります。

これは Form_Load イベントで発生しています。

Silverlight 4 ベータ版を使用して WCF データ サービス クエリを実行するためのパターンに従おうとしています。以下は私のコードです：

これは、Silverlight を使用した WCF データ サービスについて私が遭遇した多くの例から導き出されたものです。残念ながら、コードをどのように実装しようとしても、「Dispatcher.BeginInvoke」で次のエラーが発生します。

「非静的フィールド、メソッド、またはプロパティにはオブジェクト参照が必要です (System.Windows.Threading.Dispatcher.BeginInvoke(System.Action)」

先週デリゲートとの作業を開始し、バックグラウンドでグリッドビューの非同期を更新しようとしています。すべてがうまくいき、エラーなどはありませんが、EndInvoke の後に結果が得られません。誰かが私が間違っていることを知っていますか?

コード スニペットを次に示します。

私は数日間マルチスレッドと戦ってきました。

のさまざまな方法がわかりませんmultithreading。backgroundWorkerスレッドのオブジェクトの作成について少し読みました。昨日delegate、 を呼び出してマルチスレッドを実装する例を見ましたBeginInvoke。

multithreadingこれらの異なる方法または同じバックグラウンド クラスで同じ作業を行っていることを理解していません。私にそれを明確にするのを手伝ってください。

I'm working on a heavily data-bound Win.Forms application where I've found some strange behavior. The app has separate I/O threads receiving updates through asynchronous web-requests which it then sends to the main/GUI thread for processing and updating of application-wide data-stores (which in turn may be data-bound to various GUI-elements, etc.). The server at the other end of the web-requests requires periodic requests or the session times out.

I've gone through several attempted solutions of dealing with thread-issues etc. and I've observed the following behavior:

1. If I use Control.Invoke for sending updates from I/O-thread(s) to main-thread and this update causes a MessageBox to be shown the main form's message pump stops until the user clicks the ok-button. This also blocks the I/O-thread from continuing eventually leading to timeouts on the server.

2. If I use Control.BeginInvoke for sending updates from I/O-thread(s) to main-thread the main form's message pump does not stop, but if the processing of an update leads to a messagebox being shown, the processing of the rest of that update is halted until the user clicks ok. Since the I/O-threads keep running and the message pump keeps processing messages several BeginInvoke's for updates may be called before the one with the message box is finished. This leads to out-of-sequence updates which is unacceptable.

3. I/O-threads add updates to a blocking queue (very similar to Creating a blocking Queue<T> in .NET?). GUI-thread uses a Forms.Timer that periodically applies all updates in the blocking queue. This solution solves both the problem of blocking I/O threads and sequentiality of updates i.e. next update will be never be started until previous is finished. However, there is a small performance cost as well as introducing a latency in showing updates that is unacceptable in the long run. I would like update-processing in the main-thread to be event-driven rather than polling.

So to my question. How should I do this to:

1. avoid blocking the I/O-threads
2. guarantee that updates are finished in-sequence
3. keep the main message pump running while showing a message box as a result of an update.

Update: See solution below