Understanding Multi-Threading in VB.Net

[Niya]

Niya,
At this point I don't suppose you ~need~ to hear again what an outstanding job you've done here but I think you should here it!!! And like several others, your posts and in particular your responses to the replies of others inspired me to register here just to tell you how much I appreciate how cogent your instructions are, how patient you are in your responses to nuubs (myself included hopefully), how generous you are of your time to continue supporting this thread now for over almost two and a half years and (he bows his head in embarrassment) to ask a few questions of my own.
Notwithstanding my questions, my inspiration to register came from my need to tell you that you are truly the "Angel of Code," for this is, by far, the best thread on multi-threading (sorry for the pun) that I've found and I am certain not to find one better. What has made this thread even better are some of the queries to it and your thoughtful, helpful and instructive responses to them. I hope that (even as a nuub) my questions can make a contribution in this realm.

Nice to hear this has been helpful.

Question 1) Please confirm. (my situation) If you have a third party component instantiated in the main thread; when you handle a callback from that component, the callback is directly run in the main UI thread, if the callback delegate and method are in the code for the main form, yes? I am pretty sure the answer is 'Yes,' but I'm not 100% sure that the code in the component (clearly a separate thread) extend itself into the callback method...

I think you may be holding onto a few misconceptions. Firstly, objects aren't really thread specific in the strictest technical terms. While some classes might goad you into paying attention to the thread they were created on, know that there is nothing inherent in the operation of the .Net Framework that says that an object belongs to a particular thread. This is all the work of the person who wrote the class. They can choose to have that class execute its methods on that thread or to have them executed on only the UI thread regardless of where it was created.

Executing methods are thread specific, not the classes that define them. That being said, you can never make assumptions about what thread a callback will be executed on. The only way to be certain is to consult the documentation for the component. A properly documented component will inform you how their callbacks are executed. However, there are common patterns surrounding callbacks that can help you make a well informed guess. One such pattern is the asynchronous pattern which you might have seen on classes like the Socket class. The Socket class has several methods which have asynchronous variants. In those cases, callbacks are employed to signal either the failure or success of an operation. These callbacks are usually executed on a worker thread. If you see a pattern like that, you can make a well informed guess. But its still not a guarantee.

Question 2) Please confirm. Some of your responses to queries were (understandably) VB.Net Framework version dependent . With the final version of your post (i.e., using the "QueueUserWorkItem" of ThreadPool, which works under Framework 3.5, my target), is it necessary to "EndInvoke" this thread? Again I'm pretty sure, based on reading descriptions written elsewhere about ThreadPool, but ask so I can sleep at night with no lingering doubts...

No, you don't need to call and type of 'EndInvoke' method for QueueUserWorkItem. EndInvoke is usually employed with the asynchronous pattern I mentioned above.