I'm using Reactive Extensions for easy event handling in my ViewModels (Silverlight and/or Wp7 apps). For sake of simplicity let's say I have a line like this in the ctor of my VM:
Observable.FromEvent<PropertyChangedEventArgs>(
h => MyObject.PropertyChanged += h,
h => MyObject.PropertyChanged -= h)
.Where(e=>e.PropertyName == "Title")
.Throttle(TimeSpan.FromSeconds(0.5))
.Subscribe(e=>{/*do something*/});
this returns an IDisposable object, which if disposed will unsubscribe. (Am I right in this assumption?)
If I hold no reference to it, sooner or later it will be collected, and my handler will be unsubscribed.
I usually have a List<IDisposable> in my VM, and I add subscriptions to it, yet I feel dirty about it, as if I'm not doing something in a correct Rx way.
What is the best practice, recommended pattern on situations like this?
Your first assumption is correct, the IDisposable is for unsubscribing. However, you do not need to hold a reference to the IDisposable to prevent your observer from being collected. The IObservable will need to keep a reference to the observer to be able to call its methods, thus keeping the observer alive as long as the observable is alive.
The astute reader will realize that I am somewhat begging the question, because I have assumed that the observable will not be collected. To deal with that issue, let's make some reasonable guesses about what's going on behind the scenes. The first observable is subscribing to an event. This means that the object with the event has a reference to our observer from the time we subscribe to the time we unsubscribe. Since Rx operators must at some point subscribe to their sources, one can assume that the event observer has a reference to the Where observer, which has a reference to the Throttle observer, which of course is referring to our final observer.
Since we kept no way to unsubscribe, this ties the life of the observer to the life of the object with the event. Without full knowledge of your program, that is all the farther up the chain I can go, but I think it should be sufficient for you to determine the lifetime of the observable.
This actually points out a potential "memory leak" that you can have with standard .NET events, objects keeping all their event subscribers alive, which leads to your second question. If you do not keep a reference to the IDisposable, you will never be able to unsubscribe from the event and your object will continue to receive notices, even after you close the view it is related to. If the event source does not live longer than the view, this may not be a problem, but I recommend using the disposable.
There is nothing "un-Rx" about this, and Rx even includes a nice class to use as an alternative to the List if you want, System.Reactive.Disposables.CompositeDisposable.
Gideon is incorrect here. The semantics of how Rx use IDisposable are different than typical .NET. The IDisposable returned from Subscribe is if you want to unsubscribe earlier than the end of the IObservable. If you don't want to do this, complicating your code with all of the extra disposable management is unnecessary.
Common practice is to implement IDisposable interface and dispose your disposable members here.
Related
I'm trying to understand when is a good time to return a disposable in the function passed to Observable.Create vs just disposing any resources through scope by a using statement.
Is returning the disposable more for cases where the Observable is an infinite stream? Even if so I don't understand how the using block won't still dispose the resource even if the stream is closed prematurely
I think the Disposable interface on the Observable paradigm is used solely for the purpose of getting rid of the subscription (i.e, stopping the callback on the observed events), as Theodor Zoulias pointed out. It doesn't manage any resources on the stream whatsoever. You might be confusing the use of the Disposable interface on other scenarios.
As regards to disposing subscriptions:
One of the use cases I can see for returning a Disposable is when when you have more than one to call the function on: supposing you had a list of Observables, you could iterate on it and call the function .Dispose() to cancel multiple subscriptions at once.
You could also pass that stream as a disposable to another Observable, to be disposed when some event occurs. Since the entire RX paradigm is about not knowing when things will be executed, this is interesting. I worked at an application where I had to cancel a subscription if a certain event happened, and I passed the Observable Subscription (IDisposable) to the Observer of such event/stream.
Something on these lines:
IDisposable subscription1 = observableOne.Subscribe(_ => # code omitted);
observableTwo.Subscribe(_ => {
subscription1?.Dispose();
subscription1 = null;
});
As Enigmaticy has pointed out, although this exemplifies my point, a better way to accomplish this would be:
observableOne.TakeUntil(observableTwo).Subscribe(_ => #code ommited);
I haven't worked with C# in a while but these are the use cases I can see on using vs Disposable as object. It gives you greater flexibility on when you want to cancel your subscriptons :~
Thanks to everyone responding in this post it's helped me understand a bit better. I've had a lot of stumbling in my understanding of RX and I think a lot of this just comes down to limited documentation and seems like many people online don't quite understand perfectly either so there's a lot of misinformation to sort through.
This other answer does the trick for me
https://stackoverflow.com/a/7707768/7183974 .
What it really comes down to is for when we have non-blocking code in our Observable.Create method. So when our observable is subscribed to we instantly return a disposable that can clean up any asynchronous / concurrent processes in the event that we need to cancel a subscription early.
This is necessary for cases where maybe your observable is using other async (push-based) code.
For iterative (pull-based) code that you simply want to be push based then you can use Observable.Create but TBH I think just using an Iterator is better and if you need it to be a push-based API then just use ToObservable.
I was trying to implement a push-based iterator so the disposable seemed redundant to me which is what confused me. I've since refactored my code to be pull-based and if I ever were to need it to be push-based again I would just use ToObservable.
Recently I have come across an increasing number of people who have code similar to the following:
private AsynchronousReader r;
public SynchronousReader()
{
r = new AsynchronousReader();
// My practice is to put this here
// and then never remove it and never add it again
// thus cleaning up the code and preventing constant add/remove.
//r.ReadCompleted += this.ReadCompletedCallback;
}
private ReadCompletedCallback()
{
// Remove the callback to "clean things up"...
r.ReadCompleted -= this.ReadCompletedCallback;
// Do other things
}
public Read()
{
r.ReadCompleted += this.ReadCompletedCallback;
// This call completes asynchronously and later invokes the above event
r.ReadAsync();
r.WaitForCompletion();
}
Folks say that this practice is better than the one I indicated above and have given several reasons specific to Silverlight. They state it prevents memory leaks, threading issues, and even that it is the normal practice.
I have not done much Silverlight, but it seems silly to do this still.
Are there any specific reasons one would use this method instead of just rigging up the callback in the constructor once and for the lifetime of the object?
This is as simple as I could make my example. Ignore the fact that it's a sort of wrapper that turns an asynchronous object into a synchronous one. I'm only curious about the way events are added and removed.
In the case you mention it would make sense to hook it up once, but potentially the objects (parent and/or child) may not get garbage collected as the event handlers still reference them.
According to Marc Gavel here
i.e. if we have:
publisher.SomeEvent += target.SomeHandler;
then "publisher" will keep "target" alive, but "target" will not keep
"publisher" alive.
A more important point to bear in mind might be the lifespan of the child object. If it is the same as the parent, then one-off subscription in the constructor makes more sense. If it is dynamic you will likely want to remove the handlers as I have seen them leak (resulting in multiple callbacks).
Note: If the constructor-only method turns out to leak objects, you can always put an unsubscribe in the Dispose() I guess, but I can't say I have ever seen that.
It sounds like you have two issues:
You're attempting to reuse an object that really should only be used once.
That object needs to get properly cleaned up.
You should really either only use an instance of the SynchronousReader object only once (thus avoiding the two async calls racing with one failing to finish like you mentioned elsewhere) or you should implement IDisposable in order to unsubscribe from the event and prevent the memory leak.
A third solution might be possible: keep the single instance of SynchronousReader, but each call to SynchronousReader.Read would create a new instance of AsynchronousReader (rather than storing it as a private field within the instance). Then you could keep most of the code above which you don't like, but which properly handles event subscriptions.
I have a class that handles events from a WinForms control. Based on what the user is doing, I am deferencing one instance of the class and creating a new one to handle the same event. I need to unsubscribe the old instance from the event first - easy enough. I'd like to do this in a non-proprietary manner if possible, and it seems like this is a job for IDisposable. However, most documentation recommends IDisposable only when using unmanaged resources, which does not apply here.
If I implement IDisposable and unsubscribe from the event in Dispose(), am I perverting its intention? Should I instead provide an Unsubscribe() function and call that?
Edit: Here's some dummy code that kind of shows what I'm doing (using IDisposable). My actual implementation is related to some proprietary data binding (long story).
class EventListener : IDisposable
{
private TextBox m_textBox;
public EventListener(TextBox textBox)
{
m_textBox = textBox;
textBox.TextChanged += new EventHandler(textBox_TextChanged);
}
void textBox_TextChanged(object sender, EventArgs e)
{
// do something
}
public void Dispose()
{
m_textBox.TextChanged -= new EventHandler(textBox_TextChanged);
}
}
class MyClass
{
EventListener m_eventListener = null;
TextBox m_textBox = new TextBox();
void SetEventListener()
{
if (m_eventListener != null) m_eventListener.Dispose();
m_eventListener = new EventListener(m_textBox);
}
}
In the actual code, the "EventListener" class is more involved, and each instance is uniquely significant. I use these in a collection, and create/destroy them as the user clicks around.
Conclusion
I'm accepting gbjbaanb's answer, at least for now. I feel that the benefit of using a familiar interface outweighs any possible downside of using it where no unmanaged code is involved (how would a user of this object even know that?).
If anyone disagrees - please post/comment/edit. If a better argument can be made against IDisposable, then I'll change the accepted answer.
Yes, go for it. Although some people think IDisposable is implemented only for unmanaged resources, this is not the case - unmanaged resources just happens to be the biggest win, and most obvious reason to implement it. I think its acquired this idea because people couldn't think of any other reason to use it. Its not like a finaliser which is a performance problem and not easy for the GC to handle well.
Put any tidy-up code in your dispose method. It'll be clearer, cleaner and significantly more likely to prevent memory leaks and a damn sight easier to use correctly than trying to remember to un-do your references.
The intention of IDisposable is to make your code work better without you having to do lots of manual work. Use its power in your favour and get over some artificial "design intention" nonsense.
I remember it was difficult enough to persuade Microsoft of the usefulness of deterministic finalisation back when .NET first came out - we won the battle and persuaded them to add it (even if it was only a design pattern at the time), use it!
My personal vote would be to have an Unsubscribe method in order to remove the class from events. IDisposable is a pattern intended for deterministic release of unmanaged resources. In this case you not managing any unmanaged resources and therefore should not be implementing IDisposable.
IDisposable can be used to manage event subscriptions but probably shouldn't. For an example I point you to WPF. This is a library rife with events and event handlers. Yet virtually no class in WPF implements IDisposable. I would take that as an indication that events should be managed another way.
One thing that bothers me about using IDisposable pattern for unsubscribe from events is Finalization issue.
Dispose() function in IDisposable is supposed to be called by the developer, HOWEVER, if it isn't called by the developer, it is a understood that the GC will call this function (by the standard IDisposable pattern, at least). In your case, however, if you don't call Dispose no one else will - The event remains and the strong reference holds GC from calling the finalizer.
The mere fact that Dispose() won't be called automatically by GC seems to me enough to not to use IDisposable in this case. Perhaps it calls for a new application specific interface that says that this type of object must have a Cleanup function called to be disposed by GC.
I think disposable is for anything that GC can't take care of automatically, and event references count in my book. Here is a helper class I came up with.
public class DisposableEvent<T> : IDisposable
{
EventHandler<EventArgs<T>> Target { get; set; }
public T Args { get; set; }
bool fired = false;
public DisposableEvent(EventHandler<EventArgs<T>> target)
{
Target = target;
Target += new EventHandler<EventArgs<T>>(subscriber);
}
public bool Wait(int howLongSeconds)
{
DateTime start = DateTime.Now;
while (!fired && (DateTime.Now - start).TotalSeconds < howLongSeconds)
{
Thread.Sleep(100);
}
return fired;
}
void subscriber(object sender, EventArgs<T> e)
{
Args = e.Value;
fired = true;
}
public void Dispose()
{
Target -= subscriber;
Target = null;
}
}
which lets you write this code :
Class1 class1 = new Class1();
using (var x = new DisposableEvent<object>(class1.Test))
{
if (x.Wait(30))
{
var result = x.Args;
}
}
One side effect, you must not use the event keyword on your events, since that prevents passing them as a parameter to the helper constructor, however, that seems to not have any ill effects.
Another option would be to use weak delegates or something like WPFs weak events, instead of having to unsubscribe explicitly.
P.S. [OT] I consider the decision to only provide strong delegates the single most expensive design mistake of the .NET platform.
From all that i read about disposables i would argue that they were really mainly invented for solving one problem: freeing unmanaged system resources in a timely manner. But still all examples that i found are not only focussed on the topic of unmanaged resources, but also have another property in common:
Dispose is called just to speed up a process that otherwise would have occured later on automatically (GC -> finalizer -> dispose)
Calling a dispose method that unsubscribes from an event however would never occur automatically, even if you would add a finalizer that would call your dispose. (at least not as long as the event owning object exists - and if it would be called you wouldn't benefit from the unsubscription, since the event owning object would also be gone anyway)
So the main difference is that events somehow build an object graph that can't be collected, since the event handling object suddenly becomes referenced of the service that you just wanted to reference/use. You suddenly are forced to call Dispose - no automatic disposal is possible. Dispose would thereby get a subtle other meaning than that found in all examples where a Dispose call - in dirty theory ;) - isn't necessary, since it would get called automaically (at some time)...
Anyway.
Since the disposable pattern is something that already is pretty complicated (deals with finalizers that are hard to get right and many guidelines / contracts) and more importantly in most points has nothing to do with the event back referencing topic, i would say it would be easier to get that separeted in our heads by just not using that metaphor for something that could be called "unroot from object graph" / "stop" / "turn off".
What we want to achieve is to disable / stop some behaviour (by unsubscribing from an event).
It would be nice to have a standard interface like IStoppable with a Stop() method, that by contract is just focussed on
getting the object (+ all its own stoppables) disconnected from events of any objects that it didn't create by its own
so that it won't get called in implicit event style manner any longer (therefore can be perceived as stopped)
can be collected as soon any traditional references onto that object are gone
Let's call the only interface method that does the unsubscription "Stop()". You would know that the stopped object is in a acceptable state but only is stopped. Maybe a simple property "Stopped" would also be a nice to have.
It even would make sense to have an interface "IRestartable" that inherits from IStoppable and additionally has a method "Restart()" if you just want to pause a certain behaviour that certainly will be needed again in the future, or to store a deleted model object in a history for later undo recovery.
After all writing i have to confess to have just seen an example of IDisposable somewhere over here: http://msdn.microsoft.com/en-us/library/dd783449%28v=VS.100%29.aspx
But anyway until i get every detail and the original motivation of IObservable i would say it is not the best use case example
since again it is a pretty complicated system around it and we only have a small problem over here
and it might be that one of the motivations of that that whole new system is to get rid of events in the first place, which would result in a sort of stack overflow concerning th e original question
But it seems they are on some right track. Anyway: they should have used my interface "IStoppable" ;) since i strongly believe there is a difference in
Dispose: "you should call that method or something might leak if the GC happens to late" ....
and
Stop: "you have to call this method to stop a certain behaviour"
IDisposable is firmly about resources, and the source of enough problems to not muddy the waters further I think.
I'm voting for an Unsubscribe method on your own Interface too.
One option may be not to unsubscribe at all - just to change what the subscription means. If the event handler could be made smart enough to know what it's meant to do based on the context, you don't need to unsubscribe in the first place.
That may or may not be a good idea in your particular case - I don't think we've really got enough information - but it's worth considering.
No, you're not preventing the intention of IDisposable. IDisposable is intended as an all-purpose way to ensure that when you're done using an object, you can proactively clean up everything tied to that object. It doesn't have to be only unmanaged resources, it can include managed resources too. And an event subscription is just another managed resource!
A similar scenario that frequently arises in practice is that you will implement IDisposable on your type, purely in order to ensure you can call Dispose() on another managed object. This is not a perversion either, it is just tidy resource management!
I am well aware that finalizers are typically used to control unmanaged resources. Under what circumstances may a finalizer deal with managed ones?
My understanding is that presence in the finalizer queue will prevent any object, or objects strongly referenced thereby, from being collected, but it will not (of course) protect them from finalization. In the normal course of events, once an object is finalized it will be removed from the queue and any objects it references will no longer be protected from collection on the next GC pass. By the time a finalizer is called, the finalizers may have been called for any combination of objects referred to by the object; one cannot rely upon finalizers being called in any particular sequence, but the object references one holds should still be valid.
It's pretty clear that a finalizer must never acquire locks, nor attempt to create a new object. Suppose, however, that I have an object that subscribes to some events, and another object which actually uses the events. If the latter object becomes eligible for garbage collection I want to have the former object unsubscribe from events as soon as practical. Note that the former object will never become eligible for finalization until no subscriptions for it are held by any live object.
Would it be practical to have a lock-free linked-list stack or queue of objects which needed to be unsubscribed, and have the main object's finalizer put a reference to the other object on the stack/queue? The linked-list item object would have to be allocated when the main object was created (since allocation within the finalizer would be forbidden), and it would probably be necessary to use something like a timer event to poll the queue (since the event unsubscription would have to run outside the finalizer thread, and it would probably be silly to have a thread whose sole purpose was to wait for something to appear on the finalizer queue), but if the finalizer could safely reference its pre-allocated linked-list object and the main queue object associated with its class, it could allow the events to be unsubscribed within 15 seconds or so of finalization.
Would that be a good idea? (Notes: I'm using .net 2.0; also, an attempt to add to the stack or queue might spin a few times on Threading.Interlocked.CompareExchange, but I wouldn't expect that it should ever be stuck very long).
EDIT
Certainly any code which subscribes events should implement iDisposable, but disposable things aren't always disposed properly. If there were, there wouldn't be any need for finalizers.
My scenario of concern would be something like the following: a class implementing iEnumerator(of T) hooks onto a changeNotify event of its associated class so that an enumeration can be sensibly handled if the underlying class changes (yes, I know Microsoft thinks all enumerators should simply give up, but sometimes an enumerator which can keep working will be more useful). It's quite possible that an instance of the class might be enumerated many thousands or even millions of times over the course of days or weeks, but not be updated at all during that time.
Ideally, the enumerator would never be forgotten about without being disposed, but enumerators are sometimes used in contexts where "foreach" and "using" aren't applicable (e.g. some enumerators support nested enumeration). A carefully-designed finalizer might allow a means to deal with this scenario.
Incidentally, I'd require that any enumeration which is supposed to continue through updates must use the generic IEnumerable(of T); the non-generic form, which doesn't handle iDisposable, would have to throw an exception if the collection gets modified.
Suppose, however, that I have an object that subscribes to some events, and another object which actually uses the events. If the latter object becomes eligible for garbage collection I want to have the former object unsubscribe from events as soon as practical. Note that the former object will never become eligible for finalization until no subscriptions for it are held by any live object.
If the "latter object" is the one that's using the events, and the "former" object is the one subscribing to the events, the "former" object has to have some way to pass the event info to the "latter" object - meaning it's going to have some reference in place to "latter". Chances are, this will keep the "latter" object from ever being a GC candidate.
That being said, I would recommend avoid this type of managed resource deallocation via the finalizer, unless absolutely necessary. The architecture you're describing seems very fragile, and very tricky to get right. This is probably a better candidate for IDisposable, with the finalizer being the "last ditch" cleanup effort.
Although IDisposable is typically about releasing native resources - it can be about releasing any resource, including your subscription information.
Also, I'd try to avoid having a single global collection of object references - it might make more sense to have your objects internally just use a WeakReference. As soon as the "latter" object is collected, the "former" object's WeakReference would no longer be valid. The next time an event subscription is raised, if the internal WeakReference is no longer valid, you can just unsubscribe yourself. No need for global queues, lists, etc - it should just work...
I'm going to call the objects "publisher" and "subscriber" and restate my understanding of the problem:
In C#, the publisher will (effectively) hold references to the subscribers, preventing subscribers from being garbage collected. What can I do so that the subscriber objects can be garbage collected without explicitly managing the subscriptions?
First, I would recommend doing everything I could to avoid this situation in the first place. Now, I'm going to move on and assume you have, considering you're posting the question anyway =)
Next, I would recommend hooking the add and remove accessors of the publisher's event(s) and using a collection of WeakReferences. You can then automatically unhook those subscriptions whenever the event is invoked. Here's an extremely rough, untested example:
private List<WeakReference> _eventRefs = new List<WeakReference>();
public event EventHandler SomeEvent
{
add
{
_eventRefs.Add(new WeakReference(value));
}
remove
{
for (int i = 0; i < _eventRefs; i++)
{
var wRef = _eventRefs[i];
if (!wRef.IsAlive)
{
_eventRefs.RemoveAt(i);
i--;
continue;
}
var handler = wRef.Target as EventHandler;
if (object.ReferenceEquals(handler, value))
{
_eventRefs.RemoveAt(i);
i--;
continue;
}
}
}
}
Let me make sure I understand -- are you worried about leaks from event subscribers that remain subscribed to a collected event publisher?
If that's the case, then I don't think you have to worry about it.
Here's what I mean assuming that the "former" object is the event subscriber and the "latter" object is the event publisher (raises the event):
The only reason that the subscriber (former) is "subscribed" is because you created a delegate object and passed that delegate to the publisher ("latter").
If you look at the delegate members, it has a reference to the subscriber object and to the method on the subscriber that will be executed. So there is a reference chain that looks like this: publisher --> delegate --> subscriber (publisher references delegate, which references subscriber). It's a 1-way chain -- the subscriber does not hold a reference to delegate.
So, the only root that keeps the delegate around is on the publisher ("latter"). When latter becomes eligible for GC, so does the delegate. Unless there is some special action you want for your subscribers to take when they unsubscribe, they will effectively become unsubscribed when the delegate gets collected -- there is no leak).
Edit
Based on supercat's comments, it sounds like the problem is that the publisher is keeping the subscriber alive.
If that's the problem, then finalizers won't help you. Reason: Your publisher has a real, bonafide reference to your subscriber (via the delegate), and the publisher is rooted (otherise it would be eligible for GC), so your subscribers are rooted, and will not be eligible for finalization or GC.
If you are having trouble with publisher keeping subscriber alive, I would suggest that you search for weak-ref events. Here are a couple links to get you started: http://www.codeproject.com/KB/cs/WeakEvents.aspx http://www.codeproject.com/KB/architecture/observable_property_patte.aspx.
I had to deal with this once as well. Most of the effective patterns involve changing the publisher so that it holds a weak-ref to the delegate. Then you have a new problem -- the delegate isn't rooted, and you hvae to keep it alive somehow. The articles above probably do something like that. Some techniques use reflection.
I used a technique once that did not rely upon reflection. It required that you be able to make changes to the code in both the publisher and the subscriber, though. If you would like to see a sample of that solution, let me know.
Let's try this again. Can you add your event handlers to your publisher like this:
var pub = new Publisher();
var sub = new Subscriber();
var ref = new WeakReference(sub);
EventHandler handler = null; // gotta do this for self-referencing anonymous delegate
handler = (o,e) =>
{
if(!ref.IsAlive)
{
pub.SomeEvent -= handler; // note the self-reference here, see comment above
return;
}
((Subscriber)ref.Target).DoHandleEvent();
};
pub.SomeEvent += handler;
This way, your delegate doesn't keep a direct reference to the subscriber, and automatically unhooks itself whenever the subscriber gets collected. You could implement this as a private static member of the Subscriber class (for the purposes of encapsulation), just make sure it's static to prevent inadvertently holding onto a direct reference to the "this" object.
If yes, is there a way to unwire it globally for all wired events
Edit: Say for example. I have objects, each tagged with an event like orm.NatureChanged += Nature_Changed; I tag these events when i create each orm instance. If I didn't unwire by means like orm.NatureChanged -= Nature_Changed; will it cause memory leak?
Regardless of what you're asking, the technical answer to your question is "no". Technically, unless you discover a bug in the CLR, there are no true "memory leaks" with managed objects (that's a big part of what makes them a Good Thing). To answer what I think you're actually asking, though, it sounds like you're asking one of two things:
Is there something that needs to be done with events that do not have any delegates attached to them?
Can an event prevent objects from getting cleaned up by the garbage collector?
The answer to the first question is simply "no". Move along, nothing to see here.
The answer to the second has been discussed at length here on SO and other areas of the web. The short version is that an attached event handler means that the GC will consider the target instance as "reachable" by the event-firing instance. This can cause objects to remain in memory longer than expected, since this reachability is somewhat transparent to the user (developer) because of the way delegates are constructed.
In other words, say I have two objects: Producer and Consumer. Producer fires an event that Consumer...consumes.
public class Producer
{
public event EventHandler OmgIDidSomething;
}
public class Consumer
{
public void AttachTo(Producer producer)
{
producer.OmgIDidSomething += new EventHandler(producer_OmgIDidSomething);
}
private void producer_OmgIDidSomething(object sender, EventArgs e)
{
// ...
}
}
In this example, any instance of Consumer where AttachTo is called will remain reachable as far as the GC is concerned until the instance of Producer that it attached to is eligible for collection, because the delegate behind the implementation of the OmgIDidSomething event has a reference to the instance of Consumer that it corresponds to.
No, because when you unwire an event, the delegate (it's an object) which was wired to the event is no longer rooted, and will be collected when the GC sees fit to do so. This is assuming of course the event delegate isn't attached to multiple handlers, in which case it won't be collected until it is unwired from all events.
If you meant whether events that don't get unwired can cause a memory leak, the answer is that it can if the actual lifetime of the object holding the event delegate is much longer than the useful lifetime of the object to which the delegate refers. For example, if a collection's enumerator hooked a CollectionChanged event, and someone were to get enumerators without ever disposing them, then every time the collection was enumerated (without disposing the enumerator) a new enumerator object would be created that would stay in memory as long as the underlying collection.
It's not a memory leak, it just doesn't hook any handlers to that event if they aren't wired, automatically or otherwise. So the event fires to nobody, gets cleaned up, and life goes on.
This conversation talks on this subject: How do events cause memory leaks in C# and how do Weak References help mitigate that?
See some background information here: What does AutoEventWireUp page property mean?