Ja bym do tego co powyżej dodał jeszcze takie coś. Otóż ciężko nawet porównywać timer vs thread, dlatego że to całkiem odmienne twory. Prędzej można byłoby porównać thread vs event w programie ...

Timer albo powołanie jakiegoś zdarzenia (Eevent'a) ... przede wszystkim zawsze będzie się wykonywało w ramach głównego wątku aplikacji - no bo z tego sobie należy zdać sprawę - że aplikacja to już jest jeden główny thread (wątek) ... i teraz tak bardzo ogólnie mówiąc - dokąd wystarcza ci stosowanie timerów i eventów w twoich aplikacjach a przez to nie natrafiasz na żadne problemy które mogą wyniknąć w pewnych sytuacjach (np zamrażanie formy głównej ponieważ nagle jakiejś obsłudze timera albo zdarzenia powierzyłeś zbyt długotrwałą operację) .... no to spokojnie można korzystać z timerów i eventsów ....

Ale gdy w pewnym momencie dojdziesz do takich aplikacji gdzie będzie trzeba w trakcie działania głównego programu, który coś musi robić (chociażby to miało oznaczać tylko interakcję z użytkownikiem na ekranie w głównym oknie) a jednocześnie musisz np obsługiwać ciężką i długotrwałą komunikację asynchroniczną RS232 albo obsługę jakiejś bazy danych (sporo obliczeń) .... i mogłoby to doprowadzić do zakłóceń w działaniu głównego wątku programu - to wtedy zaczyna być sensowne rozważenie po prostu użycia dodatkowych wątków, w których będziesz wykonywał długotrwałe operacje. Jednocześnie wtedy trzeba rzeczywiście dobrze przemyśleć komunikację i synchronizację pracy wszystkich wątków z wątkiem głównym - a szczególnie gdy ma to mieć bezpośredni wpływ na interfejs użytkownika.

Przy okazji żeby wyjaśnić dlaczego moim zdaniem ciężko tu porównywać thread vs timer, to podpowiem tylko że w ramach wątku możesz sobie odpalić wiele timerów a nawet zdarzeń ... a odwrotnie jest to niemożliwe. Co najwyżej można powołać do życia jakiś wątek(-ki) w trakcie tyknięcia timera ...

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Ja odpowiem w największym skrócie i najprościej jak tylko potrafię. Przede wszystkim wewnątrz funkcji Thread (gdzie odpalamy wątek) może być jakiś timer/timer'y. Po drugie timer/timer'y może sobie zrobić być w aplikacji niezależnie (tzn. w ogóle nie stosując wątków).
Z praktycznego punktu widzenia to jest tak, że jeśli odpalisz aplikację gdzie zaimplementowałeś za dużo zależności od timer'a/timerów to zamulisz trochę system operacyjny (tzn. będzie zauważalny spadek wydajności w postaci reakcji we/wy typu kliknięcie na klawiaturze a reakcja na ekranie).
Przykład z życia: robisz aplikację, która wysyła dane przez port db-9 rs232 i jeśli to będzie dużo danych to na czas wysyłania/odbierania danych przyblokujesz sobie trochę system operacyjny jeśli funkcji wysyłającej/odbierającej dane nie zrobisz jako funkcji typu thread (wątek).

Ja nauczyłem się stosować wielowątkowość z książki: "C++ Builder 6 i bazy danych.", autor. Marian Wybrańczyk
Acha! Tylko ta książka jest o C++, a nie o C#.

Pozdrawiam! j23 Jarek

_________________
"O sygnałach bez całek" Czesław Frąc

Ja dam drugi przykład z życia, jak masz wiele połączeń, np. z czujników, urządzeń. TO absolutnie nie radzę, usypiać wątków, np. by zrobić jakieś opóźnienie komunikatu zwrotnego whatever .
Przy kilku uśpionych wątkach, jeszcze jest ok, ale przy 20-30stu, potrafi się zawiesić nawet komp z 2 rdzeniowym intelem .

W .NET Framework 4.5 dodali bardzo fajne rozwiązanie na programowanie asynchroniczne: https://msdn.microsoft.com/pl-pl/library/hh191443.aspx
Ja ostatnio zacząłem robić tak:
1) Tworzę sobie "funkcję timerową" (ta jest niepraktyczna, co sekundę wysyła do wszystkich tę samą wiadomość ):

2) W momencie, kiedy potrzebuję włączyć swój "timer" umieszczam w kodzie:

A działa to mniej więcej tak:
1) Funkcja GameAsync() od momentu odpalenia poleceniem Task.Run() będzie działała w kółko, ponieważ wewnątrz niej jest nieskończona pętla.
2) Najpierw funkcja wywoła inną funkcję, w tym wypadku ServerSendToAll(...)
3) Kiedy już tamta się wykona, nastąpi wyście z funkcji GameAsync() i mogą się wykonywać inne operacje.
4) Kiedy odliczanie dobiegnie końca (dba o to słówko await) program wróci do wnętrza funkcji GameAsync() i kontynuuje swoje działanie, czyli tutaj nastąpi kolejne przejście funkcji. Znowu wyśle wiadomośc do wszystkich, zacznie czekać, wyjdzie z tej funkcji żeby dać innym swobodę działania, i wróci dopiero kiedy Task.Delay(int d) się skończy. I tak w kółko.

Coś czuję, że moje tłumaczenie jest dość marne, ale naprawdę warto zainteresować się tym tematem. Być może mój przykład jest nienajlepszy, ale te nowości można z powodzeniem stosować do innych potrzeb, takich jak czekanie na zapis do pliku czy na odpowiedź serwera HTTP. Przy okazji chciałbym się dowiedzieć, czy takie podejście (ten konkretny przykład) jest w miarę OK.

Z tego co się orientuję to jest to tak zwane wyrażenie lambda ( => ). Po lewej stronie umieszczamy argumenty (u nas ich brak, dlatego są puste nawiasy), a po prawej instrukcję do wykonania. To jest pewnie zrobione po to, żeby można było wywoływać dowolną funkcję z dowolną liczbą argumentów i o dowolnych typach. W przeciwnym wypadku Task.Run oczekiwałaby jakiegoś konkretnego typu funkcji (np int func(char c)), a tak oczekuje tzw akcji (jakiegos wyrazenia lambda) i jest to bardzo uniwersalne. Dla nas to tylko zwykłe przekazanie callbacka do wywołania Od razu dodam, że zajmuję się tym amatorsko i niezbyt długo, dlatego w razie czego proszę o poprawienie Tutaj trochę informacji: https://msdn.microsoft.com/pl-pl/library/bb397687.aspx