Background and UI Threads in a WPF Application

Question

I am reading DataModel-View-ViewModel pattern: 2

I don't really understand the need to check if I am in the UI or Background thread. what if i skip the checks. Also, the code below ...

[Conditional("Debug")]
protected void VerifyCalledOnUIThread()
{
    Debug.Assert(Dispatcher.CurrentDispatcher == this.Dispatcher,
        "Call must be made on UI thread.");
}

does not really do anything, eg. set values. So if I am not debugging will it do anything at all?

Answer 1

You only need to worry about this if you are using another thread. If you're not doing this explicitly, then you're probably using the UI thread.

Some async operation callbacks, such as a web service/wcf call, is handled on the UI thread. Also, if you use a timer, such as a DispatchTimer, it is also on the UI thread. Finally, if you use a BackgroundWorker thread, that too is handled on the UI thread.

Hope this helps.

Answer 2

I don't really understand the need to check if I am in the UI or Background thread. what if i skip the checks.

The reason for using the Dispatcher and checking if you're on the UI or background thread is because of WPF's requirement that controls only be accessed on the thread they were created on. The reason for this is because the controls are not thread-safe. If you're not doing multithreading (i.e. all of your code is on the main thread), then you don't have to worry about this. WinForms has this same limitation.

If you try to access a control from a different thread than the one it was created on, you'll get an InvalidOperationException.

Also, the code below...does not really do anything, eg. set values. So if I am not debugging will it do anything at all?

When compiling a release build, Debug.Assert (and your VerifyCalledOnUIThread method) will not even appear in the code, so no, nothing will happen.

Answer 3

Sorry, but I am not agree with Chris Schmich.

You can see that the VerifyCalledOnUIThread() appears in the DataModel. Actually the purposes is To Veryfy the DataModel (not the control) only accessed from UI Thread. Yes WPF/SilverLight UI is not cross thread safe, but in this case that was't the real reason.

The fact is if you bind something (datamodel/viewmodel) to WPF/SilverLight UI and you access it from different thread other then UI thread, then you will get uninformative exception. Trouble shooting this error is verry hard because Exception thrown didn't give any clue.

I give you example about that:

//pass model to datacontex and bind it 
mycontrol.DataContext = myModel;

//myThreadedService is an assynchronous service
//done ini different thread.
//so ServiceDone will call myModel.Complete from different thread
//system will crash unexpectedly without enough clue
myThreadedService.ServiceDone += (s, e) => { myModel.Complete = true; }
myThreadedService.CallService();

So, i think you understand now why this piece of code should be there:

Debug.Assert(Dispatcher.CurrentDispatcher == this.Dispatcher,
        "Call must be made on UI thread.");

This code will give a clue when you accessing DataModel from different thread.