[so] [Tema4][Linux | Windows] Partea de preemptare

[Ionuț Mihalache]

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 <b12mihai at gmail.com> a scris:

> On Wed, 1 May 2019 at 19:31, Ionuț Mihalache via so
> <so at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cursuri.cs.pub.ro/pipermail/so/attachments/20190502/9a5df04b/attachment.html>