☰

CancellationToken が CancellationTokenSource と異なるのはなぜですか? 質問する

tag-icon • tag-icon c# multithreading task-parallel-library cancellationtokensource cancellation-token
CancellationToken が CancellationTokenSource と異なるのはなぜですか? 質問する

私は、クラスCancellationTokenに加えて.NET構造体が導入された理由を知りたいです。CancellationTokenSourceどうやってAPIを使用するだけでなく、理解したいなぜそれはそのように設計されています。

つまり、なぜ次のようなことが起こるのでしょうか。

var cts = new CancellationTokenSource();
SomeCancellableOperation(cts.Token);

...
public void SomeCancellableOperation(CancellationToken token) {
    ...
    token.ThrowIfCancellationRequested();
    ...
}

次のように直接渡すのではなくCancellationTokenSource、

var cts = new CancellationTokenSource();
SomeCancellableOperation(cts);

...
public void SomeCancellableOperation(CancellationTokenSource cts) {
    ...
    cts.ThrowIfCancellationRequested();
    ...
}

これは、トークンを渡すよりもキャンセル状態のチェックの方が頻繁に行われるという事実に基づいたパフォーマンスの最適化ですか?

つまり、CancellationTokenSourceを追跡して更新することができCancellationTokens、各トークンのキャンセル チェックはローカル フィールド アクセスになりますか?

どちらの場合も、ロックなしの volatile bool で十分であるにもかかわらず、なぜそれがより高速になるのかがまだわかりません。

ありがとう！

ベストアンサー1

私はこれらのクラスの設計と実装に携わりました。

簡単に答えると、「関心事の分離「さまざまな実装戦略があり、少なくとも型システムと初期学習に関しては、いくつかはより単純であることは事実です。ただし、CTS と CT は、非常に多くのシナリオ (深いライブラリ スタック、並列計算、非同期など) で使用することを目的としており、多くの複雑な使用ケースを念頭に置いて設計されています。これは、パフォーマンスを犠牲にすることなく、成功するパターンを奨励し、アンチパターンを阻止することを目的とした設計です。

不正な動作をする API に対して門戸が開かれたままになっていると、キャンセル設計の有用性がすぐに損なわれる可能性があります。

CancellationTokenSource==「キャンセルトリガー」、さらにリンクされたリスナーを生成する

CancellationToken== "キャンセルリスナー"

おすすめ記事