Salut, 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)
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) Ca P2 sa poata rula inainte trebuie sa rulez scheduler-ul inainte de deblocarea celor doua thread-uri. Mihai 2012/4/26 Irina Preșa <[email protected]> > On Thu, Apr 26, 2012 at 5:10 PM, Mihail Costea > <[email protected]> wrote: > > Salut, > > > > Consider ca testul 8 de pe Linux are un bug, care apare pentru procesul > cu > > prioritate 4 (P4) la rularea <so_signal(DEV1)>. > > Dupa cum am inteles eu enuntul, ordinea rularii proceselor pentru acest > caz > > e urmatoarea: > > > > - Main process forks and starts P2 > > - P2 waits DEV3, which doesn't exist > > - P2 forks and starts P4 > > - P4 waits DEV0 and blocks > > - P2 forks and starts P3 > > - P3 waits DEV0 and blocks > > - P2 forks and starts P1, but is preempted because total quantum time is > 1 > > - P1 signals DEV3, which doesn't exist > > - P2 exec and is preempted, because of quantum time > > - P1 exec > > - P2 exec and is preempted, because of quantum time > > - P1 signals DEV0 and awakes P3, P4 => we will have P2, P3, P4 in READY > > - P4 runs because it has the best priority and signals DEV1 => ERROR > > > > Eroarea apare fiindca P2 nu a ajuns sa dea wait pe DEV1, care era > urmatoarea > > comanda pe care trebuia sa o execute, dar P4 a luat-o inainte datorita > > prioritatii, > > si astfel ruleaza <so_fail("P4 should wake P2 (dev1)")>. > > > > Salut! > > Dacă un proces este preemptat din cauză că i-a expirat cuanta, nu > înseamnă că va fi blocat sau ceva de genul. Pur și simplu este > deplanificat și se reapelează schedulerul. Schedulerul va căuta apoi > să planifice următorul proces available cu cea mai mare prioritate. În > cazul de față, cum P3 și P4 sunt blocate, și cum nu mai există niciun > proces cu prioritatea 2, va fi replanificat tot P2. În exemplul de mai > sus, ai cel puțin 2 cazuri în care P2 este preemptat de P1, deoarece > lui P2 i-a expirat cuanta (P1 având prioritate mai mică). Practic, ar > trebui să fie replanificat tot P2. O să clarificăm și în enunț acest > caz. > > Ca un scurt reminder, atenție la cazul în care ai mai multe procese de > aceeași prioritate și nu mai există niciun proces READY cu prioritate > mai mare. De exemplu, să zicem că la un moment dat, ai următoarele > procese în starea READY (toate având _aceeași_ prioritate). > > [=p1=, p2, p3, p4] > > Procesele au fost salvate în ordinea în care au fost introduse în > sistem. Fie p1, procesul curent (care rulează acum pe CPU). Dacă lui > p1 îi expiră cuanta acesta va fi preemptat și, conform mecanismului > Round-Robin, ajunge să ruleze p2 (următorul proces available, cu cea > mai mare prioritate). > > => [p1, =p2=, p3, p4] > > -- > Irina > _______________________________________________ > http://elf.cs.pub.ro/so/wiki/resurse/lista-discutii
_______________________________________________ http://elf.cs.pub.ro/so/wiki/resurse/lista-discutii
