<div class="gmail_extra">Salut,</div><div class="gmail_extra"><br></div><div class="gmail_extra">Deci in cazul de fata, chiar daca P1 a deblocat procesele P3 si P4 care asteptau la DEV0, voi apela schedeler-ul din P1 inainte ca P3 si P4 sa ajunga in READY ca P2 sa poata rula? (altfel nu are cum caci P4 are prioritate mai mare si i-o va lua in fata)</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Nu ar trebui ca P1 sa apeleze scheduler-ul dupa ce <signal> a fost rulat? (adica dupa ce P3 si P4 sunt deblocate si ajung in READY pentru ca scheduler-ul sa poata alege cel mai bun proces care trebuie rulat)</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Ca P2 sa poata rula inainte trebuie sa rulez scheduler-ul inainte de deblocarea celor doua thread-uri.</div><div class="gmail_extra"><br></div><div class="gmail_extra">
Mihai<br><br><div class="gmail_quote">2012/4/26 Irina Preșa <span dir="ltr"><<a href="mailto:irina.presa@gmail.com" target="_blank">irina.presa@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Thu, Apr 26, 2012 at 5:10 PM, Mihail Costea<br>
<<a href="mailto:mihail.costea90@gmail.com">mihail.costea90@gmail.com</a>> wrote:<br>
> Salut,<br>
><br>
> Consider ca testul 8 de pe Linux are un bug, care apare pentru procesul cu<br>
> prioritate 4 (P4) la rularea <so_signal(DEV1)>.<br>
> Dupa cum am inteles eu enuntul, ordinea rularii proceselor pentru acest caz<br>
> e urmatoarea:<br>
><br>
> - Main process forks and starts P2<br>
> - P2 waits DEV3, which doesn't exist<br>
> - P2 forks and starts P4<br>
> - P4 waits DEV0 and blocks<br>
> - P2 forks and starts P3<br>
> - P3 waits DEV0 and blocks<br>
> - P2 forks and starts P1, but is preempted because total quantum time is 1<br>
> - P1 signals DEV3, which doesn't exist<br>
> - P2 exec and is preempted, because of quantum time<br>
> - P1 exec<br>
> - P2 exec and is preempted, because of quantum time<br>
> - P1 signals DEV0 and awakes P3, P4 => we will have P2, P3, P4 in READY<br>
> - P4 runs because it has the best priority and signals DEV1 => ERROR<br>
><br>
> Eroarea apare fiindca P2 nu a ajuns sa dea wait pe DEV1, care era urmatoarea<br>
> comanda pe care trebuia sa o execute, dar P4 a luat-o inainte datorita<br>
> prioritatii,<br>
> si astfel ruleaza <so_fail("P4 should wake P2 (dev1)")>.<br>
><br>
<br>
</div></div>Salut!<br>
<br>
Dacă un proces este preemptat din cauză că i-a expirat cuanta, nu<br>
înseamnă că va fi blocat sau ceva de genul. Pur și simplu este<br>
deplanificat și se reapelează schedulerul. Schedulerul va căuta apoi<br>
să planifice următorul proces available cu cea mai mare prioritate. În<br>
cazul de față, cum P3 și P4 sunt blocate, și cum nu mai există niciun<br>
proces cu prioritatea 2, va fi replanificat tot P2. În exemplul de mai<br>
sus, ai cel puțin 2 cazuri în care P2 este preemptat de P1, deoarece<br>
lui P2 i-a expirat cuanta (P1 având prioritate mai mică). Practic, ar<br>
trebui să fie replanificat tot P2. O să clarificăm și în enunț acest<br>
caz.<br>
<br>
Ca un scurt reminder, atenție la cazul în care ai mai multe procese de<br>
aceeași prioritate și nu mai există niciun proces READY cu prioritate<br>
mai mare. De exemplu, să zicem că la un moment dat, ai următoarele<br>
procese în starea READY (toate având _aceeași_ prioritate).<br>
<br>
[=p1=, p2, p3, p4]<br>
<br>
Procesele au fost salvate în ordinea în care au fost introduse în<br>
sistem. Fie p1, procesul curent (care rulează acum pe CPU). Dacă lui<br>
p1 îi expiră cuanta acesta va fi preemptat și, conform mecanismului<br>
Round-Robin, ajunge să ruleze p2 (următorul proces available, cu cea<br>
mai mare prioritate).<br>
<br>
=> [p1, =p2=, p3, p4]<br>
<br>
--<br>
Irina<br>
_______________________________________________<br>
<a href="http://elf.cs.pub.ro/so/wiki/resurse/lista-discutii" target="_blank">http://elf.cs.pub.ro/so/wiki/resurse/lista-discutii</a></blockquote></div><br></div>