I have an interface
interface IFoo
{
Task<Bar> CreateBarAsync();
}
There are two methods to create Bar
, one asynchronous and one synchronous. I want to provide an interface implementation for each of these two methods.
For the asynchronous method, the implementation could look like this:
class Foo1 : IFoo
{
async Task<Bar> CreateBarAsync()
{
return await AsynchronousBarCreatorAsync();
}
}
But HOW should I implement the class Foo2
that uses the synchronous method to create Bar
?
I could implement the method to run synchronously:
async Task<Bar> CreateBarAsync()
{
return SynchronousBarCreator();
}
The compiler will then warn against using async
in the method signature:
This async method lacks 'await' operators and will run synchronously. Consider using the 'await' operator to await non-blocking API calls, or 'await Task.Run(...)' to do CPU-bound work on a background thread.
Or, I could implement the method to explicitly return Task<Bar>
. In my opinion the code will then look less readable:
Task<Bar> CreateBarAsync()
{
return Task.Run(() => SynchronousBarCreator());
}
From a performance point of view, I suppose both approaches have about the same overhead, or?
Which approach should I choose; implement the async
method synchronously or explicitly wrap the synchronous method call in a Task
?
EDIT
The project I am working on is really a .NET 4 project with async / await extensions from the Microsoft Async NuGet package. On .NET 4, Task.Run
can then be replaced with TaskEx.Run
. I consciously used the .NET 4.5 method in the example above in the hope of making the primary question more clear.
When you have to implement an async method from an interface and your implementation is synchronous, you can either use Ned's solution:
With this solution, the method looks async but is synchronous.
Or the solution you proposed:
This way the method is truly async.
You don't have a generic solution that will match all cases of "How to implement interface method that returns Task". It depends on the context: is your implementation fast enough so invoking it on another thread is useless? How is this interface used a when is this method invoked (will it freeze the app)? Is it even possible to invoke your implementation in another thread?
Try this:
Task.FromResult
creates an already completed task of the specified type using the supplied value.To complement others answers, there's one more option, which I believe works with .NET 4.0 too:
Note
task.RunSynchronously()
. It might be the slowest option, compared toTask<>.FromResult
andTaskCompletionSource<>.SetResult
, but there's a subtle yet important difference: the error propagation behavior.The above approach will mimic the behavior of the
async
method, where exception is never thrown on the same stack frame (unwinding it out), but rather is stored dormant inside theTask
object. The caller actually has to observe it viaawait task
ortask.Result
, at which point it will be re-thrown.This is not the case with
Task<>.FromResult
andTaskCompletionSource<>.SetResult
, where any exception thrown bySynchronousBarCreator
will be propagated directly to the caller, unwinding the call stack.I have a bit more detailed explanation of this here:
Any difference between "await Task.Run(); return;" and "return Task.Run()"?
On a side note, I suggest to add a provision for cancellation when designing interfaces (even if cancellation is not currently used/implemented):
If you're using .NET 4.0, you can use
TaskCompletionSource<T>
:Ultimately, if theres nothing asynchronous about your method you should consider exposing a synchronous endpoint (
CreateBar
) which creates a newBar
. That way there's no surprises and no need to wrap with a redundantTask
.