Can I be sure that the code I write is always executed in the same thread?

Question

I normally work on single threaded applications and have generally never really bothered with dealing with threads. My understanding of how things work - which certainly, may be wrong - is that as long as we're always dealing with single threaded code (i.e. no forks or anything like that) it will always be executed in the same thread.

Is this assumption correct? I have a fuzzy idea that UI libraries/frameworks may spawn off threads of their own to handle GUI stuff (which accounts for the fact that the Windows task manager tells me that my 'single threaded' application is actually running on 10 threads) but I'm guessing that this shouldn't affect me?

How does this apply to COM? For instance, if I were to create an instance of a COM component in my code; and that COM component writes some information to a thread-based location (using System.Threading.Thread.GetData for instance) will my application be able to get hold of that information?

So in summary:

1. In single threaded code, can I be sure that whatever I store in a thread-based location can be retrievable from anywhere else in the code?

2. If that single threaded code were to create an instance of a COM component which stores some information in a thread-based location, can that be similarly retrievable from anywhere else?

Answer 1

UI usually has the opposite constraint (sadly): it's single threaded and everything must happen on that thread.

The easiest way to check if you are always in the same thread (for, say, a function) is to have an integer variable set at -1, and have a check function like (say you are in C#):

void AssertSingleThread()
{
   if (m_ThreadId < 0) m_ThreadId = Thread.CurrentThread.ManagedThreadId;
   Debug.Assert(m_ThreadId == Thread.CurrentThread.ManagedThreadId);
}

That said:

I don't understand the question #1, really. Why store in a thread-based location if your purpose is to have a global scope ?

About the second question, most COM code runs on a single thread and, most often, on the thread where your UI message processing lives - this is because most COM code is designed to be compatible with VB6 which is single-thread.

The reason your program has about 10 threads is because both Windows (if you use some of its features like completion ports, or some kind of timers) and the CLR (for example for the GC or, again, some types of timers) may create threads in your process space (technically any program with enough priviledges, can too).

Answer 2

Think about having the model of having a single dataStore class running in your mainThread that all threads can read and write their instance variables to. This will avoid a lot of problems that might arise accessing threads all over the shop.

Simple idea, until you reach the fun part of threading. Concurrency and synchronization; simply, if you have two threads that want to read and write to the same variable inside dataStore at the same time, you have a problem.

Java handles this by allowing you to declare a variable or method synchronized, allowing only one thread access at a time.

I believe some .NET objects have Lock and Synchronized methods defined on them, but I know no more than this.