Асинхронность не имеет никакого отношения к потокам и к пулу

Дефолтный таск шедулер так и делает, он вызывает enqueue work item https://docs.microsoft.com/en-us/dotnet/api/system.threading.threadpool.queueuserworkitem?view=net-5.0

Это так, дополнение

да, но иногда не доделани таски выполняются на пуле

А где-то можно про это почитать? Конкретно про это решение

когда поток уже не доступен

Ок, прочитаю потом

ну там луче таску засунуть вместо  PLinq

var result = ls.Chunk(ls.Count\5).Select(a=>Task.Run(()=>));
Task.Wait....(result);

о  так

Создание таски достаточно тяжёлое, иногда быстрее будет выполняться без тасок
Зависит от того какой код именно внутри
Если ты всякие факториалы считаешь то таски не нужны, это оверхед

Ну и тогда уж await Task.WhenAll(result)

А не Wait

з таской всьо ок, это просто обгортка, Thread тяжко создавать

а таски можно создаваать впринцепе, они пуляют всьо в пул потоков, это где много потоков запущено (Thread)

кто небудь ему объяснит что асинхронность - это не многопоточность наконец)

Вот именно, это асинхронность
Оно пушит что-то куда-то, что и замедляет выполнение для нетрудного вычислительного кода (про длительные задачи по типу хттп запросов и работы с файлами мы не говорим)
И уж тем более TPL использует thread pool, а thread pool это неэффективный вариант для загрузки всех ядер.
Parallel же в свою очередь это синхронный API
Т.е. мы говорим в разряде синхронность vs асинхронность, ну и ясен пень посчитать 2 в 10й степени создавая таск это оверхед

странный он тип. говорит на джуна не тянет, но рассуждает про серьёзные вещи очень категорично ) и советы раздаёт )