What is threading context?

The reason I thought/think each thread has some kind of private memory was because of the volatile keyword in Java and .NET, and how different threads can have different values for the same primitive if its not used. That always implied private memory to me.

OK, now we're getting to the source of your confusion. This is one of the most confusing parts about modern programming. You have to wrap your head around this contradiction:

• All threads in a process share the same virtual memory address space, but
• Any two threads can disagree at any time on the contents of that space

How can that be? Because

• processors make local copies of memory pages for performance reasons, and only infrequently compare notes to make sure that all their copies say the same thing. If two threads are on two different processors then they can have completely inconsistent views of "the same" memory.

• memory in single-threaded scenarios is typically thought of as "still" unless something causes it to change. This intuition serves you poorly in multithreaded processes. If there are multiple threads accessing memory you are best to treat all memory as constantly in a state of flux unless something is forcing it to remain still. Once you start thinking of all memory as changing all the time it becomes clear that two threads can have an inconsistent view. No two movies of the ocean during a storm are alike, even if its the same storm.

• compilers are free to make any optimization to code that would be invisible on a single threaded system. On a multi-threaded system, those optimizations can suddenly become visible, which can lead to inconsistent views of data.

If any of that is not clear, then start by reading my article explaining what "volatile" means in C#:

http://blogs.msdn.com/b/ericlippert/archive/2011/06/16/atomicity-volatility-and-immutability-are-different-part-three.aspx

And then read the section "The Need For Memory Models" in Vance's article here:

http://msdn.microsoft.com/en-us/magazine/cc163715.aspx

Now, as for the specific question as to whether a thread has its own block of memory, the answer is yes, in two ways. First, since a thread is a point of control, and since the stack is the reification of control flow, every thread has its own million-byte stack. That's why threads are so expensive. In .NET, those million bytes are actually committed to the page file every time you create a thread, so be careful about creating unnecessary threads.

Second, threads have the aptly named "thread local storage", which is a small section of memory associated with each thread that the thread can use to store interesting information. In C# you use the ThreadStatic attribute to mark a field as being local to a thread.

The actual make up of a "thread context" is implementation specific, but generally I have always understood a thread's context to refer to the current state of the thread and how it views memory at a specific time. This is what "context switching" is.. saving and restoring the state of a thread (it's context).

Memory is shared between the contexts.. they are part of the same process.

I don't consider myself a huge expert on the topic.. but this is what I have always understood that specific term to mean.