Zaktualizowałem swój kod, aby używać zadań zamiast wątków ...Czy powinienem zauważyć różnicę w używaniu zadania vs wątków w .Net 4.0?
Patrząc na użycie pamięci i procesor, nie widzę żadnych ulepszeń na wielordzeniowym komputerze, czy jest to oczekiwane?
Moja aplikacja uruchamia się zasadniczo wątków/zadań w różnych obiektach, gdy pracuje on ...
Wszystko robię to prosta
Task a = new Task(...)
a.Start();
Istnieją różne implikacje do korzystania Zadania zamiast wątków , ale wydajność nie jest znacząca (zakładając, że nie tworzysz ogromnej liczby wątków). Kilka kluczowych różnic:
Bardzo pomocne podsumowanie, dziękuję! –
Dzięki, to niezły przegląd. Teraz szukam pierwszego punktu, interesujące jest użycie TaskScheduler. – Kosko
@Kosko, jednym z typowych zastosowań TaskScheduler jest [TaskScheduler.FromCurrentSynchronizationContext] (http://msdn.microsoft.com/en-us/library/system.threading.tasks.taskscheduler.fromcurrentsynchronizationcontext.aspx), który planuje zadania do kontekst synchronizacji (zazwyczaj wątek interfejsu użytkownika). Jest to najczęściej używane podczas rejestrowania kontynuacji zadania, aby kontynuacja działała w wątku interfejsu użytkownika, a nie w puli wątków. Pomoże to uniknąć wielu brzydkich kodów Invoke w twoich metodach aktualizacji interfejsu użytkownika. –
Jednym ze znaczących ulepszeń Takss vs. Threads jest łatwość tworzenia łańcuchów zadań. Można określić, kiedy zadanie ma się rozpocząć po poprzednim zadaniu ("OnSuccess", "OnError", a.s.o.) i można określić, czy powinien istnieć przełącznik kontekstu synchronizacji. Daje to świetną okazję do uruchomienia długiego zadania w bakcground, a następnie interfejsu użytkownika, który wykonuje zadanie w wątku interfejsu użytkownika.
Jeśli po prostu wymieniłeś każde użycie Thread na Task i nie zrobiłeś żadnych innych zmian, spodziewałbym się praktycznie takiej samej wydajności. Interfejs API Task jest tak naprawdę właśnie taki, to API na istniejącym zestawie konstruktów. Pod maską wykorzystuje wątki, aby zaplanować działania i dlatego ma podobne cechy wydajności.
Co to wielki temat Task są nowe rzeczy można zrobić z nimi
ContinueWithTPL pozbywa się kodu obfuskującego wzdęcia. Jest to API, które każdy programista chce napisać, ale nie ma na to czasu. – Gusdor
Jeżeli jesteś używając .Net 4.0, możesz użyć równoległego.Wywołać metodę jak tak
Parallel.Invoke(()=> {
// What ever code you add here will get threaded.
});
o więcej informacji patrz http://msdn.microsoft.com/en-us/library/dd992634.aspx
Co takiego? Czytałeś pytanie? 'Patrząc na użycie pamięci i procesora, nie dostrzegam żadnych ulepszeń na wielordzeniowym PC, czy jest to oczekiwane?' –
Rozumiem, że Parallel.Invoke ma lepsze wykorzystanie wielordzeniowych. Teraz mogę się mylić, jeśli tak, proszę mnie pouczyć. –
1) Może, 'Parallel.Invoke' jest zaimplementowany z' Tasks'? 2) Gdzie jest odpowiedź na pytanie "Czy to jest oczekiwane?" –
Można by zobaczyć różnicę, jeśli oryginał lub przekształcone kod NIE utlize CPU całkowicie. To znaczy. jeżeli oryginalny kod zawsze ogranicza liczbę wątków do 2, na czterordzeniowym komputerze będzie działać z obciążeniem około 50% z ręcznie utworzonymi wątkami i potencjalnie z obciążeniem 100% z zadaniami (jeśli twoje zadania mogą być aktywowane paralellizująco). Wygląda więc na to, że albo oryginalny kod był rozsądny z punktu widzenia wydajności, albo obie implementacje cierpią na problemy z podobnym niewykorzystaniem CPU.
"Nie zauważam żadnych ulepszeń" To by tak bardzo zależało od rzeczywistego kodu ... Mogłeś nawet zauważyć pogorszenie. –
'Zadania' nie są klasami magicznymi. W końcu są one również "wątkami", –
Po prostu jednak Zadania są świadome środowiska wielordzeniowego, w przeciwieństwie do wątków, więc wiedzieliby, jak poprawnie się rozprowadzać na wielu rdzeniach. Również dlatego, że nie muszą być tworzone, ponieważ używają ThreadPool, będą bardziej wydajne pamięci. – TheWommies