問題タブ [cancellationtokensource]

私はこのコードでスレッドを持っています:

returnの代わりにを使用していることに注意してください。breakスレッドを停止すると、 をsome operation 2実行してはならないからです。

また、このように .ContinueWith が実行されていないことにも気付きました。

まあ、それは単なる「リターン」機能です。tokenSource.Cancel()C#は、通常の戻りではなく、戻りが原因で戻っていることをどのように知ることができますか?

特定の条件が成立している間 (定期的に検証する必要があります) 実行することになっている任意のキャンセル可能なコードのラッパーを作成する過程でCancellationTokenSource、 、Threading.Timer、およびasync/await生成コード間の相互作用で興味深い動作に遭遇しました。

簡単に言うと、待機中のキャンセル可能Taskオブジェクトがあり、それをコールバックTaskからキャンセルするとTimer、キャンセルされたタスクに続くコードがキャンセル要求自体の一部として実行されます。

Timer以下のプログラムでは、トレースを追加すると、コールバックの実行が呼び出しでブロックcts.Cancel()され、その呼び出しによってキャンセルされる待機中のタスクの後のコードが、cts.Cancel()呼び出し自体と同じスレッドで実行されることがわかります。

以下のプログラムは、次のことを行っています。

1. シミュレートする作業をキャンセルするためのキャンセル トークン ソースを作成します。
2. 開始後に作業をキャンセルするために使用されるタイマーを作成します。
3. タイマーをプログラムして、今から 100 ミリ秒後にオフにします。
4. 上記の作業を開始し、200ms 間アイドリングします。
   • タイマー コールバックが開始され、「作業」がキャンセルされ、Task.Delay500 ミリ秒スリープして、タイマーの破棄がこれを待機していることを示します。
5. 期待どおりに作業がキャンセルされることを確認します。
6. タイマーをクリーンアップし、この時点以降にタイマーが呼び出されないようにし、タイマーが既に実行されている場合は、完了するまでここでブロックします (タイマー コールバックが実行されている場合に適切に動作しない作業が後であったと仮定します)同時に）。

最初に書いたときに期待していたように、これを機能させる最も簡単な方法は、cts.CancelAfter(0)代わりに を使用することですcts.Cancel()。ドキュメントによると、cts.Cancel()登録されたコールバックを同期的に実行します。この場合、async/await生成されたコードとの相互作用により、キャンセルが発生した時点以降のすべてのコードがその一部として実行されていると思います。cts.CancelAfter(0)これらのコールバックの実行をそれ自体の実行から分離します。

誰もこれに遭遇したことがありますか？このような場合cts.CancelAfter(0)、デッドロックを回避するための最良のオプションはありますか?

キャンセルしたいタスクがあります。

これを行う通常の方法は、 を使用することCancellationTokenです。

しかし、現実の世界では、物事はそれほど単純ではありません。非同期コードはループできず、次のようになります。

オブジェクトとメソッド名に乱数を使用して、ループがまったく作成できないことを示しました。

最も厄介なのは、同じことを何度も書き続けなければならないことCancelToken.ThrowIfCancellationRequested()です。

そして、それだけでは不十分であるかのCancellationTokenように、Microsoft によると、適切なタイミングで実行時間の長い操作を停止できるようにするためだけに、コード全体をドラッグする必要があります。

そうは言っても、コードを汚染するこれらの繰り返しの呼び出しをなくす方法はありますか?

また、

メソッドに対してanOperationCancelledExceptionがスローされ、キャッチされWaitます。CancelToken.ThrowIfCancellationRequested()ただし、タスクによって実行される長い操作は、時々チェックがなければ停止しません。

待機のために例外がキャッチされたときに内部操作を停止させる方法はありますか?

の使用に関連していると思われる、再現が難しい問題に直面していますCancellationToken。次の図に示すように、ASP.NET Web API を介して通信する 3 つの非同期アプリ (それぞれが異なるサーバー上) があります。

appは、 Aapp への多数の同時要求を起動するルーチンを時々実行します。Bこれにより、 app への別の多数の同時要求が起動されますC。これらの呼び出しはすべて を使用して行われ、次のようHttpClient.SendAsyncに を使用して 10 秒のタイムアウトに制限されますCancellationToken。

サーバーCの負荷が高いと、応答に時間がかかり始めB、タイムアウトが構成されているため、サーバーは要求のキャンセルを開始します。これが発生すると、リクエストが「スタック」することがあります（下の画像を参照）。

私は C# 非同期のベスト プラクティスに精通しており、そのようなことはしていませ.Resultん.Wait()。これらがハングを引き起こす可能性があることを認識しています。

代わりにパスCancellationToken.Noneすると問題は解決するので、ヒントは、並行性の高いシナリオでのキャンセルに関係しているということです。

時間が経つにつれて、ますます多くの要求がハングし始め、最終的には IIS をリセットしてそれらをなくすしかありません。

何が起こっているのかの手がかりはありますか？

一定の時間スリープするのに最適な方法は何IsCancellationRequestedですかCancellationToken?

.NET 4.0 で動作するソリューションを探しています。

書きたい

タスクをキャンセルすると、IsCanceled プロパティに対して await の結果が true を返します。何かがうまくいかないようです。

お知らせ下さい。これはコードです：

CancelButton を押して CancelButton_Click メソッドをトリガーすると、CallBack メソッドがトリガーされます。しかし... myTaskToWaitFor.IsCanceled を確認すると、常に false が返され、次の情報が表示されます: Id = 1、Status = RanToCompletion、Method = "{null}"。ステータスがキャンセルされていないのはなぜですか？

http://msdn.microsoft.com/en-us/library/system.threading.cancellationtoken.throwifcancellationrequested.aspxを使用する場合

このような：

デバッグモードでエラーが発生するだけで、myTaskToWaitFor が実際にキャンセルされたように見えますが、コードは続行されません (続行すると、例外のためにプログラムがシャットダウンされます)。何かご意見は？敬具、

マティス

編集：

TrowIfCancellationRequested を使用したテストは、「キャンセルされた CancellationToken で ThrowIfCancellationRequested を呼び出すと、OperationCanceledException がスローされます。タスク並列ライブラリは、このタイプの例外が失敗ではなくキャンセルを表すことを認識しており、異なる方法で処理します。たとえば、 Task には、非同期メソッドの実行中に OperationCanceledException がスローされると自動的に true になる IsCanceled というプロパティがあります。

これが、myTaskToWaitFor.IsCancelled が true を返し、コードが続行されることを期待できると考えた理由です。