3.25. W±tki, Semestr III, Systemy informatyczne, Laboratoria, Visual C++

3.25. W±tki

3.25. W±tki, Semestr III, Systemy informatyczne, Laboratoria, Visual C++ - Vademecum profesjonalisty (PL)

[ Pobierz całość w formacie PDF ]
Rozdział 25WštkiW tym rozdziale: WštkiTrudnoci w programowaniu z użyciem różnych wštkówUruchamianie, wykorzystywanie i zatrzymywanie wštkówDzielenie obiektów MFC pomiędzy wštkamiKorzystanie z funkcji biblioteki czasu wykonania C w aplikacjach wielowštkowychProgram demonstracyjny korzystajšcy z wštkówW rodowisku Win32 każda działajšca aplikacja stanowi proces, za każdy proces zawiera jeden lub więcej wštków wykonania. Wštek (ang. thread) jest cieżkš wykonywania w kodzie procesu. Jednš z podstawowych różnic pomiędzy 16- i 32-bitowym systemem Windows jest to, że system 32-bitowy nie ogranicza aplikacji do posiadania tylko jednego wštku. Proces w 32-bitowej aplikacji Windows rozpoczyna życie jako pojedynczy wštek, jednak może on tworzyć dodatkowe wštki. Mechanizm wywłaszczania zawarty wewnštrz systemu operacyjnego dzieli czas procesora pomiędzy aktywne wštki, dzięki czemu wydaje się, że działajš one równoczenie. Kolejne wštki sš idealne do wykonywania zadań w tle, takich jak podział dokumentu na strony czy czyszczenie pamięci. Kolejne wštki mogš pełnić także bardziej widoczne role, tworzšc okna i kierujšc do nich komunikaty, podobnie jak główny wštek aplikacji.Wielowštkowoć nie jest dla każdego. Aplikacje wielowštkowe sš trudne w pisaniu i debuggowaniu, gdyż równoległe wykonywanie konkurencyjnych wštków tworzy dodatkowy poziom złożonoci kodu. Jednak użyte właciwie kolejne wštki mogš znacznie zwiększyć szybkoć reagowania aplikacji. Na przykład procesor tekstów, w którym sprawdzanie pisowni odbywa się w osobnym wštku, może w głównym wštku wcišż przyjmować wprowadzany tekst, bez zmuszania użytkownika do oczekiwania na zakończenie działania funkcji sprawdzania pisowni. To, co sprawia, że sprawdzanie poprawnoci tekstu może być doć trudnym zadaniem, to koniecznoć synchronizacji jego działania z innymi wštkami w aplikacji.Większoć programistów była przyzwyczajana do tego, że kod jest wykonywany synchronicznie - czyli że funkcja A wywołuje funkcję B, funkcja B inicjuje zmiennš c, funkcja B wraca do funkcji A i tak dalej. Jednak wštki w aplikacji wielowštkowej sš z natury asynchroniczne; musisz więc brać pod uwagę, co się stanie, gdy, powiedzmy, dwa wštki wywołajš funkcję B w tym samym czasie lub gdy jeden z wštków odczytuje zmiennš w momencie, gdy drugi wštek dokonuje do niej zapisu. Jeli funkcja A wywołuje funkcję B w innym wštku, musisz przewidzieć, jakie problemy mogš wystšpić, gdy funkcja A będzie wcišż działała w momencie wykonywania funkcji B. Na przykład, często zdarza się przekazywanie do funkcji B adresu zmiennej utworzonej na stosie w funkcji A. Lecz jeli funkcja B jest w innym wštku, ta zmienna może już nie istnieć w chwili, gdy funkcja B będzie się do niej odwoływała. Nawet najbardziej niewinnie wyglšdajšcy kod może, w przypadku aplikacji wielowštkowej, okazać się pełen pułapek i niebezpieczeństw.W MFC wštki sš reprezentowane poprzez klasę CWinThread. Biblioteka posiada także klasy reprezentujšce zdarzenia, mutexy i inne obiekty synchronizacji wštków występujšce w jšdrze Windows. Czy MFC ułatwia używanie wštków? Niekoniecznie. Programici przywykli do pisania wielowštkowych aplikacji w C często sš zdumieni, gdy dowiadujš się, że MFC wprowadza dodatkowy poziom złożonoci. Kluczem do pisania wielowštkowych aplikacji w MFC jest posiadanie dobrej znajomoci tego, co się robi oraz poznania głównych miejsc, które mogš powodować problemy. Włanie tego będzie dotyczyć ten rozdział.WštkiZ punktu widzenia Windows wszystkie wštki sš takie same. Jednak z punktu widzenia MFC wštki dzielš się na dwa rodzaje: wštki interfejsu użytkownika (ang. user interface thread, Ul) oraz wštki robocze (ang.worker thread). Różnica pomiędzy nimi jest następujšca: wštki Ul posiadajš pętlę komunikatów, za wštki Ul jej nie posiadajš. Wštki Ul mogš tworzyć okna i przetwarzać komunikaty wysyłane do tych okien. Wštki robocze wykonujš zadania w tle, nie otrzymujšc bezporednich poleceń od użytkownika, i w zwišzku z tym nie potrzebuj š okien ani pętli komunikatów.Gdy za pomocš powłoki Windows otwierasz folder, powłoka uruchamia wštek Ul tworzšcy okno przedstawiajšce zawartoć foldera. Jeli poprzez przecišgnięcie kopiujesz grupę plików do nowo otwartego foldera, wštek foldera przeprowadza kopiowanie plików. (Czasem wštek Ul tworzy kolejny wštek - w tym przypadku wštek roboczy, zajmujšcy się kopiowaniem plików). Zaletš takiej wielowštkowej architektury jest to, że po rozpoczęciu operacji kopiowania możesz przełšczyć się do innego okna i kontynuować pracę, za pliki będš w tym czasie kopiowane w tle. Uruchomienie wštku Ul tworzšcego okno jest koncepcyjnie podobne do uruchomienia aplikacji wewnštrz aplikacji. Najczęstszym zastosowaniem wštków Ul jest tworzenie wielu okien obsługiwanych przez różne wštki wykonywania.Wštki robocze idealnie nadajš się do wykonywania odizolowanych zadań, które można oderwać od reszty aplikacji i wykonywać w tle, podczas gdy na głównym planie wykonywane sš inne operacje. Klasycznym przykładem wštku roboczego jest wštek w animowanej kontrolce odtwarzajšcej pliki .AVI. Mówišc ogólnie, wszystko co ten wštek robi, to rysowanie klatki animacji na ekranie, zanięcie na ułamek sekundy, obudzenie się, rysowanie kolejnej klatki i tak cały czas. Taki wštek obcišża procesor w niewielkim stopniu, gdyż większoć swego życia trwa w stanie wstrzymania pomiędzy klatkami, mimo to stanowišc cennš usługę. To dobry przykład wielowštkowej konstrukcji, gdyż wštkowi w tle zostało powierzone okrelone zadanie, które jest wykonywane w kółko aż do momentu, gdy główny wštek stwierdzi, że Już wystarczy".Tworzenie wštków roboczychW aplikacji MFC istniejš dwa sposoby tworzenia wštku. Pierwszym z nich jest skonstruowanie obiektu cwinThread i wywołanie jego funkcji CreateThread o w celu stworzenia wštku, za drugim jest użycie funkcji AfxBeginThread () w celu stworzenia obiektu cwinThread oraz wštku w jednym kroku. MFC definiuje dwie wersje funkcji AfxBeginThread (): jednš dla wštków Ul oraz jednš dla wštków roboczych. W programach MFC do tworzenia wštków nie używaj funkcji Win32 : : CreateThread (), chyba że nie będziesz w nich korzystał z MFC. Funkcje AfxBeginThread() oraz cwinThread: :CreateThread () nie sš prostymi funkcjami poredniczšcymi dla funkcji : : CreateThread (); oprócz uruchamiania wštków wykonywania przeprowadzajš także inicjalizację wewnętrznych zmiennych MFC, w kilku miejscach sprawdzajš poprawnoć tworzenia wštku oraz zapewniajš, że funkcje w bibliotece czasu wykonania C sš dostępne w sposób bezpieczny ze względu na wštki.Utworzenie wštku roboczego za pomocš funkcji Af xBeginThread () jest tak proste, że wręcz trywialne. Poniższa linia uruchamia wštek roboczy i przekazuje mu adres zdefiniowanej przez aplikację struktury danych o nazwie Threadinfo, zawierajšce dane wejciowe dla wštku:CWinThread *pThread = AfxBeginThread( ThreadFunc, SThreadlnfo );ThreadFunc to funkcja wštku - funkcja wykonywana, gdy wštek rozpoczyna działanie. Na przykładzie poniżej została przedstawiona bardzo prosta funkcja, wykonujšca pętlę zajmujšcš czas procesora, po czym kończšca działanie wštku:UINT ThreadFunc( LPVOID pParam)UINT nlterations = (UINT) pParam;{for( UINT i=0; i < nlterations; i++);return 0;}Funkcjami wštków zajmiemy się bardziej szczegółowo w następnej sekcji. Funkcja AfxBeginThread() dla wštku roboczego akceptuje do czterech dodatkowych parametrów okrelajšcych priorytet wštku, rozmiar stosu, znaczniki tworzenia oraz atrybuty ochrony. Pełny prototyp funkcji wyglšda następujšco:CWinThread *AfxBeginThread( AFX_THREADPROC pfnThreadProc, LPYOID pParam, int nPriority = THREAD_PRIORITY_NORMAL, UINT nStackSize = O, DWORD dwCreateFlags = O, LPSECURITY_ATTRIBUTES IpSecurityAttrs = NULL );Parametr nPriority okrela priorytet wykonywania wštku. Wštki o wysokim priorytecie sš wybierane zawsze przed wštkami o niskim priorytecie, lecz w praktyce nawet wštek o bardzo niskim priorytecie otrzymuje wystarczajšcš iloć czasu procesora. Parametr nPriority nie okrela bezwzględnego poziomu priorytetu, a jedynie poziom priorytetu w odniesieniu do poziomu priorytetu procesu, do którego należy wštek. Domylnym priorytetem jest THREAD_PRIORITY_NORMAL, przypisujšcy wštkowi ten sam priorytet, jaki ma proces posiadajšcy ten wštek. W dalszej częci rozdziału omówimy także inne poziomy priorytetów. Priorytet wštku może być w każdej chwili zmieniony za pomocš funkcji CWinThread: : SetThreadPriority () .Parametr nStackSize przekazywany funkcji AfxBeginThread() okrela maksymalny rozmiar stosu dla wštku. W rodowisku Win32 każdy wštek otrzymuje własny stos. Domylna wartoć parametru nStackSize, zero, umożliwia rozrost stosu do l MB. Nie oznacza to, że każdy wštek otrzymuje minimum l MB pamięci, a jedynie, że każdemu wštkowi jest przypisywany l MB obszaru przestrzeni adresowej z 4GB przestrzeni adresowej aplikacji Win32. Pamięć dla stosu nie jest przypisywana aż do chwili, w której jest potrzebna, więc większoć stosów wštków nie przekracza zwykle kilku kilobajtów. Okrelenie limitu dla rozmiaru stosu umożliwia systemowi operacyjnemu wyłapanie błędnych funkcji, zawierajšcych nieskończonš rekurencję i mogšcych zajšć cały stos. Domylny limit l MB jest wystarczajšcy w ogromnej większoci aplikacji.Parametr dwCreateFlags może przyjmować jednš z dwóch wartoci. Domylna wartoć O informuje system, by natychmiast rozpoczšł wykonywanie wštku. Jeli zamiast tego zostanie przekazana wartoć CREATE_SUSPENDED, wštek rozpoczyna istnienie w stanie zawieszenia i nie zaczyna działania do chwili, gdy inny wštek (zwykle wštek tworzšcy) nie wywoła funkcji CWinThread: : ResumeThread () dla zawieszonego wštku:CWinThread *pThread = AfxBeginThread( ThreadFunc, SThreadlnfo, THREAD_PRIORITY_NORMAL, O, CREATE_SUSPENDED, NULL );Czasem przydatne je... [ Pobierz całość w formacie PDF ]

Linki

: 3. M1 DohnalJ MatusiakK ZAD3, Studia Politechnika Poznańska, Semestr VIII (MiBM), Wytrzymałość materiałów II, Wytrzymałość materiałów II 2014, Grupa M1

: 2013 Ankieta 2 dla klientow wewnetrznych 15 02 2013, Studia Zarządzanie PWR, Zarządzanie PWR II Stopień, II Semestr, Kontroling, Ćwiczenia