Salut, Am rezolvat. Nu tratam cazul când thread-ul își termina execuția de la sine. Astfel, thread-ul se termina, iar scheduler-ul nu era înștiințat ca să trează un alt thread și totul rămânea blocat.
Mulțumesc mult! 2018-05-13 11:42 GMT+03:00 Alexandru Militaru <[email protected] >: > Salut, > > După ce m-am atașat cu gdb la proces, am descoperit că thread-ul master > rulează for-ul respectiv (adică apelează so_fork() -uri) atât cât apucă > înainte ca thread-ul extern al checker-ului să apeleze so_end(). În > momentul în care thread-ul extern a apelat so_end(), începe să ruleze > funcția pthread_join *care îmi omoară instant, fără al lăsa să se > termine, *thread-ul master. De aici și numărul variabil de thread-uri > care sunt create la diferite apeluri: uneori thread-ul master apucă să > creeze mai multe, alteori mai puține. > > Este posibil să se întâmple așa ceva? Adică apelul pthread_join să îmi > omoare instant thread-ul, fără a îl lăsa să se termine? > > Menționez că apelez pthread_join într-un for. După primul apel de > pthread_join din for, primesc [Thread 0x7ffff75eb700 (LWP 6451) exited], > iar restul for-ului nu se mai execută. Apoi mi se spune despre thread-ul > care tocmai a ieșit că a primit semnalul SIGINT: Thread 1 "run_test" > received signal SIGINT, Interrupt. > > 2018-05-12 16:46 GMT+03:00 Razvan Crainea <[email protected]>: > >> >> >> On Sat, May 12, 2018 at 4:20 PM Alexandru Militaru via so < >> [email protected]> wrote: >> >>> Salut, >>> >>> Am următoarea problemă la testul 10: deși thread-ul master trebuie să >>> apeleze so_fork() de un număr random de ori, după un număr variabil de >>> apeluri ale funcției (diferă în funcției de rulare) el rămâne blocat. Am >>> verificat atent și thread-ul master nu este preemptat: nu îi expiră cuanta >>> și nici nu este dat la o parte de un proces mai prioritar. Pur și simplu >>> după un număr de apeluri se blochează. >>> >> >> În ce anume se blochează? >> >>> >>> Deși pare a fi deadlock, thread-ul master și celelalte thread-uri nu >>> interacționează cu niciun lock comun. Thread-urile worker așteaptă să >>> ruleze, în timp ce thread-ul master este singurul care lucrează. Cu toate >>> acestea, el se blochează la un moment dat și nu trece mai departe. Nu se >>> blochează în so_fork, se blochează după ce iese din această funcție. >>> >> >> Atașează-te cu gdb la thread-ul blocat și vezi în ce anume este blocat. >> Apoi, verifică cine mai lucrează cu acel loc și care sunt cazurile în care >> nu-l eliberează corect. >> >>> >>> >>> Care ar putea fi problema? >>> >>> Am încărcat codul pe gitlab. Userul meu este cmilitaru2501. >>> >> >> Numai bine, >> Răzvan >> > >
_______________________________________________ http://ocw.cs.pub.ro/courses/so/info/lista-discutii
