[drs:2007] - Re: za asistenta by "Radomir Jakovljević" <radegm@gmail.com>

Током 2.5.07., Sasa Vitorovic <savitor@sbb.co.yu> је написао:
> Pozdrav svima,
>
> 1)Nasao sam nesto sto vrlo lici na neki od prethodnim postova. Naime, u
> zbirci Ikodinovic/Jovanovic, zad3 g):
>
> Nigde se ne spominje wait(empty). Mi smo sigurni da imamo eksluzivan
> pristup
> ulazu u bafer, ali da li u njemu ima bilo sta? Moze da se desi da consumer
> uzme nesto iako Producer nije stavio nista u buffer.


Ne moze da se desi da citas iz praznog bafera ili da pises u pun bafer.
Semafor empty inicijalizujes sa n (broj praznih lokacija), a full sa 0 (jer
na pocetku imas prazan bafer). Svako wait(empty), koje poziva producer
smanjuje empty za 1, a svako wait(full), koje poziva Consumer, smanjuje full
za jedan.
Takodje svako signal(full), koje radi Producer posle ubacivanja el. u bafer,
povecava full za jedan. Isto vazi i za empty i Consumer-a.
Kada je neki od ovih semafora 0, odnosno kada nema elementa u baferu
(full==0) ili kada je bafer pun (empty==0), tada ce se u slucaju pozivanja
wait na semaforu koji je 0, dovesti do blokiranja pozivaoca. On ostaje
blokiran sve dok druga vrsta procesa ne pozove signal na tom semaforu.
Sve ovo gore znaci da u svakom trenutku vazi da broj elemenata u baferu
iznosi onoliko koliko je full, broj slobodnih mesta, onoliko koliko je
empty, a zbir full i empty je uvek n.

2)Kako bi H20 problem mogao da se resi na drugi nacin? Pominjali ste neku
> barijeru, ali evo sta sam ja nasao na netu:
>
> void hReady() {
>
> hPresent->V();
>
> waitForWater->P();
>
> }
>
> void oReady() {
>
> mutex->P()
>
> hPresent->P();
>
> hPresent->P();
>
> mutex->V();
>
> makeWater();
>
> waitForWater->V();
>
> waitForWater->V();
>
> }
>
> Cini se da je ovo resenje jednostavnije od naseg iz materijala, i pritom
> nista maje funkcionalno.
> Ispravite me ako gresim.


Ono resenje sa vezbi, je dosta komplikovano na prvi pogled. Kada se malo
udubis, postaje lakse :). Ja sam resenje shvatio kao dvostruku barijeru, gde
na prvoj barijeri vodonici cekaju jednog kiseonika da ih propusti. A na
drugoj se sacekuju sva tri atoma.

Znaci:
1) kiseonik radi sledece:
Postavi hydroSem na 2, sa dva poziva signal. Tako obezebedjuje da prva dva
vodonika koja cekaju na tom semaforu prodju dalje.
Semafor oxyMutex ima ociglednu ulogu da obezbedi ekskluzivan pristup jednom
kiseoniku, barijeri. Ostali O ce da cekaju dok on ne napravi svoj molekul.

2) vodonik radi sledece:
Ceka da dodje kiseonik i da uveca hydroSem, onda on prolazi tu barijeru i
umanjuje taj semafor za jedan sa wait. Ostala (nabudzena) logika procesa
vodonika sluzi da se saceka drugi vodonik. Tu postoji deljeni brojac atoma
vodonika, koji se uveca, pa se proveri da li je 2, ako jeste onda smo mi
drugi vodonik koji je dosao i odradjujemo propustanje O i 2 H (nas i drugog
vodonika) preko zajednicke barijere (mislim da je bilo signal(oxySem) i
2*signal(hydroSem2)). Ako nije count==2, onda se samo ceka da dodje drugi na
semaforu hydroSem2.

Ovo resenje koje si nasao na netu ima "kontra" logiku. Kiseonik ceka na dva
vodonika. Vodonici cekaju na kiseonik. Ovo resenje je lakse za razumevanje,
ali mi se cini da ne obezbedjuje da prva 2 vodonika koja dodju na barijeru i
budu u molekulu, jer moze vise atoma H, cekati da dodje O.

3)ChildCare Problem, zad 10 iz materijala.
> "for i := 0 to out do"
>     u bring BackChildren metodi
> Zar ne bi trebalo da ide od 1?


da treba. Takodje, mislim da treba: out : = numNann - (numChild + 2) / C,
umesto out : = numNann + (numChild + 2) / C;

if ((numChild + num)
>      u nannExit
> Zar ne bi trebalo bez "+num"?


Da, treba bez num.

Pozdrav,
Rade