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.
The ThreadContext allows applications to store information either in a Map or a Stack. The MDC is managed on a per thread basis. To enable automatic inheritance of copies of the MDC to newly created threads, enable the "isThreadContextMapInheritable" Log4j system property.
With computer programming, a thread is a small set of instructions designed to be scheduled and executed by the CPU independently of the parent process. For example, a program may have an open thread waiting for a specific event to occur or running a separate job, allowing the main program to perform other tasks.
Thread switching is a type of context switching from one thread to another thread in the same process. Thread switching is very efficient and much cheaper because it involves switching out only identities and resources such as the program counter, registers and stack pointers.
Context switching is the technique where CPU time is shared across all running processes and processor allocation is switched in a time bound fashion. To schedule a process to allocate the CPU, a running process is interrupted to a halt and its state is saved.
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:
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With