[drs:2007] - Re: materijali by "Sasa Vitorovic" <savitor@sbb.co.yu>

Pozdrav, 

Ono sto sam ja nasao je bio neki isecak nekog roka negde u americi. Da nadjes sve na jednom sajtu malo teze. Preporucio bih ti knjigu "Foundation of Multithread proggraming" i DVD sa mnogim korisnim stvarima koje mozes naci u 26ici.

Pozdrav,
       Sasa Vitorovic

  ----- Original Message ----- 
  From: Milos Ilic 
  To: drs@rti.etf.bg.ac.yu 
  Sent: Wednesday, May 02, 2007 5:32 PM
  Subject: Re: [drs] za asistenta


  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 


------------------------------------------------------------------------------


  -----------------------------------------------------------------
  unsubscribe:
     minimalist@rti.etf.bg.ac.yu?subject=unsubscribe%20drs
  -----------------------------------------------------------------