Is the Channel 9 explanation of Tasks vs. Threads correct?

Question

There's a Channel 9 Video that attempts to explain the difference between Threads and Tasks. I usually like the Channel 9 videos for their technical accuracy, but from my understanding, this one gets some of the key statements wrong.

Here are the statements:

1. @~1:48 to ~2:30: Threads are expensive in memory and time. Each thread gets 1 MB of user mode stack.
2. @~2:30 to 2:37: It also takes time to create threads. Time to allocate the data structures and initialize them.
3. @~2:38 to 2:45: Context switching also takes time.
4. @~2:58 to 3:23 and 3:48 to : Tasks make use of a multi-core system [...] So when you do compute, you're using multiple cores.
5. @~5:02 to 5:30: Threads run on a single core and context switching happens a lot.
6. @~5:40 to 5:51: Threads have different ways to execute. They execute on multiple cores.
7. @~6:20 to 6:30: As you see here in the diagram, Threading has overhead.

And here are my thoughts that I'd like to be confirmed or disproven:

1. The amount of call stack is configurable. That way, the thread limit is not ~1300 but up to 12000 for a 32 bit process. Those who have a copy of SysInternals TestLimit available can try it:

   D:\>testlimit -t -n 64    
   Testlimit v5.04 - test Windows limits
   By Mark Russinovich - www.sysinternals.com
   
   Creating threads with 64 KB stacks...
   Created 12500 threads. Lasterror: 8
   

   The stack size is also exposed in the Thread Constructor for .NET

2. Tasks rely on Threads as a basis. Those threads are taken from the thread pool, but nevertheless, the threads of the thread pool need to be created before they can be used. AFAIK, Mark Russinovich also explained in the Windows Internals book, that the kernel structure (_ETHREAD) is kept in memory for reuse. This minimizes the overhead of allocation and reduces it to initialization.

   I didn't find the exact place I was looking for, but in Windows Internals 6, part 1 it says on page 417:

   [...] the executive thread object might or might not be deallocated.

3. Since Tasks rely on threads as the technical implementation, context switching occurs in any case.

4. If I have 2 threads, they can also be executed on different processors. IMHO that's the whole idea of it.

5. The speaker is taslking about threads on a single core system. IMHO, tasks will have almost no benefit in that case as well. See 4.)

6. See 4. and 5.)

7. The slide may be correct, but it does not show the actual reason for that. The slide it missing the ~15 ms time slices which cause the context switching. The overhead can only be reduced using Tasks if the thread needs to wait for a result.

   In that case, the lower part of the slide is incorrect as well, because the first part of Work 1 seems to be blocking, in which case Work 2 could be executed only. When Work 2 finishes, the condition to continue with Work 1 might be fulfilled. Only if all that occurs within a time slice, Tasks have a benefit.

   In any case, a context switch will occur with Tasks as well, sooner or later.

I have tried confirming my understanding with the help of these questions on SO

• Task vs. Thread differences
• What is the difference between a task and a thread

Above might seem like 7 individual questions. I asked them all in one place because

• the all have their source in one video
• some questions depend on each other
• it's IMHO more important to find the information in one place than following the SO rule of asking one question at a time.

Answer 1

Note: Haven't watched the video, based purely on the info in OP.

The amount of call stack is configurable.

Probably, but not really relevant unless we're getting into very gritty details.

for .NET Tasks rely on Threads as a basis. Those threads are taken from the thread pool, but nevertheless, the threads of the thread pool need to be created before they can be used.

Somewhat correct... though we need to keep a very clear demarcation between abstraction and implementation. Tasks can use the Threadpool in .Net for execution is more correct.

Tasks represent the idea of a self-contained section of code that (usually) can run concurrently of other code. Threads are an OS implementation of similar nature.

Since Tasks rely on threads as the technical implementation, context switching occurs in any case.

Incorrect. While Tasks can be run on threads, and context switching can occur, Tasks contain a layer of abstraction that provides more flexibility.

For example, to swap execution between threads, a context switch must occur in the hardware. To swap execution between tasks, no such hardware context switch must occur. Tasks can be moved between different threads, put to sleep and restored all without a single hardware context switch.

If I have 2 threads, they can also be executed on different processors. IMHO that's the whole idea of it.

Correct.

The speaker is talking about threads on a single core system. IMHO, tasks will have almost no benefit in that case as well.

Incorrect. Tasks run well on single threaded systems as they are simply an abstraction. Furthermore you can run many tasks in a single thread without any hardware-context switches, potentially increasing performance.

---

The main conceptual issue here seems to be the thinking that Task = Thread. This is not the case. A task is a conceptual way of breaking down work. A thread is a implementation of a similar idea with certain behavioral characteristics. While tasks can run on threads under the covers (not necessarily) the abstraction allows them to behave in a very different way than a hardware thread.