Thread Affinity and Context in Visual C#.NET

Print QR Code ISO/IEC18004 in Visual C#.NET Thread Affinity and Context

Not all threads are equal. Some work can be done on only certain threads. For example, WPF and Windows Forms both impose a similar requirement: an object representing something in the user interface must be used only on the thread that created that object in the first place. These objects have thread affinity, meaning that they belong to one particular thread.

Not all things with thread affinity are quite as obstinate as user interface elements. For example, while some COM objects have thread affinity issues, they are usually more flexible. (COM, the Component Object Model, is the basis of various Windows technologies including ActiveX controls. It predates .NET, and we ll see how to use it from .NET in 19.) .NET handles some of the COM thread affinity work for you, making it possible to use a COM object from any thread. The main ways in which COM s thread affinity will affect you are that certain objects will have different performance characteristics depending on which thread you call them on, and there may be additional complications if your COM objects use callbacks. So thread affinity just means that the thread you re calling on makes a difference. It doesn t always mean that using the wrong thread is guaranteed to fail it depends on what you re using.

If you never write multithreaded code, you never have to worry about thread affinity if you do everything on one thread, it will always be the right one. But as soon as multiple threads get involved either explicitly or implicitly you may need to add code to get things back on the right thread. ASP.NET has a similar problem. It makes contextual information about the current request available to the thread handling the request, so if you use multiple threads to handle a single request, those other threads will not have access to that contextual information. Strictly speaking, this isn t a thread affinity issue ASP.NET can use different threads at different stages of handling a single request but it presents the same challenge to the developer: if you start trying to use ASP.NET objects from some random thread, you will have problems. The .NET Framework defines a solution that s common to WPF, Windows Forms, and ASP.NET. The SynchronizationContext class can help you out if you find yourself on the wrong thread when using any of these frameworks. Example 16-7 shows how you can use this in an event handler for a GUI application the click handler for a button, perhaps.

Always remember that even if you have not created any threads explicitly, that doesn t mean you re necessarily writing single-threaded code. Some .NET Framework classes will bring extra threads into play implicitly. For example, the CLR s garbage collector runs finalizers on a distinct thread.

SynchronizationContext originalContext = SynchronizationContext.Current; ThreadPool.QueueUserWorkItem(delegate { string text = File.ReadAllText(@"c:\temp\log.txt"); originalContext.Post(delegate { myTextBox.Text = text; }, null);

});

The code reads all the text in from a file, and that s something that might take awhile. Event handlers in WPF and Windows Forms are called on the thread that the event source belongs to a UI thread. (Or the UI thread if, like most desktop applications, you have only one UI thread.) You should never do slow work on a UI thread thread affinity means that if your code is busy using that thread, none of the UI elements belonging to that thread will be able to do anything until you re finished. The user interface will be unresponsive for as long as you keep the thread busy. So Example 16-7 uses the thread pool to do the work, keeping the UI thread free. But the code wants to update the UI when it has finished it s going to put the text it has retrieved from the file into a text box. Since a text box is a UI element, it has thread affinity we can update it only if we re on the UI thread. This is where Synchroniza tionContext comes to the rescue. Before starting the slow work, Example 16-7 reads the SynchronizationContext class s Current property. This static property returns an object that represents the context you re in when you read it precisely what that means will depend on what UI framework you re using. (The object you get back works differently depending on whether your application uses WPF, Windows Forms, or ASP.NET.) But the exact implementation doesn t matter you just need to hold on to it until you need to get back to that context. Having grabbed the context while we were in the click handler, we then kick off the work in the thread pool. And once that work is complete, it calls the stored SynchronizationContext object s Post method. Post takes a delegate, and it ll invoke that delegate back in whatever context you were in when you grabbed the context. So in this case, it ll invoke our delegate on the UI thread that the button belongs to. Since we re back on our application s UI thread, we re now able to update the text box.