• lab08-slides.pdf
• lab08-refcard.pdf

• TLPI - Chapter 29, Threads: Introduction
• TLPI - Chapter 30, Threads: Thread Synchronization
• TLPI - Chapter 31, Threads: Thread Safety and Per-Thread Storage

În laboratoarele anterioare a fost prezentat conceptul de proces, acesta fiind unitatea elementară de alocare a resurselor utilizatorilor. În cadrul acestui laborator este prezentat conceptul de fir de execuție (sau thread), acesta fiind unitatea elementară de planificare într-un sistem. Ca și procesele, firele de execuție reprezintă un mecanism prin care un calculator poate sǎ ruleze mai multe task-uri simultan.

Un fir de execuție există în cadrul unui proces, și reprezintă o unitate de execuție mai fină decât acesta. În momentul în care un proces este creat, în cadrul lui există un singur fir de execuție, care execută programul secvențial. Acest fir poate la rândul lui sǎ creeze alte fire de execuție; aceste fire vor rula porțiuni ale binarului asociat cu procesul curent, posibil aceleași cu firul inițial (care le-a creat).

• procesele nu partajează resurse între ele (decât dacă programatorul folosește un mecanism special pentru asta - shared memory spre exemplu), pe când firele de execuție partajează în mod implicit majoritatea resurselor unui proces. Modificarea unei astfel de resurse dintr-un fir este vizibilă instantaneu și din celelalte fire:
  • segmentele de memorie precum .heap, .data și .bss (deci și variabilele stocate în ele)
  • descriptorii de fișiere (așadar, închiderea unui fișier este vizibilă imediat pentru toate firele de execuție), indiferent de tipul fișierului:
    • sockeți
    • fișiere normale
    • pipe-uri
    • fișiere ce reprezintă dispozitive hardware (de ex. /dev/sda1).
• fiecare fir are un context de execuție propriu, format din:
  • stivă
  • set de registre (deci și un contor de program - registrul (E)IP)

Procesele sunt folosite de SO pentru a grupa și aloca resurse, iar firele de execuție pentru a planifica execuția de cod care accesează (în mod partajat) aceste resurse.

Deoarece toate firele de execuție ale unui proces folosesc spațiul de adrese al procesului de care aparțin, folosirea lor are o serie de avantaje:

• crearea/distrugerea unui fir de execuție durează mai puțin decât crearea/distrugerea unui proces
• durata context switch-ului între firele de execuție aceluiași proces este foarte mică, întrucât nu e necesar să se “comute” și spațiul de adrese (pentru mai multe informații, căutați „TLB flush”)
• comunicarea între firele de execuție are un overhead mai mic (realizată prin modificarea unor zone de memorie din spațiul comun de adrese)

Firele de execuție se pot dovedi utile în multe situații, de exemplu, pentru a îmbunătăți timpul de răspuns al aplicațiilor cu interfețe grafice (GUI), unde prelucrările CPU-intensive se fac de obicei într-un fir de execuție diferit de cel care afișează interfața.

De asemenea, ele simplifică structura unui program și conduc la utilizarea unui număr mai mic de resurse (pentru că nu mai este nevoie de diversele forme de IPC pentru a comunica).

Din punctul de vedere al implementării, există 3 categorii de fire de execuție:

• Kernel Level Threads (KLT)
• User Level Threads (ULT)
• Fire de execuție hibride

În ceea ce privește firele de execuție, POSIX nu specifică dacă acestea trebuie implementate în user-space sau kernel-space. Linux le implementează în kernel-space, dar nu diferențiază firele de execuție de procese decât prin faptul că firele de execuție partajează spațiul de adresă (atât firele de execuție, cât și procesele, sunt un caz particular de “task”). Pentru folosirea firelor de execuție în Python trebuie să includem modulul threading.

Modulul threading expune clasa Thread. Astfel, un fir de execuție este creat prin instantierea clasei:

import threading
threading.Thread(group=None, target=None, name=None, args=(), kwargs={}, *, daemon=None)

• group - se foloseste la extinderea clasei Thread; se recomanda pastrarea valoarei None;
• target - functia care va fi apelata la rularea threadului;
• name - numele threadului; daca acesta nu este specificat, se va genera un nume de formaThread-N, unde e un numar;
• args - lista de parametrii care va fi pasata functiei target; parametrii vor fi pasati in ordinea in care functia ii primeste;
• kwargs - dictionar care va stoca parametrii pasati functiei target, sub forma numele parametru-valoare;
• daemon - specifică dacă threadul este de tip daemon; dacă valoarea este None, proprietatea va fi moștenită de la threadul curent.

