Welcome to BitCell. Click here to register !
Probabil ca ati auzit de multi ori de "thread-uri", de "multi-threading", "thread-ul principal" si alte notiuni asemanatoare. Acum e momentul sa clarificam ce inseamna lucrurile astea si sa vedem cum putem lucra cu thread-uri in Delphi.
Thread si multi-thread
Una din caracteristicile importante ale sistemelor Windows, incepand cu Windows 95, este posibilitatea de a lansa mai multe fire de executie dintr-un singur proces. Mult timp dupa ce au aparut primele calculatoare (si, evident, programarea), programarea a ramas "single threaded". Iti perforai cartelele, le duceai la centrul de calcul si, dupa cateva zile, primeai un alt teanc de cartele care contineau, daca aveai noroc, ceea ce vroiai. Totul se procesa in ordine, FIFO (primul venit, primul servit), nu era nicio graba, iar cand programul tau rula, calculatorul era "atent" doar la el.
Conceptul de "multiple threads" (mai multe fire de executie a aparut prima oara cu sistemele "time sharing", unde mai multe persoane puteau accesa acelasi computer si resursele lui, intr-un mod concurent (aparent, in acelasi timp). Calculatorul era responsabil pentru intretinerea acestei iluzii, impartindu-si timpul intre userii logati (de obicei, prin verificari secventiale pe fiecare statie conectata la el).
DOS si primele versiuni de Windows puteau rula un singur program la un moment dat. Cu timpul, pe masura ce aplicatiile au devenit tot mai sofisticate (games, anyone ?
), conceptele de multi-tasking si multi-thread au devenit un lucru obisnuit (cate aplicatii ai deschise in momentul asta si cate thread-uri are fiecare ?).
DOS si primele versiuni de Windows puteau rula un singur program la un moment dat. Cu timpul, pe masura ce aplicatiile au devenit tot mai sofisticate (games, anyone ?
), conceptele de multi-tasking si multi-thread au devenit un lucru obisnuit (cate aplicatii ai deschise in momentul asta si cate thread-uri are fiecare ?).Orice proces (aplicatie) contine cel putin un thread, denumit "thread-ul principal". Acest thread (fir de executie) este responsabil cu procesarile de mesaje (cele din Windows sau din aplicatii), modificarile vizuale ale programului, etc. In mod normal, nici nu am avea nevoie de alte threaduri, fiindca programul poate executa tot ce are de executat din threadul principal. Totusi, cu toata viteza calculatoarelor de ultima generatie, in momentul in care executam o bucla cu zeci de mii de cicluri (sau mai mult), ne putem trezi cu aplicatia "blocata" - nu mai raspunde la tastatura si mouse, nu-si mai face update-urile vizuale sau Windows ii va adauga in titlu faimosul "Not responding". Vi se pare familiara imaginea de mai jos ?
Putem imbunatati situatia asta prin a spune programului sa proceseze mesajele primite, o data la cateva cicluri, dar asta va incetini operatia (calculele noastre), iar interfata oricum se va bloca daca procesarile nu sunt setate la intervale indeajuns de mici.
Solutia e simpla: lasi thread-ul principal sa-si faca procesarile in ritmul lui si lansezi un nou thread care sa faca "all the dirty work" in spate. Periodic, poti chiar "raporta" thread-ului principal de progresul operatiei pe care o executi. Vrei sa copiezi cativa GB de fisiere din programul tau ... sau sa calculezi PI cu 2000 de zecimale ? Probabil ca ar fi momentul sa afli ce sunt si cum se folosesc thread-urile.
Solutia e simpla: lasi thread-ul principal sa-si faca procesarile in ritmul lui si lansezi un nou thread care sa faca "all the dirty work" in spate. Periodic, poti chiar "raporta" thread-ului principal de progresul operatiei pe care o executi. Vrei sa copiezi cativa GB de fisiere din programul tau ... sau sa calculezi PI cu 2000 de zecimale ? Probabil ca ar fi momentul sa afli ce sunt si cum se folosesc thread-urile.
Thread-uri in Delphi
Pentru a folosi un thread in aplicatie, ne trebuie un descendent de-al clasei TThread. Desi e destul de simpla crearea manuala a unei clase descendenta din TThread, putem folosi si pasii urmatori:
(File / New / Other / Thread Object)
Dupa introducerea numelui pentru noul thread, va va aparea un nou unit (in proiectul deschis) care va contine urmatoarele linii (clasa mea de thread a primit numele "TDarkThread", iar unitul a fost salvat cu numele "uDarkThread"):
- unit uDarkThread;
- interface
- uses
- Classes;
- type
- TDarkThread = class(TThread)
- private
- { Private declarations }
- protected
- procedure Execute; override;
- end;
- implementation
- { Important: Methods and properties of objects in visual components can only be
- used in a method called using Synchronize, for example,
- Synchronize(UpdateCaption);
- and UpdateCaption could look like,
- procedure TDarkThread.UpdateCaption;
- begin
- Form1.Caption := 'Updated in a thread';
- end; }
- { TDarkThread }
- procedure TDarkThread.Execute;
- begin
- { Place thread code here }
- end;
- end.
Codul care trebuie executat in thread va trebui pus in procedura Execute.
Initializarea thread-ului
Daca avem nevoie sa initializam variabile folosite in thread, sau vrem sa pornim thread-ul cu anumiti parametri, trebuie sa ne definim metoda (constructorul) Create. Tot in constructor ne putem seta prioritatea implicita a thread-ului si daca thread-ul va fi distrus automat in momentul in care isi termina executia. Constructorii (oricarei clase) trebuie declarati in sectiunea "public" sau "published". Codul va arata in felul urmator:
- unit uDarkThread;
- ...
- public
- constructor Create(aLines: Integer; CreateSuspended: Boolean = True);
- end;
- ...
- constructor TDarkThread.Create(aLines: Integer; CreateSuspended: Boolean = True);
- begin
- inherited Create(CreateSuspended); // thread-ul va fi creat, dar nu va rula
- // pentru a-l rula, folosim "Resume" (sau "Execute")
- FreeOnTerminate := True; // thread-ul va fi distrus automat cand termina
- Priority := tpLower; // prioritatea thread-ului este cu doua puncte sub prioritatea normala
- NumLines := aLines; // initializam o variabila
- end;
- ...
La implementarea unei proceduri constructor, denumita de obicei "Create" (desi nu e limitata la acest nume), ar trebui sa fiti atent daca trebuie sau nu sa apelati constructor-ul parintelui, folosind linia:
- inherited;
Acest apel asigura faptul ca obiectul tocmai creat a fost instantiat corect din clasa parinte, chiar daca parintele este TObject (care nu face nimic in constructor), dar in anumite cazuri poate sa nu fie necesar. Dupa cum ati vazut in cod si in exemplu, apelul de inherited poate fi diferit, in functie de necesitati.
Prioritati pentru thread-uri |
|
|---|---|
Valoare | Prioritate |
tpIdle | Thread-ul se va executa doar cand sistemul nu este folosit (idle). Windows nu va intrerupe alte thread-uri pentru a executa acest thread. |
tpLowest | Prioritatea thread-ului este cu doua puncte sub normal. |
tpLower | Prioritatea thread-ului este cu un punct sub normal. |
tpNormal | Thread-ul are prioritate normala. |
tpHigher | Prioritatea thread-ului este cu un punct peste normal. |
tpHighest | Prioritatea thread-ului este cu doua puncte peste normal. |
tpTimeCritical | Thread-ul primeste cea mai mare prioritate. |
Executia thread-ului
Cum spuneam mai sus, Execute este metoda in care punem codul care-l vrem executat in thread. Intoarcerea din apelul lui Execute opreste thread-ul, apeleaza procedura asignata evenimentului (event handler) OnTerminate (daca exista una asignata). Execute ar trebui sa verifice periodic proprietatea Terminated (a thread-ului), pentru ca aceasta semnaleaza daca se doreste oprirea thread-ului din exterior. Daca aceasta proprietate este setata pe True, trebuie sa iesim din Execute - sau thread-ul poate cauza probleme la apelarea metodei Terminate.
Sincronizarea thread-ului cu thread-ul principal
Cum afisam progresul unui thread (indiferent de ce forma e acel progres) ? Daca thread-ul principal este responsabil cu interfata programului, inseamna ca thread-urile secundare trebuie sa comunice cu acest thread principal pentru update-uri vizuale. Dar ce se va intampla daca mai multe thread-uri incearca sa acceseze aceeasi variabila / componenta simultan ? Raspunsul e simplu: se vor crea conflicte care pot duce la crash-uri. Access violations, erori ciudate, tot pachetul.
Rezolvarea e putin mai complicata: toate metodele care acceseaza thread-ul principal (in orice fel) trebuie sa fie sincronizate. Mai pe inteles, daca apelam (in mod sincronizat !) o metoda din thread-ul principal din mai multe thread-uri simultan, accesul la acea metoda se va face secvential, in ordinea apelurilor si a prioritatii thread-urilor - in acest fel se evita conflictele de orice natura.
Pentru a sincroniza aceste apeluri inter-thread-uri, Delphi pune la dispozitie, prin intermediul clasei TThread, o metoda denumita Synchronize (deci clasa noastra derivata din TThread contine aceasta metoda !), care accepta un singur parametru - un nume de procedura. In acest fel, codul care face update de progres, de exemplu, poate fi mutat intr-o procedura care face doar acest lucru, fiind apelata prin Synchronize, ca si in exemplul de mai jos:
Procedura care updateaza interfata din thread se numeste "MyUpdateProgress" si nu va cauza niciun fel de probleme (daca este folosita sincronizat !).
Rezolvarea e putin mai complicata: toate metodele care acceseaza thread-ul principal (in orice fel) trebuie sa fie sincronizate. Mai pe inteles, daca apelam (in mod sincronizat !) o metoda din thread-ul principal din mai multe thread-uri simultan, accesul la acea metoda se va face secvential, in ordinea apelurilor si a prioritatii thread-urilor - in acest fel se evita conflictele de orice natura.
Pentru a sincroniza aceste apeluri inter-thread-uri, Delphi pune la dispozitie, prin intermediul clasei TThread, o metoda denumita Synchronize (deci clasa noastra derivata din TThread contine aceasta metoda !), care accepta un singur parametru - un nume de procedura. In acest fel, codul care face update de progres, de exemplu, poate fi mutat intr-o procedura care face doar acest lucru, fiind apelata prin Synchronize, ca si in exemplul de mai jos:
- Synchronize(MyUpdateProgress);
Procedura care updateaza interfata din thread se numeste "MyUpdateProgress" si nu va cauza niciun fel de probleme (daca este folosita sincronizat !).
Alte informatii despre thread-uri
Daca ati creat un thread suspendat (nu l-ati pornit), puteti accesa si modifica variabilele expuse in sectiunea "public". In acest fel, initializarile se pot face si fara a folosi noi parametri in constructor.
Un thread poate lansa in executie alte thread-uri. Sky is the limit (the available memory, to be more precise).
Program exemplu
Dupa ce-ati citit tot ce-am scris pe aici, cu siguranta ca ati vrea sa vedeti si un exemplu, asa ca m-am gandit sa fac un program-test care sa verifice daca un numar e prim, folosind un thread separat pentru fiecare numar introdus pentru verificare. Sa vedem putin cod.
Dupa cum se si observa, codul care verifica daca numarul NumberToCheck este prim este pus in procedura Execute, asa cum am explicat si mai sus. Pe langa codul efectiv de verificare, in procedura Execute exista doua lucruri in plus. Primul ar fi:
Sa presupunem ca userul care incearca programul introduce un numar imens (sa zicem, cateva miliarde). Pana se poate determina daca acest numar e prim sau nu, pot trece chiar minute intregi (in implementarea curenta
). Un buton care sa-i permita userului sa opreasca thread-ul ar fi binevenit, dar pentru ca un thread sa poata fi oprit fara probleme, el trebuie sa-si verifice periodic proprietatea Terminated. Aceasta proprietate este setata pe True in momentul in care se apeleaza procedura Terminate a thread-ului. E ca si cum ai calca frana masinii, dar dureaza ceva timp pana masina e intr-adevar oprita. E preferabil, totusi, ca intervalul din apelul procedurii Terminate si verificarea proprietatii Terminated sa fie cat mai mic, acesta fiind motivul pentru care verificarea proprietatii se face in fiecare ciclu al buclei de verificare a numarului.
A doua bucata de cod care atrage atentia este urmatoarea:
Asa cum am explicat mai sus, metodele care lucreaza cu date sau metode din alte thread-uri, trebuie sa fie sincronizate. Procedura mea, denumita UpdateResult, afiseaza intr-un TMemo daca numarul este prim sau nu, dar trebuie apelata in mod sincronizat, in eventualitatea ca un alt thread ar incerca sa faca acelasi lucru, in acelasi timp.
In forma actuala a acestui cod exista posibilitatea lansarii simultane a mai multor thread-uri (care sa verifice, fiecare, primalitatea unui numar) folosind o variabila locala din event handler-ul vreunui buton (din GUI). Cand un thread termina aceasta verificare si afiseaza rezultatul, el se va opri, iar memoria alocata lui va fi eliberata. Singura problema e ca, desi pot porni mai multe thread-uri, nu voi putea opri niciunul - va trebui sa astept pana se termina singure (sau sa opresc programul din Task Manager). This stinks, right ?
Ca sa ramanem cu posibilitatea de a lansa thread-uri multiple in executie, dar sa le putem opri cand dorim, va trebui sa ne creem un array de thread-uri. Fiindca nu vrem sa limitam potentialul de testare al programului, vom crea un array dinamic (ne va permite sa stocam oricate elemente, in limita memoriei sistemului). Codul urmator este ce ne trebuie:
Un contor de thread-uri (sa aflam repede si usor cate thread-uri stocam in orice moment dat) si array-ul in sine - acestea vor fi declarate ca variabile in thread-ul principal al programului - in clasa formei principale (in cazul de fata). Pentru a crea un thread nou, care sa verifice numarul dat, vom folosi ceva in genul urmator:
Din codul de mai sus se observa ca forma mea principala contine un TEdit (editbox) cu numele "edtNumber" si un buton denumit "btnCheck". In momentul apasarii butonului, se creeaza un thread nou (in array) pentru a verifica numarul din casuta text. In acest fel, putem opri oricare thread - sau toate, folosind o bucla - din cele din array-ul DarkThreads. O metoda care opreste toate thread-urile:
Dupa cum se vede, inca un buton si se opresc toate thread-urile. Simplu ca "multi-threading". Daca nu avem niciun thread lansat, afisam lucrul acesta - in caz contrar, trimitem tuturor thread-urilor decizia de a le "concedia".
Damn threads. Tocmai a aparut o problema. Ce se va intampla in cazul in care lansam in executie 10-15 thread-uri - le lasam sa-si termine treaba - si apoi dam click pe butonul de oprire al thread-urilor ?
Thread-urile sunt dealocate, iar ce a ramas in array-ul ala dinamic doar naiba mai stie. Ar fi frumos (si chiar politicos) ca fiecare thread sa anunte cand se termina pentru a-l putea sterge din array. Procedura de stergere din array e destul de simpla - ne bazam pe handle-ul thread-ului si mutam elementele din dreapta thread-ului terminat cu o pozitie mai in stanga.
Cum spuneam, e simplu. Tot ce mai trebuie e ca, atunci cand afisam rezultatele din thread, sa apelam si aceasta procedura intr-un apel sincronizat pentru a curata array-ul. Daca apelul acestea proceduri nu este sincronizat, array-ul va ... - sa spunem doar ca programul nu va muri de moarte buna decat cu ajutorul unei doze generoase de noroc chior
Pentru a nu va complica inutil, aplicatia completa (sursa si executabil) sunt atasate - 185 de linii de cod, din care jumatate (poate) sunt cod scris manual.
Un screenshot cu programul:
Un screenshot cu Task Manager-ul in timpul rularii programului:
Daca nu aveti (in Task Manager) coloana care afiseaza numarul de thread-uri din procese, folositi urmatorii pasi:
Note finale
- unit uDarkThread;
- interface
- uses
- Classes, Sysutils;
- type
- TDarkThread = class(TThread)
- private
- public
- NumberToCheck: int64;
- IsPrime: Boolean;
- procedure UpdateResult; // metoda sincronizata pentru afisarea rezultatului
- procedure Execute; override;
- constructor Create(aNumber: int64; CreateSuspended: Boolean = False);
- end;
- implementation
- uses uMainForm;
- constructor TDarkThread.Create(aNumber: int64; CreateSuspended: Boolean = False);
- begin
- inherited Create(CreateSuspended); // thread-ul va fi creat, dar nu va rula
- // pentru a-l rula, folosim "Resume" (sau "Execute")
- FreeOnTerminate := True; // thread-ul va fi distrus automat cand termina
- Priority := tpNormal; // prioritatea thread-ului este normala
- NumberToCheck := aNumber; // initializam o variabila
- end;
- procedure TDarkThread.Execute; // verificam daca numarul e prim
- var
- i, factors: int64;
- begin
- factors := 0;
- try
- IsPrime := True;
- // Vrem ca verificarea sa mearga cat mai incet,
- // pentru a se putea observa functionarea thread-urilor.
- // Din acest motiv, codul de mai jos nu este deloc optimizat.
- i := 2;
- while (NumberToCheck > i) do
- begin
- if (NumberToCheck mod i = 0) then
- begin
- Inc(factors);
- end;
- if Terminated then
- Exit;
- Inc(i);
- end;
- finally
- IsPrime := (factors = 0);
- Synchronize(UpdateResult);
- end;
- end;
- procedure TDarkThread.UpdateResult;
- begin
- // anuntam daca numarul verificat este prim sau nu,
- // daca thread-ul nu a fost terminat din exterior
- if not Terminated
- then
- if IsPrime
- then frmMain.MemoPrimes.Lines.Add(IntToStr(NumberToCheck) + ' is prime.')
- else frmMain.MemoPrimes.Lines.Add(IntToStr(NumberToCheck) + ' is NOT prime.')
- else frmMain.MemoPrimes.Lines.Add('Thread terminated (' + IntToStr(NumberToCheck) + ')');
- end;
- end.
Dupa cum se si observa, codul care verifica daca numarul NumberToCheck este prim este pus in procedura Execute, asa cum am explicat si mai sus. Pe langa codul efectiv de verificare, in procedura Execute exista doua lucruri in plus. Primul ar fi:
- if Terminated then
- Exit;
Sa presupunem ca userul care incearca programul introduce un numar imens (sa zicem, cateva miliarde). Pana se poate determina daca acest numar e prim sau nu, pot trece chiar minute intregi (in implementarea curenta
). Un buton care sa-i permita userului sa opreasca thread-ul ar fi binevenit, dar pentru ca un thread sa poata fi oprit fara probleme, el trebuie sa-si verifice periodic proprietatea Terminated. Aceasta proprietate este setata pe True in momentul in care se apeleaza procedura Terminate a thread-ului. E ca si cum ai calca frana masinii, dar dureaza ceva timp pana masina e intr-adevar oprita. E preferabil, totusi, ca intervalul din apelul procedurii Terminate si verificarea proprietatii Terminated sa fie cat mai mic, acesta fiind motivul pentru care verificarea proprietatii se face in fiecare ciclu al buclei de verificare a numarului.A doua bucata de cod care atrage atentia este urmatoarea:
- Synchronize(UpdateResult);
Asa cum am explicat mai sus, metodele care lucreaza cu date sau metode din alte thread-uri, trebuie sa fie sincronizate. Procedura mea, denumita UpdateResult, afiseaza intr-un TMemo daca numarul este prim sau nu, dar trebuie apelata in mod sincronizat, in eventualitatea ca un alt thread ar incerca sa faca acelasi lucru, in acelasi timp.
In forma actuala a acestui cod exista posibilitatea lansarii simultane a mai multor thread-uri (care sa verifice, fiecare, primalitatea unui numar) folosind o variabila locala din event handler-ul vreunui buton (din GUI). Cand un thread termina aceasta verificare si afiseaza rezultatul, el se va opri, iar memoria alocata lui va fi eliberata. Singura problema e ca, desi pot porni mai multe thread-uri, nu voi putea opri niciunul - va trebui sa astept pana se termina singure (sau sa opresc programul din Task Manager). This stinks, right ?
Ca sa ramanem cu posibilitatea de a lansa thread-uri multiple in executie, dar sa le putem opri cand dorim, va trebui sa ne creem un array de thread-uri. Fiindca nu vrem sa limitam potentialul de testare al programului, vom crea un array dinamic (ne va permite sa stocam oricate elemente, in limita memoriei sistemului). Codul urmator este ce ne trebuie:
- cntThreads: Integer;
- DarkThreads : array of TDarkThread;
Un contor de thread-uri (sa aflam repede si usor cate thread-uri stocam in orice moment dat) si array-ul in sine - acestea vor fi declarate ca variabile in thread-ul principal al programului - in clasa formei principale (in cazul de fata). Pentru a crea un thread nou, care sa verifice numarul dat, vom folosi ceva in genul urmator:
- procedure TfrmMain.btnCheckClick(Sender: TObject);
- begin
- Inc(cntThreads);
- SetLength(DarkThreads, cntThreads);
- DarkThreads[cntThreads - 1] := TDarkThread.Create(StrToInt64(edtNumber.Text));
- DarkThreads[cntThreads - 1].Resume;
- end;
Din codul de mai sus se observa ca forma mea principala contine un TEdit (editbox) cu numele "edtNumber" si un buton denumit "btnCheck". In momentul apasarii butonului, se creeaza un thread nou (in array) pentru a verifica numarul din casuta text. In acest fel, putem opri oricare thread - sau toate, folosind o bucla - din cele din array-ul DarkThreads. O metoda care opreste toate thread-urile:
- procedure TfrmMain.btnStopClick(Sender: TObject);
- var i: Integer;
- begin
- if (cntThreads > 1)
- then
- for i := 0 to cntThreads - 1 do
- DarkThreads[i].Terminate
- else memoPrimes.Lines.Add('No threads running.');
- end;
Dupa cum se vede, inca un buton si se opresc toate thread-urile. Simplu ca "multi-threading". Daca nu avem niciun thread lansat, afisam lucrul acesta - in caz contrar, trimitem tuturor thread-urilor decizia de a le "concedia".
Damn threads. Tocmai a aparut o problema. Ce se va intampla in cazul in care lansam in executie 10-15 thread-uri - le lasam sa-si termine treaba - si apoi dam click pe butonul de oprire al thread-urilor ?
Thread-urile sunt dealocate, iar ce a ramas in array-ul ala dinamic doar naiba mai stie. Ar fi frumos (si chiar politicos) ca fiecare thread sa anunte cand se termina pentru a-l putea sterge din array. Procedura de stergere din array e destul de simpla - ne bazam pe handle-ul thread-ului si mutam elementele din dreapta thread-ului terminat cu o pozitie mai in stanga.- procedure TfrmMain.DeleteThread(aHandle: THandle);
- var
- i, j: Integer;
- begin
- for i := 0 to cntThreads - 1 do // cautam thread-ul care trebuie sters din lista
- if (DarkThreads[i].Handle = aHandle) then
- Break;
- for j := i to cntThreads - 2 do // le mutam pe celelalte cu o pozitie in stanga
- DarkThreads[i] := DarkThreads[i + 1];
- Dec(cntThreads); // actualizam contorul de thread-uri
- SetLength(DarkThreads, cntThreads); // si lungimea array-ului
- end;
Cum spuneam, e simplu. Tot ce mai trebuie e ca, atunci cand afisam rezultatele din thread, sa apelam si aceasta procedura intr-un apel sincronizat pentru a curata array-ul. Daca apelul acestea proceduri nu este sincronizat, array-ul va ... - sa spunem doar ca programul nu va muri de moarte buna decat cu ajutorul unei doze generoase de noroc chior
Pentru a nu va complica inutil, aplicatia completa (sursa si executabil) sunt atasate - 185 de linii de cod, din care jumatate (poate) sunt cod scris manual.
Un screenshot cu programul:
Un screenshot cu Task Manager-ul in timpul rularii programului:
Daca nu aveti (in Task Manager) coloana care afiseaza numarul de thread-uri din procese, folositi urmatorii pasi:
Note finale
- Ar fi bine sa oprim toate thread-urile in momentul in care se incearca inchiderea programului (lucru implementat in aplicatia de mai jos).
- Testati programul incercand un numar mare (pentru care programul sa piarda cel putin 30 de secunde) si, imediat dupa, un numar mic. Veti vedea ca, desi numerele au fost date intr-o anumita ordine, rezultatele pot aparea si in alta ordine (datorata folosirii mai multor thread-uri).
