Should I use async or Task to handle a lot of concurrent operations? [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 3 years ago.

Improve this question

I am writing a Windows Service that is going to process a lot of input files.

My question is whether I should use async and await, or if I should create a custom library using Task that could limit the number of concurrent threads.

I know for a fact that if I queue up 200 threads, it takes longer to complete everything than letting 10 run at a time (various fighting for resources, context switching in the CPU, etc, etc)

So my question is whether these new fangled features async and await are any more runtime resilient, or should I just write my own custom library??

Answer 1

If you're doing I/O-based operations, async and await are great. In a Win32 service, you don't have a SynchronizationContext, so all your continuations end up as tasks on the thread pool, which does a great job of load balancing. (Remember, Task != Thread; hundreds or even thousands of Tasks are just fine).

If you're doing CPU-based operations, then I'd recommend the Task Parallel Library. In particular, the Parallel type. PLINQ is sometimes easier to use but it will assume that it can use all cores by default; since you're doing a Win32 service you'd want to be a bit "nicer" (to use Linux terminology).

TPL Dataflow is a great library that takes async/await to the next level. It does sound like your solution could use a TPL Dataflow-based approach. You can also "mix and match" between async, TPL, and TPL Dataflow quite nicely.