Noul fir creat poate fi lansat prin apelarea functiei start(). Acesta va executa codul specificat de funcția target căreia i se vor pasa argumentele din args sau kwargs.

Pentru a determina firului de execuție curent se poate folosi funcția current_thread:

import threading
threading.current_thread()

Firele de execuție se așteaptă folosind funcția join:

t = threading.Thread()
t.join(timeout=None)

Odata ce un thread a facut join pe un altul, acesta se va bloca pana threadul pe care s-a facut join isi va incheia executia. Daca threadul pe care s-a facut join va arunca o exceptie de tipul excepthook va fi aruncata in threadul care a facut join.

Un thread de tip daemon are drept scop procesarea unor operații fară a impacta firul de execuție principal.

Proprietatea principală a acestor threaduri este că programul principal își va încheia execuția dacă rămân doar threaduri de acest tip.

Un fir de execuție își încheie execuția în mod automat, la sfârșitul codului firului de execuție.

Pentru a schimba informații între programul principal si alte threaduri, vom folosi modulul queue. Folosind acest modul, putem implementa o coadă în care vom plasa mesajele din partea firelor de execuție.

Modululul suportă crearea a 6 tipuri diferite de cozi:

• Queue - coadă de tip FIFO, primul element inserat în coadă va fi primul extras;
• LifoQueue - ultimul element inserat în coadă va fi primul extras;
• PriorityQueue - Fiecare element are o prioritate, pe baza căreia se alege care element va fi cel extras;
• SimpleQueue - coadă de tip FIFO cu funcționalități limitate;
• Empty - se aruncă o excepție dacă se încearcă extragerea unui element când coada e goală;
• Full - se aruncă o excepție dacă se încearcă adăugarea unui element când coada e plină.

Pentru a crea o coadă, trebuie să instanțiem una din clasele expuse de modulul queue:

import queue
 
fifo_queue = queue.Queue()
lifo_queue = queue.LifoQueue()
priority_queue = queue.PriorityQueue()

Funcțiile put și put_nowait adaugă elemente în coadă.

q.put (item, block=True, timeout=None)
q.put_nowait (item)

Funcțiile get și get_nowait extrag elemente în coadă.

q.get (block=True, timeout=None)
q.get_nowait ()

Dacă coada este goală la apelarea uneia din cele două funcții, o excepție de tipul Empty este generată.

Mai jos vom crea un program care generează un thread ce primește valori de la programul principal și răspunde la aceastea.

import queue
import threading
 
def worker ():
    while True:
        item = q1.get()
        if item == 'Hello':
            print (item)
            q2.put ('SDE')
        elif item == 'Good':
            print (item)
            q2.put ('bye')
        else:
            break
 
q1 = queue.Queue()
q2 = queue.Queue()
 
t = threading.Thread (target=worker)
t.start ()
 
q1.put ('Hello')
print (q2.get ())
 
q1.put ('Good')
print (q2.get ())
 
q1.put ('exit')
 
t.join()

Uneori este util ca o variabilă să fie specifică unui fir de execuție (invizibilă pentru celelalte fire). Linux permite memorarea de perechi (cheie, valoare) într-o zonă special desemnată din stiva fiecărui fir de execuție al procesului curent. Cheia are același rol pe care îl are numele unei variabile: desemnează locația de memorie la care se află valoarea.

Fiecare fir de execuție va avea propria copie a unei “variabile” corespunzătoare unei chei k, pe care o poate modifica, fără ca acest lucru să fie observat de celelalte fire, sau să necesite sincronizare. De aceea, TSD este folosită uneori pentru a optimiza operațiile care necesită multă sincronizare între fire de execuție: fiecare fir calculează informația specifică, și există un singur pas de sincronizare la sfârșit, necesar pentru reunirea rezultatelor tuturor firelor de execuție.

Pentru a crea o variabila specifică threadului, se folosește clasa local a modulului threading.

import threading
 
local_data = threading.local()
local_data.my_var = 'SDE'

• Detalii desfășurare joc.

Pentru rezolvarea laboratorului, va rugam sa clonati repository-ul. daca il aveti deja, va rugam sa rulati git pull.

sudo apt-get install manpages-posix manpages-posix-dev

Intrați în directorul 1-th_stack și inspectați sursa, apoi compilați și rulați programul. Urmăriți cu pmap sau folosind procfs cum se modifică spațiul de adresă al programului:

watch -d pmap $(pidof th_stack)
watch -d cat /proc/$(pidof th_stack)/maps

