[drs:2007] - Re: za asistenta by "Milos Ilic" <milos.ilic@gmail.com>

Sasa, pominjao si da si resenje nasao na netu. Da li mozda ti ili neko od
kolega ima neku knjigu da preporuci i/ili eventualno ostavi neki link dobrog
sajta za DRS. Moze i torrent.
Hvala

Током 2.5.07., 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
>
>
> -----------------------------------------------------------------
> unsubscribe:
>   minimalist@rti.etf.bg.ac.yu?subject=unsubscribe%20drs
> -----------------------------------------------------------------


--
Budite pozdravljeni!
Milos