A “thread” is an abstraction of the platform, providing the impression that the
CPU is performing multiple tasks simultaneously; in essence, it offers to the
programmer the ability to walk and chew gum at the same time. The .NET framework
makes heavy use of threads throughout the system, both visibly and invisibly.
System.Threading namespace contains most of the baseline
threading concepts, usable either directly or to help build higher-level constructs
(as the .NET Framework Class Library frequently does).
The “thread” itself is sometimes referred to as a “lightweight process” (particularly within the Unix communities). This is because the thread, like the concept of a process, is simply an operating system (or, in the case of .NET, a CLR) abstraction. In the case of Win32 threads, the operating system is responsible for “switching” the necessary execution constructs (the registers and thread stack) on the CPU in order to execute the code on the thread, just as the OS does for multiple programs running simultaneously on the machine. The key difference between a process and a thread, however, is that each process gets its own inviolable memory space — its “process space” — that other processes cannot touch. All threads belong to a single process and share the same process space; therefore, threads can operate cooperatively on a single object. However, this is both an advantage and a disadvantage — if multiple threads can all access a single object, ...