問題タブ [cancellationtokensource]

このコードを実行しています。

そして、私はこの出力を得ています

での問題を解決するにはCount value 8?

Succeed と表示され、そこで停止します。

cancellationTokenSource.Cancelキャンセル トークンに関連付けられたタスク内で呼び出すと、OperationCancelledExceptionが正しくスローされますが、予期されるように、task.IsCanceled常に更新されて に設定されるとは限りませんtrue。

この問題は、次の nUnit テストですぐに実証できます。

このテストを実行すると、テストは成功しますが、(Resharper テスト ランナーを使用して) このテストを DEBUG すると、テストは失敗します。

これは Resharper とは何の関係もないと思います。Resharper は、おそらく .Net の問題を明らかにするいくつかの条件を作成している可能性があると思います。または、私は完全に間違ったことをしているだけかもしれません...何か洞察はありますか?

次の方法で、AsParallel を WithDegreeOfParallelism および WithCancellation と組み合わせて使用​​しています

これが私の理解です。一度に処理されるのは、着信シーケンスのうち 2 つだけです。リクエストの 1 つが完了すると、さらに多くのアイテムが処理されます。ただし、キャンセル要求が開始された場合、まだピックアップされていない着信キューのアイテムはまったく処理されません。この理解に基づいて、次のコードを作成しました。

実行したときの出力は次のとおりです。

ThreadID = 3 -> 従業員 1 -> 1058 の
スリープ ThreadID = 1 -> 従業員 7 -> 1187 の
スリープ ThreadID = 1 -> 従業員 8 -> 1296 の
スリープ ThreadID = 1 -> 従業員 9 -> 1614 の
スリープ ThreadID = 1 -> 従業員 10 -> 1607
ThreadID = 1 の間スリープ中 -> 従業員 5 -> 1928
ThreadID = 3 の間スリープ中 -> 従業員 2 -> 1487
ThreadID = 3 の間スリープ中 -> 従業員 3 -> 1535 の
間スリープ中 ThreadID = 3 - > 従業員 4 -> 1265
ThreadID = 3 の間スリープ中 -> 従業員 5 -> 1248
ThreadID = 3 の間スリープ中 -> 従業員 6 -> 807 の間スリープ中 ThreadID = 3
を待機中
-> 従業員 6 終了
ThreadID = 4 ->従業員 1 終了
ThreadID = 5 -> 従業員 7 終了
ThreadID = 6 -> 従業員 8 終了
ThreadID = 3 -> 従業員 5 終了
ThreadID = 4 -> 従業員 9 終了
ThreadID = 5 -> 従業員 10 終了
ThreadID = 6 -> 従業員 5 終了
ThreadID = 3 -> 従業員 4 終了
ThreadID = 7 -> 従業員 2 終了
ThreadID = 8 -> 従業員 3 終了
すべて完了

これが私の問題です（私の理解によると）。

1. 一部の従業員の ProcessThisEmployee はキャンセルされるためまったく呼び出されないことを期待していましたが、すべての従業員に対して呼び出されます

2. ProcessThisEmployee メソッドが呼び出されても、次のコード パスを通過しますが、これも発生していません。

   /li>

それで、ProcessThisEmployee を変更し、基本的に次のように Sleep の後に token.IsCancellationRequested メッセージを移動しました。

これで、次の出力が得られます。

私の質問は、このワークフローについて何を誤解しているのかということです。私は基本的に、長時間実行される操作を行わずに、できるだけ早く操作をキャンセルしたいと考えています (この場合のスリープは単なる例ですが、非常に高価なものになる可能性があります)。

CancellationTokenSource と exit フラグを使用してループ タスクを終了することに違いがあるかどうか疑問に思っていました

CancellationTokenSource:

終了フラグ:

私には、CancellationTokenSource を使用することは何の意味もありませんが、キャンセル トークンをパラメータとしてタスク ファクトリに追加できる理由はありますか?

何から何まで回答ありがとうございます。

最高のラガードチーム

デフォルトを作成すると、プライベートフィールドに保存されている が関連付けられていることCancellationTokenがデバッガで確認できます。CancellationTokenCancellationTokenSourcem_source

構造体に関しては、defaultキーワードが「値型か参照型かに応じて、構造体の各メンバーをゼロまたはヌルに初期化して返す」ことがどのようになるのか疑問に思っていますCancellationTokenSource。