Zonele de memorie cu dimensiunea de 8MB (8192KB) care se creează după fiecare apel pthread_create reprezintă noile stive alocate de către biblioteca libpthread pentru fiecare thread în parte. Observați că, în plus, se mai mapează de fiecare dată o pagină (4KB) cu protecția ---p (PROT_NONE, private - vizibil în procfs) care are rolul de "pagină de gardă".

Motivul pentru care nu se termină programul este prezența unui ​while(1)​ în funcția thread-urilor. Folosiți Ctrl+C pentru a termina programul.

Intrați în directorul 2-th_vs_proc și inspectați sursele. Ambele programe simulează un server care creează fire de execuție/procese. Compilați și rulați pe rând ambele programe.

În timp ce rulează, afișați, într-o altă consolă, câte fire de execuție/procese sunt create în ambele situații folosind comanda ps -L -C <nume_program>.

ps -L -C threads
ps -L -C processes

Verificați ce se întâmplă dacă la un moment dat un fir de execuție moare (sau un proces, în funcție de ce executabil testați). Testați utilizând funcția do_bad_task la fiecare al 4-lea fir de execuție/process.

Intrați în directorul 3-safety și inspectați sursa malloc.c. Funcțiile thread_function și main NU sunt thread-safe relativ la variabilele global_storage și function_global_storage (revedeți semnificația lui thread safety). Există o condiție de cursă între cele două thread-uri create la incrementarea variabilei function_global_storage, declarată în funcția thread_function, și o altă condiție de cursă între toate thread-urile procesului la incrementarea variabilei globale global_storage.

valgrind --tool=helgrind ./mutex

TODO 1: Pentru a rezolva aceste doua conditii de cursa apelati functia increase_numbers intr-un mod thread_safe cu ajutor API-ului pus la dispozitie de critical.h

În fișierul malloc.c se creează NUM_THREADS thread-uri care alocă memorie în 1000 runde. Sunt șanse mari ca thread-urile să execute apeluri malloc concurente. După ce a-ti rezolvat TODO1, compilati și rulati de mai multe ori. Observăm că programul rulează cu succes. Pentru a face verificări suplimentare, rulăm din nou helgrind:

valgrind --tool=helgrind ./mutex

Observăm că nici helgrind nu raportează vreo eroare, lucru care conduce la faptul că funcția malloc ar fi thread-safe. (chiar daca acesta nu este protejat de API-ul pus la dispozitie) Pentru a putea fi siguri trebuie să consultăm paginile de manual și codul sursă.

TODO 2: Implementati un spinlock folosindu-va de operatii atomice. Operatiile atomice existente in standardul GCC le gasiti la __atomic functions

In fisierul critical.c trebuie sa completati in dreptul comentarilor asociate TODO 2, avand la dispozitie hint-uri.

Testati si rulati de mai multe ori, pentru a verifica consistenta variabilei globale: global_storage, executabilul ./spin.

Inspectați fișierul blocked.c din directorul 4-blocked, compilați și executați binarul (repetați până detectați blocarea programului). Programul creează două fire de execuție care caută un număr magic, fiecare în intervalul propriu (nu este neapărat necesar ca numărul să fie găsit). Fiecare fir de execuție, pentru fiecare valoare din intervalul propriu, verifică dacă este valoarea căutată:

• dacă da, marchează un câmp found pentru a înștiința și celălalt fir de execuție că a găsit numărul căutat.
• dacă nu, inspectează câmpul found al structurii celuilalt fir de execuție, pentru a vedea dacă acesta a găsit deja numărul căutat.

Determinați cauza blocării, reparați programul și explicați soluția. Puteți utiliza helgrind, unul din tool-urile valgrind, pentru a detecta problema:

$ valgrind --tool=helgrind ./blocked

Aveți o funcție de inițializare pe care vreți să o apelați o singură dată. Pornind de la sursa once.c din directorul 5-once, asigurați-vă că funcția init_func este apelată o singură dată. Nu aveți voie să modificați funcția init_func sau să folosiţi pthread_once.

Citiți despre funcționalitatea pthread_once și revedeți secțiunea despre mutex.

Dorim să testăm care varianta este mai eficientă pentru a proteja incrementarea unei variabile.

Intrați în directorul 6-spin, inspectați și compilați sursa spin.c. În urma compilării vor rezulta două executabile, unul care folosește un mutex pentru sincronizare, iar altul un spinlock.

Comparați timpii de execuție:

time ./mutex
time ./spin

LinuxTutorialPosixThreads

POSIX Threads Programming