Multithreading is managed internally by a thread scheduler, a function the CLR<\/a> typically delegates to the operating system. A thread scheduler ensures all active threads are allocated appropriate execution time, and that threads that are waiting or blocked (for instance, on an exclusive lock or on user input) do not consume CPU time<\/a>.<\/p>\n On a single-processor<\/a> computer, a thread scheduler performs time-slicing \u2014 rapidly switching execution between each of the active threads. Under Windows, a time-slice is typically in the tens-of-milliseconds region \u2014 much larger than the CPU overhead in actually switching context between one thread and another (which is typically in the few-microseconds region).<\/p>\n On a multi-processor<\/a> computer, multithreading is implemented with a mixture of time-slicing<\/a> and genuine concurrency, where different threads run code simultaneously on different CPUs. It\u2019s almost certain there will still be some time-slicing, because of the operating system\u2019s need to service its own threads \u2014 as well as those of other applications.<\/p>\n A thread is said to be preempted when its execution is interrupted due to an external factor such as time-slicing. In most situations, a thread has no control over when and where it\u2019s preempted.<\/p>\n A thread is analogous to the operating system process in which your application runs. Just as processes run in parallel on a computer, threads run in parallel within a single process. Processes are fully isolated from each other; threads have just a limited degree of isolation. In particular, threads share (heap) memory with other threads running in the same application. This, in part, is why threading is useful: one thread can fetch data in the background, for instance, while another thread can display the data as it arrives.<\/p>\n","protected":false},"excerpt":{"rendered":"Threads vs Processes<\/h4>\n