<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, May 2, 2016 at 6:33 PM Teodor Ciuraru via so <<a href="mailto:so@cursuri.cs.pub.ro">so@cursuri.cs.pub.ro</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Salut!<div><br></div><div>Nu am înțeles ciclul de viață al unui thread. Am următoarele nelămuriri:</div><div><br></div><div>1. Conform modelului de implementare, creez thread-ul, aștept să fie planificat (să intre în starea READY/RUN), îl planific în start_thread(), îî apelez handler-ul, anunț că a fost planificat și îi întorc id-ul?</div></div></blockquote><div>În afirmația de mai sus sunt două greșeli:</div><div>a. "<span style="line-height:1.5">aștept să fie planificat (să intre în starea READY/RUN)" nu este corect; doar thread-urile în starea RUN au fost planificate, un thread în starea READY urmează să fie planificat. Funcția so_fork() trebuie să se asigure că thread-ul a fost creat și să-i returneze ID-ul, chiar dacă nu a fost niciodată planificat.</span></div><div><span style="line-height:1.5">b. funcția start_thread() nu trebuie să anunțe pe nimeni dacă thread-ul a fost sau nu planificat.</span></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>2. La pasul 3 din modelul de implementare, funcția so_fork(), "să intre în starea READY/RUN”, o să poată intra în RUNNING vreodată, din moment ce va trebui să treacă întotdeauna prin READY și va trebui să declanșăm incheierea funcției sau va trebui ca atunci când planific un thread ar trebui să îl trec direct în RUNNING dacă are prioritate, sărind peste READY ca să nu se întâmple această problemă?</div></div></blockquote><div>Dacă conform algoritmului de planificare primul thread ar putea să ruleze imediat, atunci nu mai are sens să-l pui în starea READY, ci direct în RUNNING. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>3. În start_thread(), “așteaptă să fie planificat” înseamnă “planifică-l” sau trebuie să aștept după o condiție?</div></div></blockquote><div>Thread-ul trebuie să se blocheze până are dreptul să ruleze. Cum îl blochezi, depinde de implementarea ta; ideal ar fi printr-o variabilă de condiție. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>4. Pasul din start_thread(), “încheiere thread” se referă la sițuatia când thread-ul a ajuns să nu mai aibă instrucțiuni de executat?</div></div></blockquote><div>Da. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>5. Contorizând în fiecare funcție timpul virtual consumat de thread pe procesor, trebuie să verific în fiecare dintre acestea dacă i-a expirat cuanta sau pot creea cumva un mecanism de tip “trigger” când a depășit timpul maxim alocat?<br></div></div></blockquote><div><span style="line-height:1.5">Aici depinde din nou de implementarea ta: cred că este mai simplu să verifici dacă i-a expirat cuanta (sau cineva cu prioritate mai mare ar trebui să ruleze), decât să creezi mecanismul de "trigger". Dar, din nou, poți face cum vrei tu, important este ca thread-urile să ruleze corect dpdv al algoritmului de planificare.</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">Numai bine,</span></div><div><span style="line-height:1.5">Răzvan</span></div></div></div>