Kanał - ATNEL tech-forum
Wszystkie działy
Najnowsze wątki



Teraz jest 28 mar 2024, o 17:46


Strefa czasowa: UTC + 1





Utwórz nowy wątek Odpowiedz w wątku  [ Posty: 5 ] 
Autor Wiadomość
PostNapisane: 1 mar 2015, o 14:11 
Offline
Moderator
Avatar użytkownika

Dołączył(a): 03 paź 2011
Posty: 27212
Lokalizacja: Szczecin
Pomógł: 1041

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 ]



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 1 mar 2015, o 22:48 
Offline
Użytkownik
Avatar użytkownika

Dołączył(a): 23 maja 2014
Posty: 317
Pomógł: 19

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



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 2 mar 2015, o 12:46 

Pomógł: 0

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 ;).



Góra
  
cytowanie selektywne  Cytuj  
PostNapisane: 3 mar 2015, o 02:28 
Offline
Nowy

Dołączył(a): 11 sty 2014
Posty: 7
Pomógł: 1

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ść ;) ):
Składnia: [ Pobierz ] [ Ukryj ]
język csharp
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.

2) W momencie, kiedy potrzebuję włączyć swój "timer" umieszczam w kodzie:
Składnia: [ Pobierz ] [ Ukryj ]
język csharp
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.

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.



Ostatnio edytowano 4 mar 2015, o 14:51 przez grzechupk, łącznie edytowano 1 raz

Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 4 mar 2015, o 12:31 
Offline
Nowy

Dołączył(a): 11 sty 2014
Posty: 7
Pomógł: 1

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



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
Wyświetl posty nie starsze niż:  Sortuj wg  
Utwórz nowy wątek Odpowiedz w wątku  [ Posty: 5 ] 

Strefa czasowa: UTC + 1


Kto przegląda forum

Użytkownicy przeglądający ten dział: Brak zidentyfikowanych użytkowników i 1 gość


Nie możesz rozpoczynać nowych wątków
Nie możesz odpowiadać w wątkach
Nie możesz edytować swoich postów
Nie możesz usuwać swoich postów
Nie możesz dodawać załączników

Szukaj:
Skocz do:  
Sitemap
Technologię dostarcza phpBB® Forum Software © phpBB Group phpBB3.PL
phpBB SEO