V OS Windows (XP, NT) sú vlákna (Threads) vnímané ako neoddeliteľná súčasť procesu. Proces predstavuje obálku zdrojov (pamäť, handlery, atd) nad vláknami, ktoré realizujú samotnú činnosť. Plánovanie prebieha nad samotnými vláknami a nie nad procesmi (čo dáva zmysel). Prideľovanie priorít procesom má priamy vplyv na chovanie plánovača (scheduler) k vláknam. V prípade ak bude záujem o detailnejšie rozobratie tejto tématiky, na konci seríálu môže na požiadanie pribudnúť kapitola na túto tému.
Okrem klasických vláken existujú i tzv. Fibres. Jedná sa o jadrom nevidenú abstrakciu vláken, ktorej plánovanie musí zabezpečovať užívateľský kód. Tým odpadá réžia spojená s plánovaním (prechod do kernel mód, návrat, atď) no pribúdajú problémy ako blokovanie, spravodlivosť atď.
Dosť bolo teórie, vrhneme sa na prvý projekt.
Projekt Vytvoríme si konzolovú aplikáciu a nazveme ju napr. “
console_thread“ (File->New->Win32 Console Application). V prípade aplikácii je treba si overiť, či používané knižnice sú s podporou multithreadingu. Aby sme toto zaručili a nedostali chybu linkeru
2001 o nevyhodnotených externých symboloch, nastavíme behovú knižnicu (run-time library) na Debug Multithread. Toto nastavenie nájdete v
Project Settings. Zvyšok ukazuje obrázok.
Prvý kód
Dnes sa posnažíme vlákno spustiť a uspať a nakoniec počkáme na ukončenie vlákna.
Stretneme sa tu s dvoma funkciami. Prvou je
AfxBeginThread a druhou je
CreateThread. Jedná sa o podobné funkcie a až na pár drobností vykonávajú tieto funkcie rovnakú úlohu – vytvoria vlákno a prípadne ho nechajú vykonávať. Popíšeme si funkciu
AfxBeginThread. V prípade, že vás zaujíma
CreateThread, MSDN vám určité kompetentne vysvetlí o čo sa jedná.
AfxBeginThread existuje v dvoch mutáciách. Líšia sa v tom, aký typ vlákna vytvoria. V OS Windows sa vlákna chápu ako
worker-thread a
user-interface thread. Prvé spomenuté vlákno nemá tzv.
MessagePump, ktorá je určená na odovzdávanie správ OS.
Worker-threads sú určené na riešenie výpočtových úloh a
User-interface threads na obsluhu užívateľského rozhrania.
V tejto lekcii sa budeme zaoberať
worker-threadmi.
CWinThread* AfxBeginThread(
AFX_THREADPROC pfnThreadProc,
LPVOID pParam,
int nPriority = THREAD_PRIORITY_NORMAL,
UINT nStackSize = 0,
DWORD dwCreateFlags = 0,
LPSECURITY_ATTRIBUTES lpSecurityAttrs = NULL );
Nebudem kompletne prepisovať popis parametrov tejto funkcie. Zameriame sa len na dôležité položky ako
AFX_THREADPROC pfnThreadProc, LPVOID pParam a DWORD dwCreateFlags. Ostatné parametre preberieme pri iných príležitostiach (ďalších lekciách) prípadne si ich vysvetlenie môžete dohľadať v MSDN.
AFX_THREADPROC pfnThreadProc
Je ukazovateľ na funkciu, ktorá reprezentuje obsluhu vlákna. Táto funkcia je volaná ako telo vlákna, podobne ako telo funkcie
main(int, char []) je vykonávané pri spustení programu. Dôležité je nezabudnúť, že volaná funkcia musí mať tvar
UINT NázovFunkcie (LPVOID MenoParametrov);
Čitatelia, ktorí sú zbehlejší v programovaní pod Windows vedia, že sa jedná o funkciu vracajúcu bezznamienkový integer (unsigned int) a ako parameter je ukazovateľ na void (void*).
LPVOID pParam
Tento parameter je pri volaní funkcie reprezentujúcej telo vlákna vkladaný ako parameter tejto funkcie.
DWORD dwCreateFlags
Úlohou tohoto parametru je charakterizovať, v akom stave sa má vlákno spustiť. Ak je tento parameter nastavený na 0 tak je vlákno hneď zaradené do fronty vláken čakajúcich na procesor. Ak parametru priradíme hodnotu
CREATE_SUSPENDED, vlákno sa vytvorí v suspended stave, teda s jeho vykonávaním sa čaká až do zavolania
CWinThread::ResumeThread. Túto vlastnosť je možné využiť napríklad pre preprocessing dát pre vlákno.
Tu uvediem všeobecne platné varovanie platné pre každého programátora – Dávajte si pozor či ako parameter nedávate adresu na lokálnu premennú, prípadne na niečo, čo pri volaní funkcie nemusí byť aktuálne platné pamäťové miesto. Nič vám nezaručuje, kedy sa presne zavolá telo obslužnej funkcie vlákna (závisí to napr. od priority vlákna).
Začneme teda s programovaním. Napíšeme si klasickú
“HELLO THREAD WORLD“ aplikáciu.
#include "stdafx.h"
//obsahuje funkcie na operacie s threadmi
#include "Afxwin.h"
//priznak aktivneho cakania
volatile int a;
//funkcia ktora je telom vlakna - exekutiva
UINT ThreadA (LPVOID pParam)
{
printf("ThreadA: HELLO THREAD WORLDn");
a=0;
return 1;
}
int main(int argc, char* argv[])
{
a=1;
//vytvorenie vlakna
AfxBeginThread(ThreadA,NULL);
//aktivne cakanie
for(;a;);
//vypis hlasky
printf("Main: Hello World!n");
//koniec
return 0;
}
V práve uvedenom kóde sa vyskytlo pár zaujímavých konštrukcií, ktoré si bližšie vysvetlíme.
volatile int a;
kľúčové slovo
volatile vraví kompilátoru, že nemá nad touto premennou robiť optimalizácie a premenná sa teda vždy pri použití načíta z pamäte. Ak by to tak nebolo, premenná by mohlo byť či už ignorovaná alebo ukladaná do pomocných registrov.
Túto premennú používame v kóde na tzv.
aktívne čakanie. Pri aktívnom čakaní sa jedná o vytvorenie cyklu, ktorého jedinou úlohou je čakať až dôjde k zmene niektorej z premenných. Aktívne čakanie je veľmi neelegantné riešenie. V ďalšom príklade si ukážeme krajší prístup.
Prečo vlastne aktívne čakáme?
Ak si skúsite sami odstrániť cyklus aktívneho čakania z kódu, môžete po spustení dôjsť k záveru, že kód je chybný, lebo sa nevypísalo
“ThreadA: Hello Thread World“. Nejedná sa však o chybu, ale len o dôsledok plánovania. Hlavné vlákno (a s tým spojený proces) ukončili svoje vykonávanie ešte predtým ako sa na processor dostalo vlákno čo sme vytvorili. Dokonca by sa mohlo stať, že by sa hlášky prekrývali
(ThreadA: HELLO Main:Hello WoTHREADrld WORLD) ako dôsledok preplánovania.
Ostatné riadky kódu sú celkom zrozumiteľné.
Teraz sa pokúsime o trošku sofistikovanejší kód, ktorý pôsobí aj elegantnejšie.
#include "stdafx.h"
#include "Afxwin.h"
UINT ThreadA (LPVOID pParam)
{
//prva hlaska
printf("Thread A: First Hello Thread Worldn");
//spanok 2 sekundy
Sleep(2000);
//druha hlaska
printf("Thread A: Second Hello Thread World (after 2 seconds)n");
//konec
return 1;
}
int main(int argc, char* argv[])
{
//vytvorenie vlakna
CWinThread *o_thread=AfxBeginThread(ThreadA,NULL);
//premenna nahdlu na vlakno
HANDLE thread;
//pouzitie operatora, je mozne to ziskat aj priamo zo struktury
thread= HANDLE(*o_thread);
//cakanie
WaitForSingleObject(thread,INFINITE);
//vytlacenie hlasky
printf("Hello World!n");
//konec
return 0;
}
V kóde samotnom sa veľa toho nezmenilo. Nebudem sa tu na dĺžku rozpisovať o tom, ako v OS Windows fungujú
HANDLE. Jedná sa totiž o rozsiahlu tému, ktorá by vyčerpala aspoň jednu kapitolu. O
HANDLE stačí zatiaľ vedieť, že objekty OS, ktoré majú čo do činenia s vláknami sa dajú transformovať na
HANDLE (i iné objekty, pamäťové mapovania atď sa dajú transformovať, ale to je iná téma).
HANDLE ma tú krásnu výhodu, že sa na ňom dá čakať.
Čo je to Čakanie?
Čakania
(WAIT) je principiálne jednoduchý ale veľmi silný nástroj. Ak chcete aby vykonávaný kód zotrval na určitom mieste až do nejakej udalosti
(Signálu), jednoducho ho necháte čakať. Čakať môže kód „nekonečne“ dlho alebo dobu podľa potreby.
Na realizáciu tohoto efektu sa dá použiť funkcia
DWORD WaitForSingleObject(HANDLE hHandle, DWORD dwMilliseconds );
Tejto funkcii môžete predať ako druhý parameter číslo alebo definovanú hodnotu
INFINITE. Asi si sami domyslíte, ako to funguje.
Táto funkcia vie dokonca vrátiť návratový kód podľa toho, či sa dočkala, alebo či došlo k chybe
(viz. MSDN).
void Sleep(DWORD dwMilliseconds); Je ďalšou funkciou spomedzi tých najpoužívanejších. Jednoducho “uspí“ vlákno na dobu uvedenú ako parameter. Vlákno nebude plánované po túto dobu
(Sleeping thread, Suspended threads) a až po jej vypršaní sa znova zaradí do plánovacieho procesu. Jednoduché, že.
Na záver spomeniem v predstihu funkciu
DWORD WaitForMultipleObjects(
DWORD nCount,
CONST HANDLE *lpHandles,
BOOL fWaitAll,
DWORD dwMilliseconds );
Táto funkcia umožňuje čakať na aspoň jeden zo skupiny HANDLE alebo na všetky. V parametre
CONST HANDLE *lpHandles uvediete ukazovateľ na jeden z prvkov poľa
HANDLERov (väčšinou na ten prvý). V premennej
DWORD nCount nesmiete zabudnúť uviesť skutočný počet prvkov a
BOOL fWaitAll charakterizuje, či sa má čakať na všetky (
fWaitAll nastaviť na
TRUE), alebo len na (aspoň) jeden.
I keď sa to zdá málo kódu, i s tým sa dajú robiť nepekné experimenty.
Dobrým cvičením je sznchronizácia viacerých vláken v presnom poradí.
Týmto by som uzavrel túto už dosť dlhú lekciu. Zdrojové kódy v podobe projektu nájdete
TU.
zdravim, ked chcete pisat a porovnavat vlakna os tak je vhodnejsie pouzivat priamo api os a nie zapuzdrenie cez mfc, na taketo priklady je vhodnejsie C ako c++, visual a podobne "rozsirenia". naviac win api nepozna worker thread a ui thread
Problem s nazvom temy je ten ze som ho nevolil ja (je dost zavadzajuci, kedze MFC je urcita forma zrozumitelnejsieho obalu API).Nejak som nikde nespomenul ze by sa jednalo priamo o Win32 API. JE to zabalene v MFC, to je na pochopenie lahsie. V ramci mojej skusenosti sa MFC chape lepsie a ked prejde do krvi (ako tak) pochopenie API je uz hracka. Pritom MFC je uhladenejsie a pochopitelnejsie na pohlad. MFC umoznuje rozlisovat Worker a UI vlakna. Z pohladu OS sa nejedna o rozdielne vlakna.odkaz pouzitia C alebo C++ je v tom ze vlakna niesu sucast ziadnej specifikacie. Cize ci uz pouzijem MFC, Win32 api, dolezite je pochopit podla mna vo co go. Cize pouzitie MFC je uplne legitimne, vzhladom na to ze docela schopne obaluje API.V clanoku som odkazal na funkciu CreateThread, len som nespomenul, ze sa jedna o API a v pripade Afx... sa jedna o MFC, nabuduce to nejak blizsie rozlisim. Problem je v tom, ze keby som mal o vsetkom pisat az do krvavej podrobnosti, upisem sa k smrti. Predpokladam ze citatelia maju dost schopnosti na pouzitie helpu na dohladanie drobnosti...A porovnavat vlakna v OS nieje ucelom mojich clankov, jedna sa skor o prakticke pouzitie. Ale dik za upozornenie...
zdravim, ale prvy diel serialu hovori aj o linuxe, tam asi mfc nevyuzijem, preto by bolo vhodnejsie ciste c, aby boli priklady na rovnocenej urovni programovania, ak to napisete z pohladu api os je clanok univerzalnejsi a ma vypovedaciu schopnost aj pre ine jazyky (napr. pascal, resp. jeho implementacia v delphi)
na linux budu vlastne clanky (atam ciste C bude.v tejto teme je dolezite pochopenie problematiky. v tomto ohlade si myslim ze priklady musia byt co najpochopitelnejsie - na co je MFC docela vhodne.90-95% je logika 5-10% syntaxpopremyslam teda nad cistym C a LEN API, problem je v tom, ze ak je clovek na nieco trosku zvyknuty, moze do toho lahko sklznut.a nieje nahodou aj v DELPHI Win32 API obalene nejako?v delhi niesom taky zbehly.
Ale o čo to tu ide? na čo su dobre vlakna? Jednoducho nechapem na čo je toto potrebne - môže mi to niekto objasniť ? ... :D
Chcel by som sa spytat, ci existuje na Win nieco ako trylock na Linuxe. Pripadne cim by sa to dalo nahradit?