WeakReference

[Peter Morris [Droopy eyes software]]

Hi all

Is there any way I can get a notification of when a weak reference is about
to die so that I can decide to keep hold of it for a bit longer?

My scenario is that my framework loads in Stock objects on demand and then
caches them using a WeakReference. These Stock instances are used a lot of
the time in my app so I'd like them to live a while longer. However it is
impossible to know exactly which instances will be used regularly until
runtime, the user may use one once during the day and then not at all for
the rest of it or they may use the same one over and over.

So what I'd like to do is to have my WeakReference for Stock die X minutes
after the last time it was used. In otherwords I want a notification when
it is about to disappear so that I can prolong it for some additional time.


Any ideas?

Thanks

Pete

 

[Peter Morris [Droopy eyes software]]

A small test reveals that I should specify the constructor with the 2nd
parameter (TrackResurrection = true) and then call
GC.ReRegisterForFinalization(this) in the object destructor. Excellent

 

[Peter Morris [Droopy eyes software]]

http://blogs.slcdug.org/petermorris/archive/2006/04/30/3935.aspx

A small amount of information regarding my experiences of WeakReferences

 

[Daniel Moth]

Well at least the documentation is not misleading
(http://msdn.microsoft.com/library/d...frlrfsystemweakreferenceclassisalivetopic.asp):
"Gets an *indication* whether the object referenced [...]"

Also the property is useful when it returns false:
http://blogs.msdn.com/clyon/archive/2006/04/20/580255.aspx

BTW, your comments are broken.

Cheers
Daniel

 

[Peter Morris [Droopy eyes software]]

Hi Daniel

Well at least the documentation is not misleading
(http://msdn.microsoft.com/library/d...frlrfsystemweakreferenceclassisalivetopic.asp):
"Gets an *indication* whether the object referenced [...]"

That's an implicit explanation of the behaviour, it needs to be more
explicit. Sure it "!indicates" that the object is still referenced, but
what it doesn't say is that it might not be in a minute. I'd say IsAlive is
only any good for checking if the referene is not alive, but that is easily
checked via Target anyway. There really should be an example on the
WeakReference class, and I honestly believe IsAlive should be dropped.

Also the property is useful when it returns false:
http://blogs.msdn.com/clyon/archive/2006/04/20/580255.aspx

I only look at the class/member help, I think that having vital information
scattered around in blogs etc it no use at all. I wouldn't search MSDN for
problems with WeakReference until I had already encountered them (by which
point I have already wasted my time).

BTW, your comments are broken.

I disabled them because I was getting too much spam about Viagra etc. The
only way they are broken is that some how people are still sometimes able to
post



--
Pete
====
Audio compression components, DIB graphics controls, ECO extensions,
FastStrings
http://www.droopyeyes.com

My blog
http://blogs.slcdug.org/petermorris/

 

[Peter Morris [Droopy eyes software]]

PS. I don't quite understand the following line in the IsAlive help, would
you mind explaining it to me?

"An exception is thrown if the object referenced by this instance is
invalid. This can occur if there is an attempt to resurrect the referenced
object after it has been finalized."

Thanks for your time!



--
Pete
====

My blog
http://blogs.slcdug.org/petermorris/

 

[Guest]

If the object is fully Disposed and you call IsAlive you'll get an
exception, which is expected.

-Chris

 

[Guest]

I disagree. Why remove it? As a developer you must understand that when
you call any method, other threads continue to run. How about this?

if(myObject != null)
{
myObject.DoStuff();
}

This can still fail in a multithreaded environment because the object could
be set to null (or collected or whatever) after the check and before the
method call. Shouuld we remove the ability to set an object to null?

The situation is analogous. You have to understand the environment and how
all objects interact in a multithreaded environment. Your code should check
the IsAlive for the 99.9% of times it will work, then still use a try/catch
to handle the rare cases when it doesn't.

-Chris

Hi Daniel

Well at least the documentation is not misleading
(http://msdn.microsoft.com/library/d...frlrfsystemweakreferenceclassisalivetopic.asp):
"Gets an *indication* whether the object referenced [...]"

That's an implicit explanation of the behaviour, it needs to be more
explicit. Sure it "!indicates" that the object is still referenced, but
what it doesn't say is that it might not be in a minute. I'd say IsAlive
is only any good for checking if the referene is not alive, but that is
easily checked via Target anyway. There really should be an example on
the WeakReference class, and I honestly believe IsAlive should be dropped.

Also the property is useful when it returns false:
http://blogs.msdn.com/clyon/archive/2006/04/20/580255.aspx

I only look at the class/member help, I think that having vital
information scattered around in blogs etc it no use at all. I wouldn't
search MSDN for problems with WeakReference until I had already
encountered them (by which point I have already wasted my time).

BTW, your comments are broken.

I disabled them because I was getting too much spam about Viagra etc. The
only way they are broken is that some how people are still sometimes able
to post



--
Pete
====
Audio compression components, DIB graphics controls, ECO extensions,
FastStrings
http://www.droopyeyes.com

My blog
http://blogs.slcdug.org/petermorris/