5

I use the SynchronizationContext to invoke methods from my background thread on the UI thread. I read this post which asks for the difference of Send and Post. I understand the answer and would call Send whenever I need the result of the called method to proceed and I would call Post whenever I don't care for the result.

My question is: Can I make any assumption on the order in which the Posted delegates are called? For example I would Post messages that could be displayed in a log window on the UI thread. But if the Posted delegates don't get processed in the order they are invoked, the message log would display the message out of order, too.

I could solve that by Sending the messages, but do I really need to worry about that?

Community
  • 1
  • 1
Sascha
  • 1,210
  • 1
  • 17
  • 33
  • 1
    [This](http://geekswithblogs.net/akraus1/archive/2014/10/12/159645.aspx) would be a good read for you. Are you using WinForms or WPF? I think this would be implementation specific to the `SynchronizationContext` you're using. – Yuval Itzchakov Dec 18 '15 at 07:14
  • Thanks @YuvalItzchakov. The article explains it quite well. I use WinForms by the way. The article describes a situation where messages get out of order (when posting a sending command). At least in my code I will prevent the situation. But I can not make any assumptions on what the per Post invoked method does. Maybe it's bad API design, but I don't feel responsible for that. So far I would consider my question solved. Thanks again. – Sascha Dec 18 '15 at 07:25

1 Answers1

0

You can depending on the app model you are using, which will inform which SynchronizationContext you us. Different implementations have different behaviours, which is well illustrated in table (Figure 4) in this article.

So desktop UI based SynchronizationContext implementations will guarantee ordered execution of delegates, and for others it is not guaranteed.

Stuart
  • 5,358
  • 19
  • 28