Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
After exploding with excitement over learning about how to make thread-safe calls to Windows Form Controls, it got me thinking…
Why aren’t all calls to Windows Form Controls thread-safe? Can anyone explain why? I would think it would reduce a lot of confusion for users of those controls.
The issue here is not one of thread safety. The methods are all “thread safe” in that they do not corrupt the state of the application when called simultaneously on multiple threads – it is just that thread safety includes throwing a wrong thread exception (can’t remember what it is called).
What they have is thread afinity – they can only be called on one thread – sometimes referred to as the UI thread, although this is misleading because it implies there is only one. This is mainly because the OS calls they depend on have the same thread affinity rules.
Trust me – this is a good thing. When you think about the primary role of the “UI Thread” it all starts to become clear. The UI threads job is to take input from the users hands, through a keyboard or mouse, act upon it, and produce output in the form of pixels in response. There is only one user, and that user only has one set of eyes. The user expects to see everything they do happen on the screen, and most importantly they expect to see it happen in the order they did it. Multithreaded UI would make this very difficult to achieve – almost impossible.
The problem is that when you mix your background “worker” threads with the UI thread, you need to do a certain amount of marshalling to talk to the UI because you have to be on the UI thread to do it. Again, as I said, this is a good thing. Someone has to do this marshalling, else the user would see things happening in the wrong order and that is bad. The system could admittedly do it for you, and in some WIN32 calls it does – but this has problems. First of all, the system can’t know what granularity you need the marshalling to occur at so you might end up being inefficient. Your operations might be better marshalled at a higher level than the system can understand. Secondly, the marshalling is expensive, and it punishes the developers who are doing the right thing and moving everything over to the UI thread correctly. So the system does the minimum thing it can, check if it is on the right thread and if not, throw an exception.