[so] [Tema4][Linux] Testul 10

[Alexandru Militaru]

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 <alexandru.cmilitaru at gmail.com
>:

> 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 <razvan.crainea at gmail.com>:
>
>>
>>
>> On Sat, May 12, 2018 at 4:20 PM Alexandru Militaru via so <
>> so at cursuri.cs.pub.ro> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cursuri.cs.pub.ro/pipermail/so/attachments/20180513/97745419/attachment.html>