Are TAP and async/await meant to be used for dedicated threads?

Question

I have some number of threads dedicated to one task (receive and handle requests) and some number of threads dedicated to other tasks (long running/CPU intensive tasks). It's a console application.

And I want to use async/await in all of the threads but I learned that async/await uses the managed thread pool to run continuation that means requests handling can be delayed because of a bunch of CPU intensive tasks shown up (yes, so many, it's why i have limited threads count to do this job)?

1. If i want to limit concurrency, then i must not use TAP?
2. If i want to do some job in background for aplication's lifetime, then i must not use TAP either?
3. Should I write a ThradPool implementation with it's own SyncronizationContext to do so?
4. Is there an other way to run continuation in some set of threads?

Answer 1

And I want to use async/await in all of the threads but I learned that async/await uses the managed thread pool to run continuation that means requests handling can be delayed because of a bunch of CPU intensive tasks shown up (yes, so many, it's why i have limited threads count to do this job)?

This is a close-enough analysis. Technically, it's not async / await that needs the thread pool for continuations, but internal TAP method implementations. That said, it is a common pattern in the BCL, and because of this, exhausting the thread pool can cause delays for asynchronous completion.

If i want to limit concurrency, then i must not use TAP?

As long as you don't overwhelm the thread pool, you can use TAP. Limiting concurrency would free up the thread pool, which will enable TAP.

If i want to do some job in background for aplication's lifetime, then i must not use TAP either?

I would think of it more as "don't drown the thread pool in work". An exhausted thread pool isn't great for any kind of work.

Should I write a ThradPool implementation with it's own SyncronizationContext to do so? Is there an other way to run continuation in some set of threads?

You can use SynchronizationContext to control where await resumes executing, but there are still BCL-internal completions that need to queue to the thread pool. There's no controlling that; the only real option is to keep the thread pool free.