Tę serię przede wszystkim należy zacząć od pytania – po co nam to? To z kolei możemy rozbić na dwa kolejne. Po co nam w ogóle programowanie równoległe oraz po co nam TPL – przecież już mamy dostępne narzędzia.

Po co nam to w ogóle

Mam nadzieję, iż tak na prawdę na to pytanie odpowiadać nie trzeba, ale dla porządku zróbmy to. Potrzebujemy bo prawo Moore’a przestaje działać. Nie możemy już powiedzieć naszemu klientowi, który narzeka na słabą wydajność aplikacji, że gdy będziemy wydawać to oprogramowanie to procesory będą dwukrotnie szybsze więc nie będzie problemu (pytanie: czy ktoś kiedykolwiek tak powiedział?? :)). Dodatkowo procesory teraz posiadają 2 lub więcej rdzeni więc tak na prawdę wykorzystujemy tylko cząstkę dostępnej nam mocy. Przez to nasze aplikacje pracują mniej wydajniej i obciążając procesor blokują inne.

Po co nam TPL

No dobrze. Nawet jeśli widzimy potrzebę wykorzystania drzemiącej mocy naszych procesorów, to po cóż nam coś nowego? Przecież mamy namespace System.Threading. Po cóż więc nam coś nowego – jakieś Taski i inne takie? W zasadzie – po nic. Problem z System.Threading jest jednak taki, że API tam dostępne jest skomplikowane i przez to nie jest wykorzystywane w wielu przypadkach. Zrównoleglenie kodu zawsze zostawiamy na potem, aż w końcu po release’ie stwierdzamy, że znów zapomnieliśmy o nim – no bo w końcu wydajność to nie jest nasz priorytet.

TPL wprowadza nową jakość do wątków – udostępnia je – jak to powiedział Scott Hanselman – dla mas. Dzięki nowemu i prostszemu API więcej osób w łatwy sposób będzie mogło zrównoleglić kod w swojej aplikacji. Jednak nie dajcie się zwieść – to, że API jest łatwe, ładne i przyjemne nie oznacza, że nie można za jego pomocą zrobić sobie krzywdy. Można! Jednak jeśli będziemy uważni, możemy dużo więcej osiągnąć.

Na dziś tyle. Zainteresowani tematem znajdą dużo informacji w linku poniżej – a już niedługo przestanę teoretyzować i zaczniemy bawić się naszym nowym API.

Link: Parallel Computing