• Curs 08 - Fire de execuție (vizualizare Prezi)
• Curs 08 - Fire de execuție (PDF)

• Suport curs
  • Operating Systems Concepts
    • Capitolul 4 - Threads
  • Modern Operating Systems
    • Capitolul 2 - Processes and Threads
      • Secțiunea 2.2 - Threads
  • Beginning Linux Programming
    • Capitolul 12 - POSIX Threads
  • Windows System Programming
    • Capitolul 7 - Threads and Scheduling
    • Capitolul 8 - Thread Synchronization

Pentru parcurgerea demo-urilor, folosiți arhiva aferentă.

1. Overhead proces/thread
   • Deschideți directorul 0-overhead/.
   • Consultați fișierele process-overhead.c și thread-overhead.c.
   • Folosiți comanda make pentru a obține executabilele process-overhead și thread-overhead.
   • Rulați cele două executabile și contorizați statistici de rulare:

     /usr/bin/time -v ./process-overhead  > /dev/null
     /usr/bin/time -v ./thread-overhead  > /dev/null

     • Urmăriți diferențele din ieșirea celor două comenzi.
       • Urmăriți dimensiunea maximă a memoriei rezidente, numărul de page fault-uri, numărul de schimbări de context.
       • Explicați diferențele între ieșiri.
2. Partajarea informației între thread-uri
   • Deschideți directorul 1-process_thread/.
   • Consultați fișierele process.c și thread.c.
   • Se incrementează o variabilă globală dintr-un thread nou (thread.c) sau dintr-un proces nou (process.c).
   • Folosiți comanda make pentru a obține executabilele thread și process.
   • Rulați cele două executabile:

     ./thread
     ./process

     • Observați valoarea variabilei data_var, afișată prin rularea celor două executabile.
     • Observați că thread-urile partajează secțiunea de date a procesului, în vreme ce procesele au o zonă de date proprie.
3. Nevoie de acces exclusiv
   • Intrați în directorul 2-list/.
   • Consultați fișierele thread-list-app.c și list.c.
   • Ce impact are macro-ul USE_MUTEX?
   • Parcurgeți fișierul Makefile și urmăriți definirea macro-ului USE_MUTEX.
   • Folosiți comanda make pentru a obține executabilele thread-list-app și thread-list-app-mutex.
   • Rulați thread-list-app de mai multe ori, până obțineți eroare.
     • Dacă nu vă dă eroare, actualizați macro-urile NUM_THREADS și NUM_ROUNDS la alte valori (probabil mai mari), recompilați folosind make și apoi rulați thread-list-app.
   • Rulați thread-list-app-mutex de mai multe ori.
     • De ce nu vă dă eroare?
   • Rulați ambele executabile sub comanda time (e relevant timpul obținut pentru rulare cu succes):

     time ./thread-list-app
     time ./thread-list-app-mutex

     • Care timp este mai mare? De ce?
     • De ce timpul petrecut în kernel space (system time – sys în output-ul time) este mai mare în cazul folosirii thread-list-app-mutex?
4. Mutex vs. Spinlock – consum de timp
   • Intrați în directorul 3-spin/.
   • Consultați fișierul spin.c.
     • Urmăriți efectul macro-ului USE_SPINLOCK.
   • Consultați fișierul Makefile.
     • Observați unde este definit, ca opțiune de compilare, macro-ul USE_SPINLOCK.
   • Folosiți comanda make pentru a obține două executabile: spin și mutex.
   • Rulați cele două executabile prin comanda time pentru a contabiliza timpul de rulare:

     time ./spin
     time ./mutex

     • Care comandă a durat mai mult? De ce?
     • De ce comanda ./spin nu petrece foarte mult în kernel space (system time – sys în output-ul time)?
5. Granularitatea accesului exclusiv
   • Intrați în directorul 4-granularity/.
   • Consultați fișierul granularity.c.
   • Urmăriți macro-urile GRANULARITY_….
   • Compilați folosind comanda make; veți obține executabilul granularity.
   • Rulați executabilul și măsurați timpul de execuție:

     time ./granularity

   • Modificați macro-ul GRANULARITY_TYPE la valoarea GRANULARITY_COURSE.
   • Recompilați programul.
   • Rulați executabilul și măsurați, din nou, timpul de execuție:

     time ./granularity

   • Ce observați? Cum explicați diferența între timpi?
   • Care este avantajul și dezavantajul fiecărei soluții?