Can I be sure that the code I write is always executed on the same thread?
I usually work on single threaded applications and generally never bothered about working with threads. My understanding of how things work, which of course could be wrong, is that as long as we are always dealing with single threaded code (i.e. no forks or something like that) it will always be run on the same thread.
Is this assumption correct? I have a vague idea that UI libraries / frameworks can spawn their own threads to handle GUI files (which explains the fact that the Windows Task Manager tells me my single threaded app is actually running on 10 threads), but I think shouldn't this affect me?
How does this relate to COM? For example, if I had to instantiate a COM component in my code; and that the COM component is writing some information to the streaming location (with a help for example System.Threading.Thread.GetData
), will my application be able to get this information?
So, in short:
-
In one streamed code, can I be sure that whatever I store in a streamed location can be retrieved from anywhere in the code?
-
If this single streaming code were to instantiate a COM component that stores some information in a streamed location, could it be retrieved in a similar way from anywhere?
source to share
The UI usually has the opposite limitation (unfortunately): it's a one-liner, and everything has to happen on that thread.
The easiest way to check if you are always on the same thread (like a function) is to have an integer variable set to -1 and have a check function (like 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 question # 1, really. Why store in a streaming location if your goal is to have a global scope?
About the second question, most COM code runs in a single thread and, more often than not, the thread where your UI message handling lives - this is because most COM code is designed to be compatible with VB6, which is single threaded.
The reason your program has about 10 threads is because both the OS (if you use some of its features like completion ports or some kind of timers) and the CLR (for example for GC or, again, some timer types) can create threads in your process space (technically, any program with sufficient privileges can too).
source to share
Think about whether the model has one dataStore class running in your mainThread that all threads can read and write their instance variables. This will avoid many of the problems that can arise when accessing streams throughout the store.
Simple idea until you reach the fun part of streaming. Concurrency and synchronization; just if you have two threads that want to read and write the same variable in the dataStore at the same time, you have a problem.
Java handles this by allowing you to declare a variable or sync method, allowing only one thread to access at a time.
I suppose some .NET objects have Lock and Synchronized methods defined on them, but I know nothing more.
source to share