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.
Communication Issue in Different Threading Models.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. |