Class DomainContext has method Invoke which return instance of InvokeOperation
and often we can see next code
InvokeOperation op = domainConextInstance.Invoke(...);
op.Completed +={...};
My first thought - it should not work: after all event can arise earlier than we will subscribe for it.
I made an experiment
InvokeOperation op = domainConextInstance.Invoke(...);
Thread.Sleep(5000); //or 25000
op.Completed +={...};
But I found that this code works correctly, But how?
Can you explain this to me?
And what pattern does this construct use?
It's hard to know without seeing any of the code for DomainContext - but it sounds like the code which adds a handler for the Completed event calls the handler immediately if the operation has already completed.
Assuming you have the code for InvokeOperation, I'd definitely look at the declaration of the Completed event to discover the "magic".
Assuming, you are talking about WCF RIA Services SDK, Jon is right. InvokeOperation has a property IsComplete. The add part of the Completed event checks this property. In case of a completed operation it does not add the passed event handler but calls it immediately.
You can validate this by inspecting OperationBase (base class of InvokeOperation) in System.ServiceModel.DomainServices.Client.dll with a disassemler tool like dotPeek.
Related
My WinForms application connects to a running service via WCF and subscribes to events from the service. When the event fires, my application requests current data from the service and calls a method named UpdateDisplay() to populate a DataGridView and display it. The grid view is remaining empty, and I'm trying to debug it. But if I put a breakpoint inside UpdateDisplay(), the next time the event fires, I get a deadlock because the first event handler hasn't finished yet.
I thought I could unsubscribe from the event at the top of my method and resubscribe to it at the bottom, something like this:
private static bool m_updatingDisplay = false;
private void UpdateDisplay()
{
// Unsubscribe from the event while the display is being updated. This should remove the problem of deadlocks while debugging because
// the event gets raised again.
m_callbackHandler.DatabaseUpdatedEvent -= m_callbackHandler_DatabaseUpdatedEvent;
DoSomethingThatTakesALongTime();
m_callbackHandler.DatabaseUpdatedEvent += m_callbackHandler_DatabaseUpdatedEvent;
}
But I still get the exception.
My only thought is to have the event handler merely set a flag, and then a timer would check the flag every minute or so, and if it's true, then it would do the update and clear the flag. I think that would work, but I have a feeling this is a common problem with a well-recognized solution, and I should probably know what it is. What's the best way to handle this situation?
The InvalidOpeartionException is a very odd Exception, because it covers a lot of possible things. All of those very specific to what function you call and what call it onto. The Documentation actually lists examples, but those really only showcase how little all the cases have in common:
Enumerators are supposed to become Invalid, if the underlying collection was changed. Hence they throw a IOE
For ResourceSet, it would be a case of the resource closed/disposed. Hence the IOE
XContainer.Add is specific to XML modification and the way that class does it's job. Hence the IOE
And the UI class case is soemthing we specifically invented to get people to properly use invoke.
So without you telling us exactly what DoSomethingThatTakesALongTime() and m_callbackHandler_DatabaseUpdatedEvent do - and wich specific line this exception is from - we can not hope to help you.
I guess C# eventhandler has a list of listeners and it loops thru the list when sending a message. My question is how does this works in internally. Does it make a copy of the list before looping it thru and if so, what happens if someone unregister itself after the list has been copied but it has not yet received the message.
Will it still get the message even do it has unregister itself?
A delegate is immutable, so when you are invoking a delegate the list of subscribers is known and fixed. Subscribing or unsubscribing replaces the delegate that underpins the event.
This does indeed mean that in a multi-threaded scenario you can receive an event after unsubscribing, because either:
the delegate was already in the process of being invoked
a snapshot of the delegate had already been obtained for the purpose of invoking
by 2, I mean the usual pattern (to prevent a null-ref during invoke):
var handler = SomeEvent;
// <===== another thread could unsubscribe at this point
if(handler != null) handler(sender, args); // <== or part way through this invoke
// (and it either case, have the event trigger even though they think they have
// unsubscribed)
For that reason, if you are coding complex multi-threaded code with events, you should code defensively such that the event firing after you think you have unsubscribed is not a problem.
These nuances do not really impact single-threaded code.
Say I have the following code:
public event EventHandler DatabaseInitialized = delegate {};
//a intederminant amount of subscribers have subscribed to this event...
// sometime later fire the event, then create a new event handler...
DatabaseInitialized(null,EventArgs.Empty);
//THIS LINE IS IN QUESTION
DatabaseInitialized = delegate {};
Will this clear out the subscribers, replacing it with new empty default? And, will the event notify all subscribers before they get cleared out? I.E. Is there a chance for a race condition?
Yes it will clear it out. And because events fire syncronously in the same thread there shouldn't be race condition.
My advice: when in doubt, write a small test application and... well, test it.
UPDATE: I tested it before posting. (In response to minuses.)
To unsubscribe from the event use event-=delegate, so you're sure that resource is free. Even if by official Microsoft documentation it's not necessary, in my own experience, especially on a large scale complex project, unnecessary events suscribers are source for memory leaks. So unsubscribe from them explicitly.
Have just had an idea, I haven't seen it before, wondering if you guys thought it was a good idea, if it exists, any common pitfalls etc. - and also how to implement it.
There are several times I've found myself subscribing to an event from the UI thread that will be called from a different thread - for example, notification of a service call completing.
'My' idea would be to store the current Dispatcher in the add block along with the handler delegate, then when the event is 'fired', perform some extra logic/checks to see if there was a dispatcher associated with the handler, and Invoke on it if necessary.
Of course it would only work on threads with a Dispatcher (or Forms equivalent - something with a message pump I guess). I guess the usefulness and cleanliness depends on whether the event subscriber should have to worry about the thread the handler is called or not?
Edit: Sounds like it's not such a bad thing then - additionally does anyone have any idea how to implement? Using Delegate.Combine how could you call each handler on a different Dispatcher, for example? Would you instead store delegates in a composite object in a List, and invoke them in turn in the On(Whatever) method, or is there something nicer?
...Looking at the BackgroundWorker source in Reflector, there's nothing to Invoke:
protected virtual void OnProgressChanged(ProgressChangedEventArgs e)
{
ProgressChangedEventHandler handler = (ProgressChangedEventHandler) base.Events[progressChangedKey];
if (handler != null)
{
handler(this, e);
}
}
Unless I'm missing something?
So then BackgroundWorker does it with an AsyncOperation. How about a general solution, just for event handlers, in the event accessors? BackgroundWorker can get away with the way it works because a method is called from the client - in the more general case, the only time you'll have access to the handler's thread is in the event accessor? :)
As far as I know, that's exactly what the BackgroundWorker is doing in its RunWorkerCompleted and ProgressChanged events. So it can't be that bad.
I can't find a real proof, that the BackgroundWorker is doing it, I just read it somewhere. When you google for it, you will find more hints. If someone can provide a link, I would be happy.
UPDATE:
Because it isn't so easy to find this behavior in the BackgroundWorker, I provide my analysis:
The BackgroundWorker is using an AsyncOperation for raising the events. Inside this class, the events are posted to a SynchronizationContext. Only then are the methods OnProgressChanged and OnRunWorkerCompleted executed. This means, those methods are already executed on the right thread.
In some more detail, the following happens, when RunWorkerAsync is called:
An AsyncOperation instance is created via AsyncOperationManager.CreateOperation. This saves the current SynchronizationContext. As we are still in the UI thread, this is the context of the UI thread.
The background operation is started and calls into the private method WorkerThreadStart. This method is running in the background thread and executes OnDoWork which in turn raises the DoWork event. This means, the DoWork event is not raised in the UI thread.
After OnDoWork completed, the PostOperationCompleted method of the AsyncOperation instance is executed which in turn calls AsyncOperation.Post which calls SynchronizationContext.Post which in turn will call indirectly OnRunWorkerCompleted on the UI thread.
When ReportProgress is called, a similar thing happens: AsyncOperation.Post is called directly and will invoke the OnProgressChanged method on the UI thread.
AsyncOperation and AsyncOperationManager are public and can be used to implement a similar behavior in your classes.
I've done something similar with Castle DynamicProxy, where it intercepts calls and does an IsInvokeRequired/Invoke on them.
I have a class containing a worker thread which receives data from a queue in a loop.
Another part of the app sinks an event from this class, which the class raises for each queue item.
These events are fired asynchronously, so at busy times the other part of the app can be processing several events at once.
This should be fine but we've discovered a scenario where this can cause problems.
We need a quick solution while the main issue gets addressed. Does the framework provide a simple way I can force the worker thread to wait while each event gets processed (so they are processed sequentially)? If not, what's the easiest way to implement this?
A simple answer would be to lock() on a single object in the event handler. All of the theads would wait to get the lock.
The ManualResetEvent class might help you here, unless I'm not understanding your question. You can use it to block the firing of the next event until the last one completes.
My guess is that you want to simply go away from triggering the action by raising an event and calling the method directly.
AFAIK events are going to be async and I am not aware of any "easy" ways of changing that.
Turns out there's another answer. You can just add the following attribute to the method.
[System.Runtime.CompilerServices.MethodImpl(System.Runtime.CompilerServices.MethodImplOptions.Synchronized)]
There is no general way.
In the end the handlers need to provide a mechanism for tracking.
If you are using BeginInvoke, rather than raising the events directly, you can use a wrapper, within which you call the real event handler synchronously, then raise the wrapper asynchronously. The wrapper can maintain a counter (with Interlocked operations) or set an event as meets your needs.
Something like:
TheDelegate realHandler = theEvent;
var outer = this;
ThreadPool.QuereUserWorkItem(x => {
// Set start of handler
realHandler(outer, eventArgs);
// Set handler finished
};
All of the event handlers sinking events raised by the queue-reading worker thread are called in the queue-reading worker thread. As long as the event handlers aren't spawning threads of their own, you should be able to wait for the event handlers to finish by calling Thread.Join() on the queue-reading worker thread.