I've grasped the concept of async await and have been using it sporadically, but do have a couple questions regarding best practices.
is it ok to use await in a while(condition) loop to keep fetching data that may be present, until the while condition changes, e.g. stopProcessingMessages = false.
in an application such as winforms, while UI runs on it's thread, using async/await on an operation such as a button click is fairly trivial, but what about if I would like to enforce asynchronously throughout an entire console application, or even a windows service. what is the best practice to initially kick off that first await task, would that be Task.Run (() => ... )?
I hope I am making sense in my 2nd question. I want to make the most of async and utilize it to it's full extent, but just need to understand how to kick off the initial asynchronous operation before it bubbles down to all other asynchronous functions.
apologies for not using the proper code blocks I am on the train using my smartphone.
Good morning,
I would rather use a regular task with the TaskCreationOption set to 'LongRunning' in your first scenario than the async/await pattern. This way your whole while block would be executed in one long running task. When using await inside each while loop you would start a new task with every loop - would work, but it's maybe not so optimal ;-)
Regarding your second question, I'm sorry but I don't get your point.
Hope this helps.
It is not ok to use a loop to keep fething data that may be present.. You can create an async call that upon completion will automaticlly invoke a callback method.. the "waiting" phase in that case will happen in the OS mechanisms which treat this waiting phase in optimum way to the OS being used.
Take a look here for further study of the subject: http://msdn.microsoft.com/en-us/library/vstudio/hh191443.aspx
I have an intro to
async
/await
blog post that goes into more detail than most intros and also introduces several best practices.You want to avoid tight loops. So the
while (condition) GetDataIfPresent();
is going to consume a lot of CPU.Alternatively, you could use an
async
method that returnednull
(or whatever) ifstopProcessingMessages
istrue
. In this case, your code would bewhile (true)
, and a more TAP-like solution would be to useCancellationSource
instead of a flag.Also take a look at TPL Dataflow; it sounds like it may be useful for your kind of situation.
For console apps, you could
Wait
on the top-level task. This is an acceptable exception to the usual guideline (which is toawait
instead ofWait
).Wait
ing will burn a thread for the duration of the console app, but that's usually not important enough to warrant a more complex solution. If you do want to install a single-threaded context for your console app, you could useAsyncContext.Run
from my AsyncEx library.For Win32 services, you usually do need to start your own thread. You can use
Task.Run
for this (if you want a multithreaded context), orAsyncContextThread
from AsyncEx (if you want a single-threaded context).