Task.Run vs ThreadPool.QueueUserWorkItem

Question

Nie jestem ekspertem tematu Staram się zrozumieć więcej asynchronicznego świata dostępnego w .NET. Task.Run i ThreadPool.QueueUserWorkItem pozwalają zarówno na wysyłanie pracy na wątku puli, ale jakie są różnice lub, jeśli wolisz, plusy i minusy dwóch? Oto moja lista profesjonalistów. Nie jestem pewien, czy jest kompletny, czy nawet poprawny.

ThreadPool.QueueUserWorkItem zalety:

• możliwość przejścia Argumentem

Task.Run wady:

• Możliwość dostarczania CancellationToken
• Możliwość oczekuje zakończenia zadania
• Możliwość zwrotu wartości do kodu

Answer 1

ThreadPool.QueueUserWorkItem nazywając to po prostu starsza realizacja (wprowadzony w .NET 1.1) robi to samo zadanie jak Task.Run (wprowadzony w .NET 4.5).

Firma Microsoft próbuje uniknąć wstecznej zgodności w .NET. Coś napisanego dla .NET 1.1 można skompilować i uruchomić w .NET 4.5 z (zwykle) bez zmian. Przerywanie zmian jest zwykle spowodowane zmianami kompilatora, a nie zmianami w strukturze, takimi jak the variable declared in a foreach used inside a lambada behaving differently in C# 5 and newer.

Nie ma prawdziwego powodu, aby używać ThreadPool.QueueUserWorkItem, gdy masz Task.Run.

Jeden punkt końcowy: jak na ironię, rzeczy zatoczyły już pełne koło z HostingEnvironment.QueueBackgroundWorkItem(...). Pozwala uruchomić coś na wątku w tle w środowisku ASP.NET i pozwolić, aby praca w tle była powiadamiana o zamykaniu serwerów przez serwer WWW (co często może się zdarzyć podczas długich okresów bezczynności).

Answer 2

Jedna różnica między ThreadPool.QueueUserWorkItem a Task.Run Niedawno zdałem sobie sprawę z tego, jak radzą sobie z wyjątkami.

Jeśli w pliku wystąpi nieobsługiwany wyjątek i nie zostanie obsłużony przez obsługę wyjątków globalnych, spowoduje to awarię wątku nadrzędnego. Z drugiej strony, nieobsługiwane wyjątki od wątku Task.Run nie będą propagowane, dopóki nie uzyskasz await lub Task.Wait.