I am looking to wrap synchronous methods into asynchronous code in order to expose those methods as asynchronous - the reason is I do not want to duplicate the code inside the synchrnous methods as I would like it to be DRY and already knowing the functionality of the syunchronous code works - no need to manage separate method as well. However I would like asynchronous methods. I understand the purpose of asynchronous methods at least what they do and why I would want to use them.
Consider the following code:
public int AddValues(int a, int b)
{
// some really boring or extremely long DRY method code
return a + b;
}
Adding an Asynchronous Calling Method like below
saves time writing code ; Ensures the functionality of the inner code is the same as Synchronous code.
Could I or Should I do this?:
public async task AddValuesAsync(int a, int b)
{
return await Task.FromResult(AddValues(a,b));
}
And here is my other question and maybe an answer to me;
Calling the Asynch method twice will also call the sync method - and since it is behind the async I can get a cross thread exception ? IS that correct.
So what should I do in this situation - how to keep it DRY and keep it simple?
I could make the sync method private and force all calls to the method be Async ..
If you say my example code is a bad way to do it, please give a short reason why and a simple example of a good way to do it ..and any suggestions on what is best and how to do this ?
I have looked here
Is wrapping a synchronous call in a Task.Run() to make it asynchronous beneficial?
but that does not seem to answer very clearly , what I would like to know.
EDIT
For others who are looking - aside from the answer marked here is info that points to the answer with examples and also more importantly why.
Should I expose asynchronous wrappers for synchronous methods?
Which way is best for wrapping synchronous code into an asynchronous method?
I am asking this because I would like to know what the proper way is to make a synchronous methods to have asynchronous versions in a class and as DRY as possible.
The proper way is "don't".
More to the point, your API's shouldn't lie. If they're doing synchronous work, they should have a synchronous signature.
After comments by Stephen Cleary I found a link on related.. What is the best way for wrapping synchronous code into asynchronous method
While not worded exactly - one comment included an article link that was worded exactly to one point of my question.
The comment there by Yuval Itzchakov included this.
"There is great article called Should I expose asynchronous wrappers for synchronous methods? by Stephan Toub which talks about all the reasons not to do what you're trying to do. I suggest reading it."
Related
I'd like to wrap the WebClient.DownloadFileAsync method, which is actually non blocking, into a method which returns a Task and can be awaited until the download is completed.
I understand the logic behind suscribing to the DownloadFileCompleted event, as explained here (and in plenty other posts) but I'd like to wrap it into something more user friendly. And my knowledge of asynchronous programming is quite superficial.
The best I can think of is to wrap DownloadFile method (synchronous) into a Task and returns it , but I've read many times that wrapping a synchronous method onto a an asynchronous one is not a good practice
return Task.Run(() =>client.DownloadFile(fileUri, localPath));
It's actually the first time I meet an async method which is non awaitable, is there a reason why it has been thought this way?
Thanks
As per #JonSkeet's comment above, the answer is :
The method DownloadFileAsync has been thought long before await/async was implemented
The method I was looking for is called DownloadFileTaskAsync, a straightforward async file downloader, and there is no need to rewrite a wrapper
I have been researching how to convert my (synchronous) algorithms into asynchronous ones. (TAP)
First, just to be clear, this question is not about "what is Async and Await does" ( I already have read the excellent posts of Stephen Cleary , for example Async and Await (If anyone is interested read the link- it is very informative)
I have also read already the chapter on concurrency of "C# in a nutshell".
This question is not about how async functions use await to call functions either. I already know that.
Unfortunately in almost all the things I read, the await Task.Delay(10) is used to "make a asynchronous function". For example:
public async Task<int> GetResult()
{
int result= await GiveMeTheInt();
}
public async Task<int> GiveMeTheInt() //<--is async needed here? (oops! I just realize it is...
{
await Task.Delay(100);
return(10);
}
In this example for instance I already understand the magic of async await in the GetResult() function but the implementation of GiveMeTheInt() is not very useful.(They just put a Delay as a generic asynchronous function and leave it at that)
So my question is about the "GiveMeTheInt"-type of questions (not the ones who call them).
The question
If I have an algorithm written in a function that so far has been synchronous, how can I convert this to be used asynchronously?
This is not a duplicate question, the closest I have found is Turning a Syncronous method async in which the poster is told to use a async version of his method that already exists. In my case, this does not exist.
My algorithms consist mainly of Image processing so in essence scanning a large array and changing the values of each pixel. Something like
void DoSomethingToImage(int[,] Image)
{
for(int i=0;i<width;i++)
for(int j=0;j<height;j++)
{
Image[i,j]=255;
}
}
(This is a fictional example, the operation is different of course)
The closest I have gotten an answer to this is to put the function inside a Task.Run() but I am not sure if this is the way to do it.
Any help will be greatly appreciated
So take a look at your method:
void DoSomethingToImage(int[,] image)
{
for (int i = 0; i < width; i++)
{
for (int j = 0; j < height; j++)
{
image[i, j] = 255;
}
}
}
Is this asynchronous? Obviously not. This is just CPU-bound work that will keep the processor busy for a bit. As such, it is not a good candiate to make asynchronous on its own. It should be run synchronously.
What if you are consuming this from an asynchronous part of the application? You certainly don’t want the user interface to block because you are iterating through a lot of pixels. So the solution is to load the work off to another thread. You do that using Task.Run:
await Task.Run(() => DoSomethingToImage(image));
So you would write that whenever you call the DoSomethingToImage method from an asynchronous method. Now, if you only use that method inside asynchronous contexts, you could argue that it might make sense to move the Task.Run into the function:
Task DoSomethingToImageAsync(int[,] image)
{
return Task.Run(() => { … });
}
Is this a good idea? In general no, because now you are making the method look asynchronous when it’s in fact not. All it does is spawn a new thread that does the work, and then it waits for the thread to complete. So now you are hiding that part and also make a method doing highly synchronous work decide that a thread should be started. That’s rarely a good idea. And there is nothing wrong with keeping the method as it is, to show that it’s synchronous, and make the calling code responsible of deciding how that code should be run.
If I have an algorithm written in a function that so far has been synchronous, how can I convert this to be used asynchronously?
So, coming back to your actual question, this is actually difficult to answer. The answer is probably just this: “It depends”.
If a method does CPU-bound work, you’re better off keeping it synchronous and let calling code decide how to run it. If you are doing mostly I/O work where you interact with other interfaces (network, file system, etc.), then that’s a good candidate for making it asynchronous, especially considering that many of those interfaces will already offer asynchronous ways to communicate with them.
One final note regarding your “is async needed here?” question in your code: You need the async keyword whenever you want to use await inside of it. The mere presence of the async keyword does not make a method asynchronous though (not even the return type does indicate that).
So here I have a function
static bool Login(SignupData sd)
{
bool success=false;
/*
Perform login-related actions here
*/
}
And there is another function
static Task<bool> LoginAsync(SignupData sd)
{
return Task.Run<bool>(()=>Login(sd));
}
Now, I've come across a rather different implementation of this pattern, where you would add the async keyword to a function which returns Task<TResult> (so that it ends up looking like: async Task<TResult> LoginAsync(SignupData sd)). In this case, even if you return TResult instead of a Task<TResult>, the program still compiles.
My question here is, which implementation should be prefered?
static Task<bool> LoginAsync(SignupData sd)
{
return Task.Run<bool>(()=>Login(sd));
}
OR this one?
async static Task<bool> LoginAsync(SignupData sd)
{
bool success=Login(sd);
return success;
}
You shouldn't be doing either. Asynchronous methods are useful if they can prevent threads from being blocked. In your case, your method doesn't avoid that, it always blocks a thread.
How to handle long blocking calls depends on the application. For UI applications, you want to use Task.Run to make sure you don't block the UI thread. For e.g. web applications, you don't want to use Task.Run, you want to just use the thread you've got already to prevent two threads from being used where one suffices.
Your asynchronous method cannot reliably know what works best for the caller, so shouldn't indicate through its API that it knows best. You should just have your synchronous method and let the caller decide.
That said, I would recommend looking for a way to create a LoginAsync implementation that's really asynchronous. If it loads data from a database, for instance, open the connection using OpenAsync, retrieve data using ExecuteReaderAsync. If it connects to a web service, connect using the asynchronous methods for whatever protocol you're using. If it logs in some other way, do whatever you need to make that asynchronous.
If you're taking that approach, the async and await keywords make perfect sense and can make such an implementation very easy to create.
While HVD is correct, I will dive into async in an attempt to describe its intended use.
The async keyword, and the accompanying await keyword is a shortcut method of implementing non blocking code patterns within your application. While it plays along perfectly with the rest of the Task Parallel Library (TPL), it isn't usually used quite the same. It's beauty is in the elegance of how the compiler weaves in the asynchronicity, and allows it to be handled without explicitly spinning off separate threads, which may or may not be what you want.
For Example, let's look at some code:
async static Task<bool> DoStuffAsync()
{
var otherAsyncResult = doOtherStuffAsync();
return await otherAsyncResult
}
See the await keyword? It says, return to the caller, continue on until we have the result you need. Don't block, don't use a new thread, but basically return with a promise of a result when ready (A Task). The calling code can then carry on and not worry about the result until later when we have it.
Usually this ends up requiring that your code becomes non-blocking the whole way down (async all the way as it were), and often this is a difficult transition to understand. However, if you can it is incredibly powerful.
The better way to handle your code would be to make the synchronous code call the async one, and wait on it. That way you would be async as much as possible. It is always best to force that level as high as possible in your application, all the way to the UI if possible.
Hope that made sense. The TPL is a huge topic, and Async/Await really adds some interesting ways of structuring your code.
https://msdn.microsoft.com/en-us/library/hh191443.aspx
I have been reading lots about Task lately, and I have to say I thought I understood it but once you read blogs by Stephen Cleary and Jon Skeet I have started to realize that there is more to it than one thinks.
So, I am implementing an interface that's based on TASK (this is not my interface its part of AspNet.Identity IUserPasswordStore ), Is this the correct way to implement this ?
public Task<bool> HasPasswordAsync(ApplicationUser user)
{
return Task.Factory.StartNew(() => true);
}
This is kinda a trivial question, but you never know they might be an "ah, but did you know that this will do"
The rest of the code is all grown from async code so kinda just writes its self, well sort of , I need to convert begin/end pattern to TAP.
You didn't read well enough :)
In any case, when you just want to wrap a result in a finished task, there's no need to spin up new threadpool work. Just use
Task.FromResult(false)
For this case, it's okay to expose the Task in an interface. However, if you were to just use Task.Run or similar, don't. That's exactly the kind of things you'll find on Stephen's blog as "bad ideas". If your interface seems wide enough to accomodate things that are inherently asynchronous and at the same time inherently synchronous, you probably need to narrow your interfaces down.
I am implementing an interface that's based on TASK , Is this the
correct way to implement this ?
Generally speaking, no. You shouldn't expose async wrappers over sync methods.
Why shouldn't you do so? because it may confuse the end user which believes your method is purely an async IO bound operation (as that is what most of the BCL exposes for us), but will be surprised to see that it actually isn't.
That is why the recommended approach is to let the user explicitly invoke the synchronous version on a new thread.
Instead, do this:
public bool HasPassword(ApplicationUser user)
{
return true;
}
And let him delegate it:
var hasPassword = Task.Run(() => HasPassword(user));
I'm facing the problem of designing methods that with performs network I/O (for a reusable library). I've read this question
c# 5 await/async pattern in API design
and also other ones closer to my issue.
So, the question is, if I want provide both async and non-async method how I've to design these?
For example to expose a non-async version of a method, I need to do something like
public void DoSomething() {
DoSomethingAsync(CancellationToken.None).Wait();
}
and I feel it's not a great design. I'd like a suggestion (for example) on how to define private methods that can be wrapped in public ones to provide both versions.
If you want the most maintainable option, only provide an async API, which is implemented without making any blocking calls or using any thread pool threads.
If you really want to have both async and synchronous APIs, then you'll encounter a maintainability problem. You really need to implement it twice: once async and once synchronous. Both of those methods will look nearly identical so the initial implementation is easy, but you will end up with two separate nearly-identical methods so maintenance is problematic.
In particular, there's a no good and simple way to just make an async or synchronous "wrapper". Stephen Toub has the best info on the subject:
Should I expose asynchronous wrappers for synchronous methods?
Should I expose synchronous wrappers for asynchronous methods?
(the short answer to both questions is "no")
However, there are some hacks you can use if you want to avoid the duplicated implementation; the best one is usually the boolean argument hack.
I agree with both Marc and Stephen (Cleary).
(BTW, I started to write this as a comment to Stephen's answer, but it turned out to be too long; let me know if it is OK to write this as an answer or not, and feel free to take bits from it and add it to Stephen's answer, in the spirit of "providing the one best answer").
It really "depends": like Marc said, it is important to know how DoSomethingAsync is asynchronous. We all agree that there is no point in having a the "sync" method call the "async" method and "wait": this can be done in user code. The only advantage of having a separate method is to have actual performance gains, to have an implementation which is, under the hood, different and tailored to the synchronous scenario. This is especially true if the "async" method is creating a thread (or taking it from a threadpool): you end up with something that underneath uses two "control flows", while "promising" with its synchronous looks to be executed in the callers' context. This may even have concurrency issues, depending on the implementation.
Also in other cases, like the intensive I/O that the OP is mentioning, it may be worth having two different implementation. Most operating systems (Windows for sure) have for I/O different mechanisms tailored to the two scenarios: for example, async execution of and I/O operation takes great advantages from OS level mechanisms like I/O completion ports, which add a little overhead (not significant, but not null) in the kernel (after all, they have to do bookkeeping, dispatch, etc.), and more direct implementation for synchronous operations.
Code complexity also varies a lot, especially in functions where multiple operations are done/coordinated.
What I would do is:
have some examples/test for typical usage and scenarios
see which API variant is used, where, and measure. Measure also difference in performance between a "pure sync" variant and "sync". (not for the whole API, but for selected few typical cases)
based on measurement, decide if the added cost is worth it.
This mainly because two goals are somehow in contrast with one another. If you want maintainable code, the obvious choice is implementing sync in terms of async/wait (or the other way around) (or, even better, provide only the async variant and let the user do "wait"); if you want performance you should implement the two functions differently, to exploit different underlying mechanisms (from the framework or from the OS). I think that it should not make difference from a unit-testing point of view how you actually implement your API.
I ran into the same problem but managed to find a compromise between efficiency and maintainability using two simple facts about async methods:
asynchronous method which does not execute any await is synchronous;
asynchronous method which awaits only synchronous methods is synchronous.
This is better to be shown on example:
//Simple synchronous methods that starts third party component, waits for a second and gets result.
public ThirdPartyResult Execute(ThirdPartyOptions options)
{
ThirdPartyComponent.Start(options);
System.Threading.Thread.Sleep(1000);
return ThirdPartyComponent.GetResult();
}
To provide maintainable sync/async version of this method it has been split to three layers:
//Lower level - parts that work differently for sync/async version.
//When isAsync is false there are no await operators and method is running synchronously.
private static async Task Wait(bool isAsync, int milliseconds)
{
if (isAsync)
{
await Task.Delay(milliseconds);
}
else
{
System.Threading.Thread.Sleep(milliseconds);
}
}
//Middle level - the main algorithm.
//When isAsync is false the only awaited method is running synchronously,
//so the whole algorithm is running synchronously.
private async Task<ThirdPartyResult> Execute(bool isAsync, ThirdPartyOptions options)
{
ThirdPartyComponent.Start(options);
await Wait(isAsync, 1000);
return ThirdPartyComponent.GetResult();
}
//Upper level - public synchronous API.
//Internal method runs synchronously and will be already finished when Result property is accessed.
public ThirdPartyResult ExecuteSync(ThirdPartyOptions options)
{
return Execute(false, options).Result;
}
//Upper level - public asynchronous API.
public async Task<ThirdPartyResult> ExecuteAsync(ThirdPartyOptions options)
{
return await Execute(true, options);
}
The main advantage here is that middle level algorithm which is most likely to change is implemented only once so developer don't have to maintain two almost identical pieces of code.