Performance penalty je definitivno prisutan kod multi-threading aplikacija, tu nema nikakve sumnje, ali je sigurno bolji od pada aplikacije
Ok, sto se tice eventa, stvari uopste nisu tako jednostavne kao sto mislis, recimo nek imas deset threadova koji imaju pristup ovoj klasi:
1. Svih deset threadova mora da ima instancu klase koja ce pratiti ovaj objekat (Da bi odredjeeni metod tih objekata bio handler za event)
2. Ako jedan thread pozove set, taj set mora da "pozove" event i da u ukviru svog threada pozove svih deset event handlera, to povlaci za sobom potrebu da sve klase tih deset objekata budu multi-thread safe. I opet imas performance penalty da je thread koji menja promnljivu zakljucan dok ne pozove svih deset handlera
Svejedno moras da imas lock na get. Znam da to moze izgledati malo zbunjujuce zato sto je to prosto bool polje, ali resursi se stite u oba pravca bez obzira na velicinu. Razlog je sto moze da se desi da thread koji je u get ne uradi dobrovoljni release (kroz Sleep, process queue itd) i da bude prekinut nasilno i da se taj prekid obavi izmedju dve asemblerske instrukcije koje cine pristup zasticenom resursu, u tom slucaju je resurs u "nestabilnom" stanju i ako drugi thread obavi set dolazi do gadnih situacija. Iako je statisticka verovatnoca da se to desi mala, imajuci u obzir da prosecan PC vrti oko 500 threadova sa izmedju 5 i 20 hiljada promena threadova u sekundi, desava se
a bagovi koji su posledica ovoga su veoma nepredvidivi i veoma teski za lociranje i nemoguci za debagovanje. Jedini nacin da to radi apsolutno sigurno bez lock je da budes apsolutno siguran da ce JIT prevesti ono sto je u lock{} kao JEDNU I SAMO JEDNU asemblersku instrukciju, a to je nemoguce tvrditi sa nekom sigurnoscu
Ceo taj koncept sa eventima je veoma user-unfriendly
OnPropertyChange event model se koristi kad treba obavestiti drugi objekat da je doslo do premene u prvom ako je ta promena od vzanosti za drugi objekat (sto drugi objekat odlucuje time hoce li se zakaciti za event). Njegova potreba je bila da se promeni stanje istog objekta, praviti event i onda ga konzumirati u okviru istog objetka samo radi promene internog stanja, hmmm, nisam siguran ni da je to uopste moguce i ako jeste definitivno ne preporucujem.
Nemoj zazirati od lock-a
. Deset threadova koji su u WAIT_STATE za isti mutex objekat je savim ok i dok ovo citas desilo se bar nekoliko hiljada puta u tvom PC-u u samom OS-u ili u drugim programima
Vazno je samo da sadrzaj lock-a bude sto jednostavniji i da ne zavisi od drugih lockovanih resursa iz drugih klasa/objeakta da ne napravis deadlock situaciju za koju leka nema.
Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog
naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji
je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan,
sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv - Z.Đinđić
Eventi, delegati ili nešto treće?
Re: Eventi, delegati ili nešto treće?