CancellationTokenこのフィールドを設定する 2 つのコンストラクターがありますが、コンストラクターを呼び出さず、 (まったく同じ動作をする) 構造体がパラメーターなしのコンストラクターを持つことができないため (まだdefault(CancellationToken)) コンストラクターを呼び出さないため、これらは無関係です。new CancellationToken()

サービスを正常にシャットダウンできるように、渡されるキャンセル トークンを使用します。サービスには、他のサービスへの接続を試行し続けるロジックがあるため、トークンは、個別のスレッドで実行されているこれらの再試行ループから抜け出すための優れた方法です。私の問題は、内部再試行ロジックを持つサービスを呼び出す必要があるが、再試行が失敗した場合は一定期間後に戻る必要があることです。これを行うタイムアウト付きの新しいキャンセルトークンを作成したいと思います。これに関する問題は、新しいトークンが「マスター」トークンにリンクされていないため、マスター トークンがキャンセルされた場合、新しいトークンはタイムアウトするか、接続が確立されて戻るまで有効です。私がやりたいのは、2 つのトークンをリンクして、マスター トークンがキャンセルされると新しいトークンもキャンセルされるようにすることです。使ってみたCancellationTokenSource.CreateLinkedTokenSourceメソッドですが、新しいトークンがタイムアウトすると、マスター トークンもキャンセルされます。トークンを使用して必要なことを行う方法はありますか、または再試行ロジックを変更する必要がありますか (おそらくこれを簡単に行うことはできません)

これが私がやりたいことです：

マスター トークン – サービスが正常にシャットダウンできるように、さまざまな関数を渡します。一時トークン – 単一の関数に渡され、1 分後にタイムアウトに設定されます

マスタートークンがキャンセルされた場合、一時トークンもキャンセルする必要があります。

一時トークンの有効期限が切れた場合、マスター トークンをキャンセルしてはなりません。

したがって、この投稿への回答によると：

2) タスクの本体もキャンセル トークンを監視しており、そのトークンを含む OperationCanceledException をスローする場合 (これは ThrowIfCancellationRequested が行うことです)、タスクがその OCE を確認すると、OCE のトークンがタスクのトークンと一致するかどうかを確認します。一致する場合、その例外は協調キャンセルの確認と見なされ、タスクは (Faulted 状態ではなく) Canceled 状態に遷移します。

このことから、トークンをタスクのコンストラクターに渡してから、同じトークンの ThrowIfCancellationRequested() メソッドを呼び出すことで、OperationCanceledException を明示的にキャッチしなくても、タスクは実際には平和的に終了することがわかりました。

ただし、例外がスローされることが判明したため、メカニズムを誤解した可能性があると思います。

私のコード:

これを達成する方法について、MSDN にもここにも具体的な言及はありません。ユースケースはややあいまいですが、それでも有効だと思います。

上記のコードは、切り離された子遅延タスクtaskを含むを 100 ミリ秒後にキャンセルしようとし、 (キャンセルにより)が生成されるのを待ちます。これに関する問題は、キャンセルではなくフォルトになることです。両方が同じキャンセル トークンを共有しているにもかかわらず、遅延タスクが親にアタッチされていないため、これは予想される動作です。taskAggregateExceptiontasktask

私の質問は、特に、Task.Delay既に実行されているタスクに a をアタッチする方法に関連しています。親タスクにアクセスできる場合でも、これを行うことは可能ですか? それが不可能な場合、または親タスク インスタンスにアクセスできない場合、このシナリオを処理する適切な方法は何ですか?

私が思いついた最善の回避策は、遅延タスクWaitを try/finally ブロックでラップし、タスクのキャンセルを明示的にバブルアップしようとすることでした。

効果的ではありますが、あまり正しくはありませんが、これを達成するためのより良い方法があるかどうかはわかりません. 望ましい結果は、キャンセルが発生した場合Canceledではなく、親タスクが移動することです。Faultedそのため、切り離された子タスクでキャンセルの発生が発生した場合でも、親タスクは に移行する必要がありCanceledます。

注：問題や結果が変わらないように見えるという理由だけで、ここでは意図的に async/await を省略しました。そうでない場合は、例を示してください。