CancellationToken, CancellationTokenSource'tan neden ayrı?

Sınıfa CancellationTokenek olarak .NET struct'ın neden tanıtıldığına dair bir mantık arıyorum CancellationTokenSource. Anlıyorum nasıl API kullanılacaksa, aynı zamanda anlamak istiyorum neden o şekilde olduğunu tasarlanmıştır.

Yani, neden elimizde:

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

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

doğrudan CancellationTokenSourceetrafta dolaşmak yerine :

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

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

Bu, iptal durumu kontrollerinin jetonun etrafından dolaşmaktan daha sık gerçekleştiği gerçeğine dayanan bir performans optimizasyonu mu?

Böylece bu CancellationTokenSourcetakip ve güncelleme yapabilir CancellationTokensve her belirteç için iptal kontrolü yerel bir alan erişimidir?

Her iki durumda da kilitlemesiz geçici bir bool'un yeterli olduğu göz önüne alındığında, bunun neden daha hızlı olacağını hala anlayamıyorum.

Teşekkürler!

Bu sınıfların tasarımında ve uygulanmasında görev aldım.

Kısa cevap, " endişelerin ayrılması " dır . Çeşitli uygulama stratejilerinin olduğu ve bazılarının en azından tip sistemi ve ilk öğrenmeye göre daha basit olduğu oldukça doğrudur. Bununla birlikte, CTS ve CT birçok senaryoda (derin kitaplık yığınları, paralel hesaplama, zaman uyumsuz vb.) Kullanılmak üzere tasarlanmıştır ve bu nedenle birçok karmaşık kullanım durumu göz önünde bulundurularak tasarlanmıştır. Performanstan ödün vermeden başarılı kalıpları teşvik etmeyi ve anti-kalıpları caydırmayı amaçlayan bir tasarımdır.

Yanlış davranan API'ler için kapı açık bırakılırsa, iptal tasarımının kullanışlılığı hızla aşınabilir.

CancellationTokenSource == "iptal tetikleyicisi", artı bağlantılı dinleyiciler oluşturur

CancellationToken == "iptal dinleyicisi"

Tam sorum vardı ve bu tasarımın arkasındaki mantığı anlamak istedim.

Kabul edilen cevap mantığı tam olarak doğru buldu. İşte bu özelliği tasarlayan ekibin onayı (vurgu benim):

Çerçevenin temelini iki yeni tür oluşturur: A CancellationToken , 'potansiyel iptal talebini' temsil eden bir yapıdır. Bu yapı, bir parametre olarak yöntem çağrılarına aktarılır ve yöntem, bunu yoklayabilir veya iptal istendiğinde çalıştırılacak bir geri aramayı kaydedebilir. A CancellationTokenSource, bir iptal talebini başlatmak için mekanizma sağlayan bir sınıftır ve Token ilişkili bir belirteci elde etmek için bir özelliğe sahiptir . Bu iki sınıfı tek bir sınıfta birleştirmek doğal olurdu, ancak bu tasarım iki temel işlemin (iptal talebini başlatma, iptali gözlemleme ve buna yanıt verme) net bir şekilde ayrılmasına izin verir. Özellikle, yalnızca a alan yöntemler CancellationTokenbir iptal talebini gözlemleyebilir ancak bir iptal talebini başlatamaz.

Bağlantı: .NET 4 İptal Çerçevesi

Bana göre CancellationTokendurumu sadece gözlemleyebilen ve değiştiremeyen gerçeği son derece kritik. Jetonu bir şeker gibi dağıtabilir ve sizden başka birinin onu iptal edeceğinden asla endişelenmeyin. Sizi düşmanca üçüncü taraf kodlarından korur. Evet, şans düşük, ama şahsen bu garantiyi seviyorum.

Ayrıca API'yi daha temiz hale getirdiğini ve yanlışlıkla yapılan hataları önlediğini ve daha iyi bileşen tasarımını teşvik ettiğini düşünüyorum.

Bu sınıfların her ikisi için genel API'ye bakalım.

Bunları birleştirirseniz, LongRunningFunction yazarken, kullanmamam gereken çoklu 'İptal' aşırı yüklemeleri gibi yöntemler göreceğim. Kişisel olarak Dispose yöntemini görmekten de nefret ediyorum.

Mevcut sınıf tasarımının 'başarı çukuru' felsefesini takip ettiğini düşünüyorum, geliştiricilere üstesinden gelebilecek daha iyi bileşenler oluşturmaları için rehberlik ediyor. Task iptal ve ardından bunları karmaşık iş akışları oluşturmak için çeşitli şekillerde bir arada kullanmaları için yönlendiriyor.

Size bir soru sorayım, belirtecin amacının ne olduğunu merak ettiniz mi? Bana mantıklı gelmedi. Ve sonra Yönetilen İş Parçacıklarında İptali okudum ve her şey kristal netliğe kavuştu.

TPL'deki İptal Çerçeve Tasarımının kesinlikle birinci sınıf olduğuna inanıyorum.

Teknik nedenlerle değil, anlamsal nedenlerle ayrıdırlar. CancellationTokenILSpy altında uygulamasına bakarsanız, bunun yalnızca bir sarmalayıcı olduğunu göreceksiniz CancellationTokenSource(ve dolayısıyla performans açısından bir referansın etrafından dolaşmaktan farklı olmadığını).

İşleri daha öngörülebilir hale getirmek için bu işlevsellik ayrımını sağlarlar: a yöntemini geçtiğinizde CancellationToken, onu iptal edebilecek tek kişinin siz olduğunuzu bilirsiniz. Elbette, yöntem hala a atabilir TaskCancelledException, ancak CancellationTokenkendisi - ve aynı belirteci referans alan diğer yöntemler - güvenli kalacaktır.

CancellationToken yapı, yöntemlere aktarılması nedeniyle çok sayıda kopya bulunabilecek bir yapıdır.

Kaynak CancellationTokenSourceçağrılırken bir belirtecin TÜM kopyalarının durumunu ayarlar Cancel. Bu MSDN sayfasına bakın

Tasarımın nedeni sadece endişelerin ayrılması ve bir yapının hızı olabilir.

Her CancellationTokenSourcene sebeple olursa olsun, iptali düzenleyen 'şey'. Bu iptali verdiği tüm 'lere' göndermenin 'bir yoluna ihtiyacı CancellationTokenvar. Örneğin ASP.NET, bir istek iptal edildiğinde işlemleri iptal edebilir. Her talep, CancellationTokenSourceiptali düzenlediği tüm belirteçlere ileten bir özelliğe sahiptir.

BTW birim testi için bu harika - kendi iptal jetonu kaynağınızı oluşturun, bir jeton Cancelalın, kaynağı arayın ve jetonu iptali işlemesi gereken kodunuza iletin.