23

I was under the impression that the dispatcher will follow the priority of the operations queued it and execute the operations based on the priority or the order in which the operation was added to the queue(if same priority) until I was told that this is no the case in case of the WPF UI dispatcher.

I was told that if a operation on the UI thread takes longer duration say a database read the UI dispatcher simple tries to execute next set of operations in the queue. I could not come to terms with it so decided to write a sample WPF application which contains a button and three rectangles, on click of the button, the rectangles are filled with different colors.

<StackPanel> <Button x:Name="FillColors" Width="100" Height="100" Content="Fill Colors" Click="OnFillColorsClick"/> <TextBlock Width="100" Text="{Binding Order}"/> <Rectangle x:Name="RectangleOne" Margin="5" Width="100" Height="100" Fill="{Binding BrushOne}" /> <Rectangle x:Name="RectangleTwo" Margin="5" Width="100" Height="100" Fill="{Binding BrushTwo}"/> <Rectangle x:Name="RectangleThree" Margin="5" Width="100" Height="100" Fill="{Binding BrushThree}"/> </StackPanel>

and in the code-behind

private void OnFillColorsClick(object sender, RoutedEventArgs e) { var dispatcher = Application.Current.MainWindow.Dispatcher; dispatcher.BeginInvoke(new Action(() => { //dispatcher.BeginInvoke(new Action(SetBrushOneColor), (DispatcherPriority)4); //dispatcher.BeginInvoke(new Action(SetBrushTwoColor), (DispatcherPriority)5); //dispatcher.BeginInvoke(new Action(SetBrushThreeColor), (DispatcherPriority)6); dispatcher.BeginInvoke(new Action(SetBrushOneColor)); dispatcher.BeginInvoke(new Action(SetBrushTwoColor)); dispatcher.BeginInvoke(new Action(SetBrushThreeColor)); }), (DispatcherPriority)10); } private void SetBrushOneColor() { Thread.Sleep(10 * 1000); Order = "One"; //MessageBox.Show("One"); BrushOne = Brushes.Red; } private void SetBrushTwoColor() { Thread.Sleep(12 * 1000); Order = "Two"; //MessageBox.Show("Two"); BrushTwo = Brushes.Green; } private void SetBrushThreeColor() { Thread.Sleep(15 * 1000); Order = "Three"; //MessageBox.Show("Three"); BrushThree = Brushes.Blue; } public string Order { get { return _order; } set { _order += string.Format("{0}, ", value); RaisePropertyChanged("Order"); } }

The commented code works as expected the methods are invoked based on the DispatcherPriority and I also get to see the screen refresh after each operation has been completed. Order is One, Two, Three. Colors are drawn one after another.

Now the working code where the DispatcherPriority is not mentioned ( I assume it would default to Normal) the order is still One, Two, Three but if I show a MessageBox inside the methods, the
Thrid popup is show first then Two then One but when I debug I could see the methods are
invoked in the expected order (IntelliTrace even shows that a message box is shown but I don't see it on the screen at that time and see it only after the last operation is finished.) its just that the MessageBoxes are shown in the reverse order.

Is it because MessageBox.Show is a blocking call and the operation are cleared after the message has been closed.
Even then the order of the MessageBox should also be One, Two andThree` ?

Improve this question
3
  • This is simply affected by the order in which you close the message boxes. Since the last one is on top, that's the first one you close. Does not have anything to do with DispatcherPriority. Commented Sep 22, 2014 at 17:35
  • Yes..I thought so, but am not able to see the other MessageBoxes before I close the topmost one. Commented Sep 23, 2014 at 4:42
  • @Vignesh.N does my answer explains your query? Commented Sep 27, 2016 at 5:34

2 Answers 2

Reset to default
7

Before coming down to your code behavior it's a prerequisite to understand the priorities of Dispatcher. DispatcherPriority is divided into ranges as shown in below image.

DispatcherPriority

If you simply queue 4 actions to 4 above ranges on Dispatcher. the Foreground queue will get executed first, then the Background and then in last Idle queue. priority 0 will not get executed.

Now your code:

Three task are queued 1st in background, 2nd in background and 3rd in foreground queue. So 3rd will get executed first. then 2nd task cause it has higher priority then 1st task. I hope that clears it.

Although some more observation will help you understand it better like, what if you have set the priorities as 7,8 and 9. So as this is a foreground queue, 7 will get executed first then 7 and then 8. One by one and exclusively in that order and while 7 is getting executed, 8 and 9 will wait, meaning foreground queue will get executed synchronously to each another.

But Background and Idle queue will not behave in that way the where execution is asynchronous to other tasks and tasks will follow the priority. And first Background and the Idle queue.

Hope this explanation clarifies to some extent.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

if this is true, order of the color and text on screen has to "Three Two One" which is not the case.
@Vignesh.N I think you didn't read the answer carefully.... the task are in foreground queue, they will get executed in the series they are queued. and output will be "one two three"
5

This is because the first MessageBox is blocking the UI thread.

What Dispatcher.BeginInvoke() is doing under the hood is taking your delegate and scheduling it to be run on the main UI thread during it's next idle period. However, MessageBox will block whichever thread it is called from until it is closed. This means that the second MessageBox cannot be displayed until the first is cleared because the UI thread scheduler sees that the thread is already in use (waiting for the first MessageBox to be cleared) and can't execute the next delegate containing the second MessageBox.

Improve this answer

3 Comments

If you were right, I would expect the message boxes to be in the order they have been called. Hence 1, 2, 3 not 3, 2 1...
Indeed, however the execution order problem here can most likely be traced to the nested BeginInvokes. The outer BeginInvoke is already ensuring that the code is running on the UI. Simply removing the inner BeginInvokes would be enough to ensure that the code is executed in order. Calling BeginInvoke from the UI thread could easily have unexpected behaviors since you're already on the UI thread.
You are absolutely right, I tried it myself. I also tried a few times to really understand what is going on behind the scenes in this case, but however I try to look at it I came to the same conclusion: It should be 1, 2, 3. Can you explain in more detail what is your model of the inner workings here? What happens exactly?

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.