What is threading context?

Question

Does a thread's context refer to a thread's personal memory? If so, how is memory shared between multiple threads?

I'm not looking for code examples- I understand synchronization on a high level, I'm just confused about this term, and looking to gain some insight on what's actually happening behind scenes.

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.

As I didn't realize the term was more general, I guess I'm asking how context-switching works in Java and C# specifically.

Solution 1

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.

Solution 2

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.

Comments

[Alexei Levenkov]

Providing some context where you got "thread context" can help with an answer. Threads don't have "personal copy of memory" in .Net memory model...

[Eric Lippert]

Alexei is absolutely right; without saying where you heard this term or how it was used, it is hard to say. For example, in the Task-based Asynchrony Pattern there is an object called the threading context and that has a very specific meaning when you're talking about TAP programming. (Because the continuation of a completed task is always scheduled to run in a thread that had the same "context" as the thread that awaited the task.)

[Eric Lippert]

In particular, are you asking about the meaning of the CurrentContext property of a Thread object?

[Eric Lippert]

Regardless though of what you mean by "context", I am completely confused about what you mean by "scope" -- scope is a property of things that have names and only has meaning at compile time. The scope of a field, say, is the region of program text in which that field may be referred to by its unqualified name. What does that have to do with threads? I also don't understand what you mean by "a personal copy of memory". That's not how memory works. Virtual address spaces are per-process, not per-thread.

[Eric Lippert]

All in all, now I'm not even sure this question is answerable. Can you clarify it a whole bunch?

[William Morrison]

Yes, let me edit... I'll elaborate.

[William Morrison]

Edited. Hopefully I've been more clear. I'm not asking about a property.

[Simon Whitehead]

Context switching isn't a language / framework feature.. it's an OS feature.

[William Morrison]

Oh. I was thinking the virtual machine would handle it, but I guess you're right. Threads are native... I think. Starting to doubt everything :)

[Eric Lippert]

Threads are both native and managed in .NET. Threads that are managed by the CLR have many restrictions placed on them by the runtime that truly native threads do not have. For example, a managed thread abort exception is never thrown while a managed thread is executing native code. For example, the CLR guarantees that no race conditions in verifiable code will corrupt the CLR's data structures, even if they are corrupting your data structures.

[William Morrison]

Thank you for what you've done already, +1. Do threads have personal memory in C#/Java? That's the only thing I don't have an answer for yet.

[William Morrison]

So then thread context in C#/Java refers to what a thread says its local copy of memory is? This is a fantastic answer by the way.

[Eric Lippert]

@WilliamMorrison: I don't know what "thread context" means the way you are using it. I would not use "thread context" when speaking about C# to mean anything other than "the object returned by the CurrentContext property of a Thread object". Consider for example a thread that is in charge of running the UI refreshes, and a thread that is in charge of keeping track of network requests, and ten threads that are all off drawing fractals into bitmaps. You might want to have three different threading contexts, one for each of those kinds of tasks.

[Eric Lippert]

The idea would then be that if a thread in the UI context requested the results of the bitmap rendering, and the rendering wasn't done yet, then the scheduled completion of the rendering task would be executed on a thread in the UI context and not on a thread in the rendering context. By contrast, if the completion of a task happens to be "I need more rendering", then it doesn't matter which of the ten rendering threads you pick; any idle thread will do. That's what I mean when I say "threading context".

[Drakarah]

Isn't ThreadLocal<T> better than ThreadStatic? (see stackoverflow.com/questions/18333885/…)