[drs:2007] - Re: za asistenta by srdjan <tarzanka@gmail.com>

On 5/2/07, Sasa Vitorovic <savitor@sbb.co.yu> wrote:
> Pozdrav,
>
> Odgovori su dole.
>
> ----- Original Message -----
> From: Radomir Jakovljević
> To: drs@rti.etf.bg.ac.yu
> Sent: Wednesday, May 02, 2007 4:35 PM
> Subject: Re: [drs] za asistenta
>
>
>
>
> Током 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.
>
> u zadatku 3g) nigde nije definisan empty semafor!
>
>
>
>
>
> > 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.
>
>
> 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.
>
>
> Pazi sad sledecu situaciju. U zadatku iz materijala dodju 2 kiseionika do
> wait(oxyMutex). Zatim dodju 2 vodonika i oba se zaustave posle
> signal(hydroMutex),a pre wait*hydroSem2). treci vodonik koji naidje moze da
> prodje kroz barijeru. Dakle ni ivde nije ocuvan redosled.
> Zato sam i postavio pitanje da vidim dal ovo komplikovano resenje ima nekih
> prednosti.
>
>
> -----------------------------------------------------------------
> unsubscribe:
>    minimalist@rti.etf.bg.ac.yu?subject=unsubscribe%20drs
> -----------------------------------------------------------------
ni ja nesto ne vidim prednosti.
evo mog resenja koje sam budzio u javi i koje radi posao

Attachment: H20.rar
Description: audio/pn-realaudio-plugin