remembering the CLI and the multi-tasking OS
I have literally paid the price for forgetting about the wonders of a multitasking Operating System and how the Common Language Infrastructure (CLI) takes advantage of such a thing for my benefit. And when I mean “literally paid” I am talking about the intricacies of the job interview. For at least one job opportunity, I have failed to take the time to sit down, draw a picture and wax poetic about the whole reason why the execution of my code is possible, leaving extremely busy hiring managers to assume that I care little about such a wondrous thing.
First, according to the academic custom, I must empty the universe of almost everything and begin with a single statement:
A multitasking Operating System can schedule a CLI Task with its Thread.
thread scheduling
Scheduling is fundamental to computation itself. It crosses the boundary between abstract logic and real computing resources under the control of a multitasking Operating System (OS). Scheduling is not just about time; it is about the time when computing resources will be available.
Both the Task and the Thread (coincidentally?) exist in the abstract logic of the computer programming language(s) of the CLI and in the OS. The confusion may start when we must see that:
- in the OS, the Task or Process is an entire computer program, composed of one or more threads
- in the CLI, the Task is a grouping of statements and/or expressions, running on a Thread (usually asynchronously)
threads of the AppDomain
The CLI groups threads together in an isolated environment called the
AppDomain[docs]; the OS can see several AppDomain instances in a single process.
One leading benefit of the CLI insinuating itself between OS processes and threads is to reduce the cost of context switching, especially in the traditional, single core processor system.
Another benefit, is the single execution model implemented in the Common Language Runtime (CLR), featuring its Just-in-Time (JIT) compilation. The CLR can be thought of as one throat to choke when it comes to security issues around the successful isolation of the AppDomain.
threads of the thread pool
Most threads for most programmers come from a thread pool which is a task queue related to the all-important scheduling mentioned above. Windows programmers who are familiar with SQL Server or Internet Information Server (IIS) will have been introduced to the thread pool concept. According to Joe Duffy, in Concurrent Programming on Windows:
Both Windows and the CLR offer different variants of the thread pool idea that are entirely different components and provide different APIs.
On the client side, Windows Windows Presentation Foundation (WPF) is designed with two default threads, one for handling rendering and another for “managing the UI”—this latter thread borrows from the tradition of the event loop, leading developers down into the often slippery slope of event driven programming for the Graphical User Interface (GUI).
thread safety
Thread safety is about preventing race conditions and deadlocks. Chapter 11 of Joe Duffy’s book, “Concurrency Hazards,” groups race conditions and deadlocks under “correctness hazards” and “liveness hazards,” respectively.
thread memory allocation and the Garbage Collector
Chapter three of Duffy’s book, “Threads,” states:
Coincidentally, each .NET program is actually multithreaded from the start because the CLR garbage collector uses a separate finalizer thread to reclaim resources.
We could say then that the CLR uses/provides a thread to remove memory allocations generated by other managed threads. These allocations are partitioned in the Garbage Collector (GC) into generations. The older (higher-number) generations are more likely to be ‘finalized’ than younger ones.
There are two leading disadvantages to the use of the GC:
- several times more memory is required (as much as five times, according to Matthew Hertz and Emery D. Berger (2005))
- noticeable delays when generations reach millions
type safety
Before threads can be scheduled at runtime, the compile time of the Common Language Infrastructure ensures type safety, starting with the Common Type System (CTS) and leading into well-typed rules of covariance and contravariance.