Lets say I have a method that is constantly receiving input every 10ms, adds data to a Queue<T>, another thread dequeues and does some processing and writes to a file to keep everything flowing in nicely. The reason for this is because processing will take longer than 10ms.
In updating this method with .Net 4 I would start a new Task with the long running option to ensure a new thread is created. Have a BlockingCollection<T> to add data to and in the task method have the BlockingCollection call GetConsumingEnumerable to process data and write this to file.
Firstly, I’m not entirely sure if I need the Task to create a new thread or not but due to my ignorance this seems the most beneficial way of doing it.
Secondly with the introduction of async and await keywords I could possibly rewrite this again so that when data comes in, call a method marked with async which does processing and then calls await FileStream.WriteAsync. Will this ensure that the data coming in at 10ms apart is handled ok and there is no back log? I have found that these new keywords don’t create new threads but just handles execution in a timely manner somehow.
In my scenario will this be any good to me or should I stick to creating new threads with the long running Task and BlockingCollection?
If you’re receiving input every 10ms and processing takes longer than 10ms, then you will not be able to keep up unless you’re doing parallel processing on the back end.
It sounds like a producer/consumer approach is best for your situation. You can use
BlockingCollection<T>with separate threads/tasks, but you should also consider the Dataflow library (part of the new VS Async support). The Dataflow library allows you to set up a pipeline (or mesh) that defines how your data flows through the system; tasks are automatically created as needed.