🚀 go-pugleaf

iiui wrote:
> witam!
>
> kolejne pytanko - mam watek, ktory ma za zadanie cykliczne
> odpytywanie bazy i wysiwetlanie rezultatow w liscie. chce by ta
> funkcja dzialala jako odrebny watek.
>
> robie cos takiego:
>
> thread_get_posts = new Thread(new ThreadStart(get_posts));
> this.thread_get_posts.IsBackground = true;
> this.thread_get_posts.Start();
>
> wykonuje sie funkcja get_posts, ale tylko raz,
> zastanawiam sie co zrobic, by wykonywala sie cyklicznie.
> czy dobrym rozwiazaniem jest umieszczenie w tej funkcji czegos
> takiego :
[...]

Witam!

Musi być pętla, wątek to tylko rozgałęzienie w wykonywanym szeregowo kodzie.
Nie oznacza to, że ten kod będzie wykonywał w nieskończoność. W .NET
przerwanie wątku zostało rozwiązana przez zgłaszanie wyjątku. Spotkałem się
z rozwiązaniem, w którym w pętli należało regularnie sprawdzać warunek czy
wątek został poproszony o zakończenie. A .NET wątek dostaje wyjątek do
obsłużenia po wywołaniu metody Abort(). Metodę Abort() może wywołać także
system.

Podobnie jak z procesami. O wiele korzystniejsze jest, jak aplikacja zamknie
się sama niż system ubije proces i po nim posprząta przydzielone zasoby. Z
punktu widzenia systemu nie wiadomo co się dzieje w procesie, można np.
przez zabicie procesu nie zapisać zmian w pliku, itd. Dlatego Windows czeka
przed zabiciem na proces i pokazuje ładny pasek w okienku pokazujący czas.
Nie jest to wygodny i preferowany sposób zamykania.

Przy okazji wychodzi dlaczego okna czasem są całe białe. System wysyła do
okien komunikat z prośbą o przerysowanie. Ponieważ proces to przynajmniej
jeden wątek główny, czyli szeregowo wykonywany zestaw instrukcji, to
instrukcje przerysowania zostaną wywołane jak proces będzie na to miał
ochotę.

Jeśli aplikacja ma dwa wątki, jeden coś robi -- wątek poboczny. A jeden gada
z użytkownikiem -- wątek główny. Dodatkowo trzeba przygotować odpowiednio
okno, np. wyszarzać przycisk odpowiedzialny za wykonywa operacje. Okno musi
uwzględniać, że coś jest wykonywane wątku. Jeśli nie to użytkownik może
takiej aplikacji zrobić krzywdę uruchamiając coś co nie powinno być
uruchomione w tym momencie.

Dodatkowo niezła zabawa jest z umożliwieniem zamykania takie okna, w który
działa wątek. Moje rozwiązanie jest takie, że wysyłam do wątku prośbę o
przerwanie działania. Okna nie zamykam tylko zapamiętuje konieczność
zamknięcia. Dopiero jak wątek się zakończy wywoływane jest zaszarzenie w
kontekście wątku głównego, pod które jest podpięty kod ewentualnego
zamknięcia i odblokowania kontrolek okna. Przynajmniej tak robiłem w Delphi.
W .NET-cie jeszcze nie miałem do czynienia z wątkami.

Jak wywołałem metodę WaitFor (w .NET odpowiednik to metoda Join) w czasie
zamykania okna cała aplikacja się
blokowała. Nie dosyć, że w tym czasie nic się nie przerysuje to samo
zamkniecie okna może potrwać. Np. trzeba poprosić bazę dany o przerwanie
transakcji albo samemu coś posprzątać. To dodatkowo w Delphi był wywoływane
zdarzenie w kontekście wątku główne. Ponieważ wątek główny wisi na WaitFor
czekają na wątek poboczny, a wątek poboczny za to czekał na wykonanie metody
czy coś
podobne. W każdym razie powstało zakleszczenie, deadlock.

Jeśli to wszystko nie przerażą, trzeba jeszcze wspomnieć o synchronizacji
między wątkami. Komputer to działa szeregowo, kolejne linijki kodu zależą o
stanów powstałych po wywołaniu poprzednich. Program nie działał by gdybyś
zaczął wszystkie te linijki kodu wykonywać w dowolnej kolejności. Dodatkowo
linki kodu nie są atomowe tylko rozkazy procesora.

Zatem jeśli dopuścisz aby dwa wątki pisały po jednym obszarze pamięci to
efekt tego jest nieokreślony. W przypadku procesów jest osobna wirtualna
przestrzeń adresowa. Procesor jest w trybie chronionym i przekazanie
wskaźnika do innego procesu nie ma sensu. Poza tym próba odczytu fizycznej
pamięci nie należącej do procesu lub praca na wskaźniku bez sensu kończy się
wyłapaniem tego przez procesor. Co kończy się sławnym komunikatem Access
Violation itp.

-- 
Pozdrawiam,
Marek Janaszewski
[ j_m...@gazeta.pl ]