Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.

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

[es] :: .NET :: Keširanje event u invocator-u - zašto?

[ Pregleda: 2009 | Odgovora: 8 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

lukeguy
Novi Sad

Član broj: 46545
Poruke: 470
212.200.231.*



+8 Profil

icon Keširanje event u invocator-u - zašto?08.05.2010. u 10:37 - pre 169 meseci
Do sada sam često nailazio na ovakav kod:
Code (csharp):
public event EventHandler<EventArgs> MyPropertyChanged;

private void InvokeMyPropertyChanged(EventArgs e)
        {
            var handler = MyPropertyChanged;
            if(handler != null)
            {
                handler(this, e);
            }
        }

private void SomeMethod(int value)
        {
            MyProperty = value;
            InvokeMyPropertyChanged(new EventArgs());
        }
 


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!
 
Odgovor na temu

ravni

Član broj: 8894
Poruke: 373



+15 Profil

icon Re: Keširanje event u invocator-u - zašto?08.05.2010. u 13:18 - pre 169 meseci
licno, nisam nikad video takav kod, a i nikakvog kesiranja tu nema
handler je lokalna promenljiva ako na nju mislis
 
Odgovor na temu

mmix
Miljan Mitrović
Profesorkin muz
Passau, Deutschland

SuperModerator
Član broj: 17944
Poruke: 6041



+4631 Profil

icon Re: Keširanje event u invocator-u - zašto?08.05.2010. u 13:50 - pre 169 meseci
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.
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ć
 
Odgovor na temu

lukeguy
Novi Sad

Član broj: 46545
Poruke: 470
*.dynamic.sbb.rs.



+8 Profil

icon Re: Keširanje event u invocator-u - zašto?08.05.2010. u 16:26 - pre 169 meseci
ok, tako sam i mislio, jedino nisam bio siguran da li je to jedini razlog. hvala na odgovoru!
 
Odgovor na temu

ravni

Član broj: 8894
Poruke: 373



+15 Profil

icon Re: Keširanje event u invocator-u - zašto?10.05.2010. u 22:16 - pre 169 meseci
to deluje pogresno... onda bi svaki properti morao da 'kesiras' :S
 
Odgovor na temu

mmix
Miljan Mitrović
Profesorkin muz
Passau, Deutschland

SuperModerator
Član broj: 17944
Poruke: 6041



+4631 Profil

icon Re: Keširanje event u invocator-u - zašto?10.05.2010. u 22:32 - pre 169 meseci
One koji su thread sensitive moras. Nije to pogresno, ovo je jos i najjednostavniji nacin da osiguras thread safety.
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ć
 
Odgovor na temu

Boris B.
Ljubljana

Član broj: 213615
Poruke: 286
*.dial-up.dsl.siol.net.



+14 Profil

icon Re: Keširanje event u invocator-u - zašto?11.05.2010. u 00:27 - pre 169 meseci
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.

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

mmix
Miljan Mitrović
Profesorkin muz
Passau, Deutschland

SuperModerator
Član broj: 17944
Poruke: 6041



+4631 Profil

icon Re: Keširanje event u invocator-u - zašto?11.05.2010. u 07:55 - pre 169 meseci
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."}


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ć
 
Odgovor na temu

Boris B.
Ljubljana

Član broj: 213615
Poruke: 286
*.evj-kabel.net.



+14 Profil

icon Re: Keširanje event u invocator-u - zašto?18.06.2011. u 19:38 - pre 155 meseci
Bajata tema, ali zanimljiva . Slučajno sam naleteo na ovaj blog post i setio se ove teme, pa rek'o da podelim:

http://blogs.msdn.com/b/ericli...09/04/29/events-and-races.aspx
if it walks like a duck and quacks like a duck, it could be a dragon doing a duck
impersonation.
 
Odgovor na temu

[es] :: .NET :: Keširanje event u invocator-u - zašto?

[ Pregleda: 2009 | Odgovora: 8 ] > FB > Twit

Postavi temu Odgovori

Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.