[drs:2006] - Re: Monitori by "Ana Peric" <anaperic@gmail.com>

Pogledaj prvo predavanja iz monitora.
Videces da postoje 2 discipline Signal&Wait i Signal&Continue, koje se razlikuju, pa i kod koji pishes ce ti se razlikovati...

U cemu je fora... 

Kod SW, imas preempting, sto znaci da ako iz jedne mon. procedure uradis signal na nekom queue-u neka je to npr oktoread, proc. koji je uradio signal ide u entry queue, a iz condition queue-a na kome je izvrsen signal, prvi koji jr cekao "iskace" odmah u execution queue, i izvrsava se...

Kod s&c ti je drugacije, jer nije preemprive, vec onaj koji je iyvrsio signal pushta nekoga ko je na redu (obicno fifo) u cond. queue-u, ali u ENTRY queue, i naravno ta procedura, odradi svoje do kraja - ne prekida svoje izvrsavanje, a nemash garancije da ce ti odmah taj proces koji si sa signal "osobodio" doci bash sada na red da ode i odradi svoj posao u execution redu...

videces da je 2. zadatak RWR problem sa signal&continue...videces i razliku...

onako, kako su ove procedure u 1. zadatku napisane, stanje je sledece...

busy=true ukoliko neko pishe...
writer moze da uleti u izvrsavanje samo ukoliko neko drugi ne pise, i ukoliko niko ne cita.
ako to nije ispunjeno, writer cuci i ceka u oktowrite redu...
posto je disciplina SW, nema potrebe da za ispitivanje prom. rdcnt i busy stavimo u petlju, jer onog trenutka kada neka 2. procedura odradi signal, ovaj odmah ide u izvrsavanje, i niko ne moze u medjuvremenu da "poremeti" vrednosti rdcnt-a i busy-ja...

kada writer zavrsi svoj posao (u medjuvremenu su se mogli redjati neki readeri, writeri, i svi bi bili poslati u svoje cond. redove i tu cekali), writer ce da kaze "zavrsio sam" ovim busy=true,  i sada ybog neke pravednosti, nece dati prednost sledecem writeru, ukoliko ima nekog ridera koji je zeleo da cita, a ukucao se jer nije bilo zadoljeno 
!busy...
Ukoliko niko u medjuvremenu od citaca nije trazio citanje, pustice sledeceg pisaca da radi posao.

Sta radi reader kada hoce da cita...

ako ima pisaca trenutno, ili ako ima nekoga u redu za cekanje za pisanje, blokirace se na cond oktoread, i cekati da mu neko da signal,
ako ne, regularno povecava rdcnt, i posto je skapirao da niko ne pise, niti ceka da pise, sada ce se readeri "zaleteti", i jedni drugima davati signal...

jasno je da ukoliko u condition redu nema vise readera, oktoread.signal nema ama bash NIKAKVOG efekta...

sta se desava kada je reader zavrsio posao, i odlazi?

standardno dekrement rdcnt, i samo ukoliko je on bio poslednji koji je citao, reci ce "hajde sada writer koji je cekao moze da pocne da radi svoje".
Jasno je da ukoliko je bilo citaca koji citaju, svi pisaci su se slali da cekaju na oktowrite red (zbog rdcnt<>0)...

jasno li ti je nesto:) ?

eto, to je "ukratko" :)

a ja se odjavih sa liste...
I srecno svima...

BTW jedan hint...
Ukoliko zelite da ASISTENT procita mejl... STAVITE U SUBJECT "Za asistenta" - pa something something :), inace mislim da Zaki nece da odgovori, jer mu nije adresirano :) 
Niste ovo culi od mene :)) (shala :) )

eto...toliko od mene.

pozdrav,
Ana Peric

p.s. inace, jedina instr. koja budi SVE je signal_all... BUDITE "citaci" i teorije :)) hehe....
pps. ako sam negde omasila...neka me isprave...ali...:)

----- Original Message ----- 
From: "Branko Golubovic" <b.golubovic@sbb.co.yu>
To: <drs@rti.etf.bg.ac.yu>
Sent: Wednesday, September 13, 2006 11:32
Subject: [drs] Monitori


> 
> Jedno pitanje za asistenta (ili nekog ko je APSOLUTNO siguran u ono sto pise
> :)
> 
> Kod monitora u pascal-u, readers-writers problem, prvi zadatak sa vezbi,
> zanima me da li sam dobro shvatio... Prvo, procedura signal budi prvog ko je
> u redu cekanja za dati uslov (condition) ili budi sve koji su u redu (tipa
> broadcast) - koliko sam ja shvatio, budi prvog?
> 
> Ako budi samo prvog, i situacija je sledeca: imali smo jednog writer-a koji
> je pisao, u medjuvremenu se pojavio jos npr. jedan writer i nekoliko
> reader-a; writer zavrsava i budi prvog reader-a, koji zatim budi sledeceg
> reader-a, i tako dalje, sve dok ima reader-a u redu. Prvi put kada signal
> nema koga da probudi u redu za citanje, taj signal prakticno "propada" i tek
> tada prvi sledeci writer dobija sansu (naravno, kada i poslednji reader
> zavrsi sa citanjem); zato sto svaki sledeci reader koji naidje, mora da ceka
> jer je Oktowrite.queue == true, a vise nema ni jedan reader ispred da mu
> signalizira da prodje...
> 
> Da li je to tako ili sam negde pogresio sa pretpostavkama?
> 
> Unapred hvala! Pozdrav,
> Branko
> 
> 
> 
> -----------------------------------------------------------------
> unsubscribe:
>   minimalist@rti.etf.bg.ac.yu?subject=unsubscribe%20drs
> -----------------------------------------------------------------