Obscure explanation of the new thread pool in .NET - can anyone clarify?

Question

.NET

From the article regfordev.blogspot.ru/2010/12/thread-pool.html
Paragraph 1:

The new thread pool works in a slightly different way. Each worker thread in the pool has its own local queue. A task that has entered a local queue can spawn a child one, and they are placed in the same local queue. Also, tasks are executed in the local queue in LIFO (last-in-first-out) order, unlike the pool in 3.5, where tasks from the global queue are executed by worker threads in FIFO (first-in-first-out) order. Since only the worker thread cleans up its own heap, or rather has access to its beginning (head), no synchronization is required at the local queue level.

Paragraph 2:

When a worker thread sees that it has nothing else to do, that is, its local queue is empty, it tries to steal a task from another worker thread. But he steals elements from the tail of someone else's local queue.

I'm trying to understand what is meant here. Assume that the situation in paragraph 2 does not happen (all threads will always be busy). That is, as follows from paragraph 1, in this case, if my code executing the parent task (thread #1) creates a new parallel child task through a Task.Run call, then the child task will not actually run in parallel on another thread, but will started on the same thread #1 that queued it, after thread #1 has finished executing the parent task? And in fact, we will get just sequential execution of tasks?
If so, then there is no parallel execution of tasks right there. Why then use Task.Run when you can stupidly just execute the parent and child tasks sequentially with each other in the same thread?
Or is it assumed that the situation when all threads are busy is very rare, and in fact the task from Task.Run will most often be run in a separate thread in parallel?
Or have I misunderstood something at all? Explain.

Answer 1

Everything is simple.
The guys worked with the old mechanism and found out that in the conditions of 100500 tasks per second, it takes too much time to synchronize the access of threads to a single task queue.
In order to resolve such a problem, we decided to divide the global queue into several local ones under overload conditions - so that the worker thread could work with this local queue without using a lock (respectively, without idle waiting for this lock).
That's all. As soon as the local queue ends, work goes on with other people's local queues and with the global queue.
In general, don't sweat it. If you have 10 tasks per second, consider nothing has changed.
And if 100500, then it will take less time to wait for locks. And the performance of the pool in this case will increase.