Bine, acum să încerc să fac un rezumat la ceea ce am înțeles: - thread-ul care face so_init ar trebui să se afle în coada noastră cu priorități - nu se asigură nicicum că so_end va fi făcut după ce toate thread-urile își vor încheia execuția așadar trebuie să ne asigurăm noi că acest lucru se întâmplă în so_end(rulând cu helgrind am văzut că se poate face so_end în timp ce mai sunt thread-uri care folosesc acele structuri de date și apare segfault) - în cadrul thread_start din enunț trebuie să ne asigurăm că thread-urile își apelează handler-ul în ordinea din coada cu priorități iar după apelarea acestuia ele trebuie să se scoată singure din coadă sau pentru a apela pthread_join() în so_end ar trebui să le punem la finalul cozii și să lăsăm eliberarea doar thread-ului care face so_init
În joi, 2 mai 2019 la 11:42, Mihai Barbulescu <b12mi...@gmail.com> a scris: > On Wed, 1 May 2019 at 19:31, Ionuț Mihalache via so > <so@cursuri.cs.pub.ro> wrote: > > > > Și încă o întrebare pe care am uitat să o adresez: Cum să fac debug > pentru că dacă folosesc printf pot apărea sincronizări nedorite? > > Sugestia 1 (profesionista): logging intr-o zona din RAM/memoria > procesului mapata dinainte in procesul tau numit "scheduler" in care > threadurile scriu. Apoi ai alt proces care colecteaza aceste loguri. O > scriere in RAM tot o sa te coste deci poti avea desincronizari. Cele > doua procese impart un /dev/shm. > Sugestia 2 (cea mai la indemana pt voi): > http://valgrind.org/docs/manual/hg-manual.html > > GDB nu poate fi folosit prea reliable pentru ca asa cum printf strica > sincronizarile ghici ce-ar face un breakpoint :) > > -- > Cu stimă, > Mihai Bărbulescu >
_______________________________________________ http://ocw.cs.pub.ro/courses/so/info/lista-discutii
