<div dir="ltr">Nu mai contează. Noul checker a rezolvat problema asta.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">În joi, 2 mai 2019 la 23:42, Ionuț Mihalache <<a href="mailto:ipopescu46@gmail.com">ipopescu46@gmail.com</a>> a scris:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">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 pthread_create failed with error code 11 (EAGAIN: Try again)". 300 nu este relevant, doar am ales una dintre erori.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">În sâm., 27 apr. 2019 la 20:21, Paul Olaru via so <<a href="mailto:so@cursuri.cs.pub.ro" target="_blank">so@cursuri.cs.pub.ro</a>> a scris:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Deci va trebui să fac join early, că join la final face Valgrind să consume mai mult de 1.5 GB de memorie și deci să-și ia OOM kill... Probabilistic.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Apr 27, 2019, 8:19 PM Razvan Crainea <<a href="mailto:razvan.crainea@gmail.com" target="_blank">razvan.crainea@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sat, Apr 27, 2019 at 6:25 PM Paul Olaru via so <<a href="mailto:so@cursuri.cs.pub.ro" rel="noreferrer" target="_blank">so@cursuri.cs.pub.ro</a>> wrote:<br>
><br>
> Îmi poate oferi cineva o idee prin care pot găsi motivul pentru care primesc mesajul de eroare „task was not preempted” la unele execuții? Sau ce să verific în codul meu? Test round robin.<br>
Eroarea "task was not preempted" o primești atunci când un task<br>
ruleaza mai mult decât cuanta maximă, și scheduler-ul tău nu îl<br>
preemptează ca să poată rula un alt thread cu aceeași prioritate.<br>
><br>
><br>
><br>
> Când ar trebui să se facă preempția în so_signal, cea cauzată de expirarea cuantei? Înainte sau după semnalizare? Similar pentru so_fork: înainte sau după lansarea threadului? [la mine oricum inițializarea structurilor noului thread se întâmplă sincron cu apelul so_fork].<br>
so_signal() este în sine o instrucțiune, care consumă timp pe<br>
procesor. Instrucțiunile sunt considerate atomice, astfel încât cuanta<br>
de timp este considerată expirată după ce întreaga instrucțiune s-a<br>
executat. Așadar, preempția în so_signal() ar trebui să se facă după<br>
semnalizare. La fel și la so_fork, preempția se face după terminarea<br>
inițializării, dar înainte de a rula handler-ul.<br>
><br>
><br>
><br>
> (bănuiesc că nu ar trebui să-mi încerc norocul pe VMchecker gen „tura asta merge”, dat fiind că problema apare la sub 10% din rulări).<br>
Nu, n-ar trebui să îți încerci norocul.<br>
><br>
><br>
><br>
> (în urma discuției din alt thread, mașina virtuală de SO are 1.5GB pe sistemul meu în loc de cei 512MB pe care îi are by default).<br>
Recomandăm să nu modifici mașina virtuală, altfel vei avea diferențe<br>
între rularea pe mașina ta virtuală și mașina de pe vmchecker.<br>
<br>
Numai bine,<br>
Răzvan<br>
</blockquote></div>
_______________________________________________<br>
<a href="http://ocw.cs.pub.ro/courses/so/info/lista-discutii" rel="noreferrer" target="_blank">http://ocw.cs.pub.ro/courses/so/info/lista-discutii</a></blockquote></div>
</blockquote></div>