Before moving further we need to have a quick understanding about applications threading model.
The .NET Framework supports several different kinds of application models, and each application model might impose its own threading model.
Console applications and Windows Services (which are really console applications; you just don’t see the console) do not impose any kind of threading model; that is, any thread can do whatever it wants when it wants.
However, GUI applications, including Windows Forms, Windows Presentation Foundation (WPF), and Silverlight, impose a threading model where the thread that created the window is the only thread allowed to update that window.
It is common for the GUI thread to spawn off an asynchronous operation so that the GUI thread doesn’t block and stop responding to user input like mouse, keystroke, pen, and touch events.
When two different threading model tired to talk each other then it could be problematic for example when the asynchronous operation completes using a thread pool thread then it cannot update the UI showing the results.
Fortunately, the FCL defines a base class, called System.Threading.SynchronizationContext, which solves all these problems. Simply stated, a SynchronizationContext-derived object connects an application model to its threading model. It provides Send and Post methods that allows communicating two different threads.