Keširanje event u invocator-u - zašto?

Do sada sam često nailazio na ovakav kod:


Ali nisam nigde našao objašnjenje zbog čega je dobra praksa da se kešira event handler u invocator metodi.

Da li je ovakav invocation thread-safe ili postoje neki drugi razlozi? Hvala!

licno, nisam nikad video takav kod, a i nikakvog kesiranja tu nema
handler je lokalna promenljiva ako na nju mislis

da, upravo zbog threadsafety. MyPropertyChanged moze da ode na null izmedju if i invoke i ne samo to nego moze da bude i collected, stavljanjem u handler promenljivu se osiguravas od te dve stvari, da handler ne moze biti null i da event handler (tj instanca koja ga sadrzi) nece biti collectovan dok se ne obavi poziv handlera.

Potpis

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ć

ok, tako sam i mislio, jedino nisam bio siguran da li je to jedini razlog. hvala na odgovoru!

to deluje pogresno... onda bi svaki properti morao da 'kesiras' :S

One koji su thread sensitive moras. Nije to pogresno, ovo je jos i najjednostavniji nacin da osiguras thread safety.

Potpis

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ć

Pa i nije neki thread safety moram da priznam :)

Ono sa cisto tehnicko-teorijske strane mozda i jeste, ali u praksi ako se je neki objekat odjavio sa event handlera znaci da ne zeli/ne predvidja vise da reaguje na taj event. IMHO u 99% slucajeva se posle odjave pokrene i neki teardown, npr oslobadjanje kesa, disconnect ili sl. Pokretanje hendlera "na silu" u tom trenutku bi bilo veoma pogresno, tj pojavljuju se problemi koje si upravo hteo tim "kesiranjem" reference da izbegnes, samo na drugom mestu.

Potpis

if it walks like a duck and quacks like a duck, it could be a dragon doing a duck
impersonation.

Pa najbolji je koji imas u tom trenutku za tu primenu, mada se slazem da bi to moglo da se pojaca kroz nacin na koji se instanciraju i odrzavaju Multicast delegati. KOntam da prvo mraju da se dese tone bagova sa novim paralelizmom da bi obratili paznju.

A pokretanje handlera "na silu" nije pogresno a znam i zasto mislis da je pogresno (i ja sam mislio svojevremeno), zato sto o tome razmisljas kao C++ programer, kroz immediate execution, dok CLR zapravo odlaze sve sto moze . Ja sam se doduse navikao na to jos kroz COM evente. To sto si se odjavio sa eventa ne znaci da si rekao da neces vise da primas pozive, vec da ne zelis da ih primas, zvuci slicno ali nije. U COMu npr je slicna prica, kad invoker poziva event sink prvo poziva njegov AddRef() da se osigura da event sink ne nestane u pola posla

Isto tako, ne smes da pretpostavis da ce tvoja instanca umreti onog trenutka kad tebi vise nije potrebna, sve i da nema vise zivih referenci GC moze da je odrzi u zivotu jos veoma veoma dugo (narocito ako je zavrsila u Gen2 na masini sa puno rama) a posebno sto je neko drugi u medjuvremenu mogao da uzme referencu (kao sto je ovde slucaj) pa GC ni ne moze da je pokupi. Teardown state-a o kome pricas da bi bio "koser" mora da se desi kroz disposable patern, i onda ni tu nema problema, samo kod u event handleru uokviris u if (!disposed) {...} i problem resen, kad pravis disposable klasu na to moras svejedno da racunas, na cinjenicu da public metode, interface metode i event hanlderi MOGU biti pozvani nakon Dispose(). Ti mozes da sredis svoju klasu koja ima handler, covek koji pravi klasu sa eventom ne moze da pretpostavi ko ce sve biti kacen na njegov event i kako i mora da se osigura da event ne pukne kod njega sa {"Object reference not set to an instance of an object."}

Potpis

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ć