Nu mai contează. Noul checker a rezolvat problema asta.
În joi, 2 mai 2019 la 23:42, Ionuț Mihalache a scris:
> Numărul de thread-uri din acest test este foarte mare? helgrind îmi spune
> că anumite thread-uri dau failed la pthread_create() sau poate este de la
> mine. Ideea este că testul
On Thu, 18 Apr 2019 at 15:21, Elena Mihailescu
wrote:
>
> Salutare,
>
> A treia lucrare de curs va avea loc pe 22 si 24 aprilie 2019:
> * Luni, 22 aprilie, ora 17:00, sala PR001: Seria CA + alții
> * Miercuri, 24 aprilie, ora 11:00, sala PR001: Seria CB + alții
> * Miercuri, 24 aprilie, ora
Numărul de thread-uri din acest test este foarte mare? helgrind îmi spune
că anumite thread-uri dau failed la pthread_create() sau poate este de la
mine. Ideea este că testul durează foarte mult și am avut impresia că am
deadlock însă dacă îl las să ruleze apare eroarea asta "Thread #300's call
to
so_fork are un parametru care e prioritatea lui; noul thread va intra în
coada ready la prioritatea respectivă.
Fiecare thread are ca tranziții:
running->ready în so_exec și celelalte funcții care preemptează, când
expiră cuanta sau apare (în so_fork sau so_signal) un thread cu prioritate
mai
Multumesc frumos, asta explica multe!
De ce ar trebui sa avem un vector de cozi de prioritati? Dupa ce criteriu
stabilim pe ce coada de prioritati se duce un thread?
On Thursday, May 2, 2019, 7:46:26 PM GMT+3, Paul Olaru
wrote:
Looks like significant misunderstandings here.
1. Vezi 3;
Looks like significant misunderstandings here.
1. Vezi 3; ID-ul este dintr-un vector de cozi I/O.
2. Fiecare thread este ori running, ori ready (în coadă), ori blocked
(într-o coadă I/O). Fiecare funcție manipulează în general propriul thread,
cu excepția lui fork (care crează un thread nou) și
Salutare,
Din cauza problemelor de OOM aparute, am scos memcheck-urile pentru
testele de roundrobin (testul 15) si stress (testul 19). Propunerea
noastra este sa resubmiteti temele manual cei care sunteți nemulțumiți
de punctaje pe acele teste. Dacă vreți să facem noi un resubmit dați
reply la
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
On Wed, 1 May 2019 at 19:31, Ionuț Mihalache via so
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
On Wed, 1 May 2019 at 19:33, Paul Olaru via so wrote:
>
> cuda-gdb nu e prea rău, dar honestly aș face altceva: după ce s-a apelat
> kernelul și am dat toate cudaFree-urile etc copiez vectorii prin care
> implementez Hashtable-ul în sine și îl printez.
Cum folosesc cuda-gdb pe un PC cu AMD
Salut Ionut,
Raspund doar la acest email initial si inline, pentru ca in rest a
mers threadul pe ulei
On Wed, 1 May 2019 at 19:17, Ionuț Mihalache via so
wrote:
>
> Salut,
>
> După ceva timp în care am tot încercat diferite variante de implementare
> pentru a rezolva prima partea a testelor,
11 matches
Mail list logo
