[so] [Tema4][Linux] Testul 8

[Mihail Costea]

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 <irina.presa at gmail.com>

> On Thu, Apr 26, 2012 at 5:10 PM, Mihail Costea
> <mihail.costea90 at gmail.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cursuri.cs.pub.ro/pipermail/so/attachments/20120426/e2ed3627/attachment.html>