AsyncCTP: Creating a class that is IAwaitable - c#

I found myself wanting to implement an IAwaitable class (something that implements asynchronous calls without blocking threads).
I've got the most recent version of AsyncCTP installed, and the compiler is saying that I need an IsCompleted() member. Okay, so the CTP preview has moved on a little bit (I get that, like it's a preview)
Question: What interface are the AsyncCTP language extensions expecting now?
Question: In all this I'm assuming that I can signal to the "IAwaitable" via a lamda/delegate? Is this possible? Do we call EndAwait? The intellisense suggests that you call EndAwait to retrieve the result... so that doesn't sound right. Any ideas?
All of the examples I've found so far are for features that the AsyncCTP library has already implemented such as:
await new WebClient().DownloadStringTaskAsync(uri).ConfigureAwait(false);
from the 101 AsyncSamplesCS
Background:
I find myself on Jon Skeets page (again) looking at this example
using System;
class Test
{
static async void Main()
{
await new Awaitable();
}
}
class Awaitable
{
public Awaiter GetAwaiter()
{
return new Awaiter();
}
}
class Awaiter
{
public bool BeginAwait(Action continuation)
{
return false;
}
public int EndAwait()
{
return 1;
}
}

With the SP1 refresh, you need:
Some GetAwaiter() method (possibly but not necessarily an extension method) that returns something (Awaiter in your example) with all of:
A bool IsCompleted property (get)
A void OnCompleted(Action callback)
A GetResult() method which returns void, or the desired outcome of the awaited operation
However, I suggest you look at TaskCompletionSource<T> - I looked at this, and it out-performed my naive implementation (here; obsolete). You can also use it for void tasks, by using something like a TaskCompletionSource<bool> (and exploit the fact that the Task<bool> is also an untyped Task).

Related

Is there any way to know if a method is running being awaited from within the method?

I'm a university student but, since I like programming, I try to create a library of code that's been useful to me (something like a code base).
In the process of doing this, I started designing/writing an asynchronous method that's about to be used for interlocking a variable. My goal is to produce different result when this method is being awaited (runs synchronously) and when it isn't.
An example could be the following:
private int _lock;
public async Task<bool> Lock()
{
if (method_is_not_being_awaited)
return Interlocked.Exchange(ref _lock, 1) == 0;
while (0 != Interlocked.Exchange(ref _lock, 1)) {}
return true;
}
Is there any way to achieve such result? If yes, how?
ps: I know that I could make 2 different methods bool lock() and async Task<bool> lockAsync() but, that's not what I ask for
No, it is not possible to do what you want because method must return value before any operation on result (including await) can be performed. It is not specific to async methods but rather how all code behaves in C# (and pretty much any other language).
On other hand it is pretty easy to do something that very close to what you ask - synchronously return value as soon as one tries to await the result of the method: await is essentially just call to GetAwaiter on the result and you can wire it up to alter state of your method.
Note that you can't really know what to do if method ever awaited anyway - so while you can act at moment when await is called you really can't know in advance if you should start asynchronous processing. So the best you can achieve is to do nothing in synchronous part, start asynchronous processing anyway and instantly return result when await is called (aborting/ignoring asynchronous part of the method).
Details on implementing class that can be used as result can be found in https://www.codeproject.com/Articles/5274659/How-to-Use-the-Csharp-Await-Keyword-On-Anything and https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/async/task-asynchronous-programming-model.
Skeleton code below shows how to implement method that does nothing unless await is called:
class MyTask
{
public MyAwaitable GetAwaiter()
{
return new MyAwaitable();
}
}
class MyAwaitable : INotifyCompletion
{
public bool IsCompleted
{
get { return true; }
}
public int GetResult()
{
return 42; // this is our "result" from method.
}
public void OnCompleted (Action continuation)
{
// just run instantly - no need to save callback as this one is
// always "completed"
continuation();
}
}
MyTask F()
{
// if your really want you can start async operation here
// and somehow wire up MyAwaitable.IsComplete to terminate/abandon
// asynchronous part.
return new MyTask();
}

System.Threading.Channels ReadAsync() method is blocking execution

Overview
I am attempting to write an IAsyncEnumerable<T> wrapper around an IObserver<T> interface. At first I used a BufferBlock<T> as the backing data store, but I found out through performance testing and research that it is actually a pretty slow type, so I decided to give the System.Threading.Channels.Channel type a go. I had a similar problem with my BufferBlock implementation as this one but this time I'm not sure how to resolve it.
Problem
My GetAsyncEnumerator() loop gets blocked by the await _channel.Reader.WaitToRead(token) call if my IObserver<T>.OnNext() method hasn't written to the _channel yet. What is the correct way to wait for a value to be available to yield in this context without blocking program execution?
Implementation
public sealed class ObserverAsyncEnumerableWrapper<T> : IAsyncEnumerable<T>,
IObserver<T>, IDisposable
{
private readonly IDisposable _unsubscriber;
private readonly Channel<T> _channel = Channel.CreateUnbounded<T>();
private bool _producerComplete;
public ObserverAsyncEnumerableWrapper(IObservable<T> provider)
{
_unsubscriber = provider.Subscribe(this);
}
public async void OnNext(T value)
{
Log.Logger.Verbose("Adding value to Channel.");
await _channel.Writer.WriteAsync(value);
}
public void OnError(Exception error)
{
_channel.Writer.Complete(error);
}
public void OnCompleted()
{
_producerComplete = true;
}
public async IAsyncEnumerator<T> GetAsyncEnumerator(
[EnumeratorCancellation] CancellationToken token = new CancellationToken())
{
Log.Logger.Verbose("Starting async iteration...");
while (await _channel.Reader.WaitToReadAsync(token) || !_producerComplete)
{
Log.Logger.Verbose("Reading...");
while (_channel.Reader.TryRead(out var item))
{
Log.Logger.Verbose("Yielding item.");
yield return item;
}
Log.Logger.Verbose("Awaiting more items.");
}
Log.Logger.Verbose("Iteration Complete.");
_channel.Writer.Complete();
}
public void Dispose()
{
_channel.Writer.Complete();
_unsubscriber?.Dispose();
}
}
Additional Context
It shouldn't matter, but at runtime the IObservable<T> instance passed into the constructor is a CimAsyncResult returned from async calls made to the Microsoft.Management.Infrastructure apis. Those make use of the Observer design pattern which I'm trying to wrap with the fancy new async enumeration pattern.
Edit
Updated with logging to the debugger output and made my OnNext() method async/await as one commenter suggested. You can see it never enters the while() loop.
Further up the call stack I was calling the async method syncronously via the GetAwaiter().GetResult() methods.
Yup, that's a problem.
I did this because in once case I wanted to get the data from within a constructor. I changed that implementation to execute the call using Task.Run() and now the iterators run flawlessly with both implementations.
There are better solutions than blocking on asynchronous code. Using Task.Run is one way to avoid the deadlock, but you still end up with a sub-par user experience (I'm assuming yours is a UI application, since there is a SynchronizationContext).
If the asynchronous enumerator is used to load data for display, then a more proper solution is to (synchronously) initialize the UI to a "Loading..." state, and then update that state as the data is loaded asynchronously. If the asynchronous enumerator is used for something else, you may find some appropriate alternative patterns in my async constructors blog post.

What is async in System.Data.Common.DbDataReader.ReadAsync?

I am looking at the code for DbDataReader (also DbCommand) at MS reference and can't figure out what is async in ReadAsync() method.
virtual public Task<bool> ReadAsync(CancellationToken cancellationToken) {
if (cancellationToken.IsCancellationRequested) {
return ADP.CreatedTaskWithCancellation<bool>();
}
else {
try {
return Read() ? ADP.TrueTask : ADP.FalseTask;
}
catch (Exception e) {
return ADP.CreatedTaskWithException<bool>(e);
}
}
}
The ReadAsync method just calls Read method and returns a complete task.
Doesn't this block the calling thread the same way as calling Read directly?
I have noticed the same pattern in DbCommand ExecuteReaderAsync and other methods. They just call the sync versions and return completed Tasks.
What am I missing here?
UPDATE: I did not miss anything, as #PeterBons explained nicely (also in the documentation). I still don't like it, but that's my problem.
You are looking at a virtual method in an abstract class. If you want (future) implementations to be able to do some truly async work you will have to define a method signature that allows that. So it should return a Task or Task<T>. Remember that just using a Task does not make anything asynchronous, it makes it awaitable.
The use of the Task<bool> return type in this example virtual method is to facilitate other classes that derive from DbDataReader to provide real async behavior in their implementation of ReadAsync.
For example, a truly async implementation could do something like
class TrueAsyncReader : DbDataReader
{
...
public override async Task<bool> ReadAsync(CancellationToken cancellationToken)
{
...
return await ReadFromDbAsync();
}
}
As you can see you can now have async and non async implementations, without having to alter the method signature.
Since you can easily call synchronous code from an async method this is the way to go. Calling async code from a synchronous method is a nog go.
for non async implementations that need to return a task you can return something like Task.FromResult<T> or Task.CompletedTask. This will not block.
See also await Task.CompletedTask for what?
To summarize: the default implementation does not do anything async but derived classes can without having to change the method signature.

How do you handle a 3rd party interface returning Task if you don't have any async code? [duplicate]

This question already has answers here:
How to implement interface method that returns Task<T>?
(4 answers)
Closed 6 years ago.
I am working with a third-party dll which exposes methods which return Task and Task<T>. I don't have any control over this assembly or the interface, and I assume the author assumed everything would need to be async since the naming of the methods are *Async() as shown below.
Given that, how do I properly implement the interface if I don't actually have any asynchronous code running?
public interface IFoo
{
Task DoWorkAsync();
Task<int> GetValueAsync();
}
My attempt was the following:
public class FooBar : IFoo
{
public async Task DoWorkAsync()
{
// Do Some Work
await Task.Yield();
}
public async Task<int> GetValueAsync()
{
// Do Some Work
var result = ...;
return Task.FromResult(result);
}
}
Additionally:
Was the author correct in exposing only methods that returned Task/Task<T>?
Was the author correct in suffixing method names with *Async()? Code analysis doesn't complain if I write an async method without appending Async to the name.
If you don't have async work to do don't include the async keyword. Your GetValueAsnyc function was almost correct, you just needed to drop the async. For your DoWorkAsync you should just not mark the method async and return a completed task.
public class FooBar : IFoo
{
public Task DoWorkAsync()
{
// Do Some Work
//If you can use .NET 4.6
return Task.CompletedTask;
//For older versions, the thing you pass in does not matter, I like to use bool.
return Task.FromResult(false);
}
public Task<int> GetValueAsync()
{
// Do Some Work
var result = ...;
return Task.FromResult(result);
}
}
However, if your code is slow and you end up blocking the UI for a long period of time I would consider looking in to if you can re-write your code as actually being async or perhaps wrapping the code in to a background thread, but I would only do a background thread if it was a last resort.

Metro - write async c# operation and call from javascript

I have create a metro app which is composed by
- a c# windows runtime component
- a javascript application, wich contains the UI and is the main application.
In the c# component I created an async method:
async public void createDocument() {
}
but when I try to call it from the javascript code, I cannot use the .done() or the then() function to handle the method completed evet, because there is an error: javascript error, cannot call done() from object not set to an instance of object.
If I try to assign Task or Task to the function I have another error, which tell me Task is not a windows runtime type and to use IAsyncOperation, IAsyncAction, ecc.. instead.
So, how can I create an async function in the c# windows runtime component and call it from javascript handling the done() or then() events?
I found an article that seems to be related to the problem you are having. I haven't done this myself, but the gist of it says that you can't use the async keyword from C# for Javascript promises - you must wrap the method in a slightly different way:
instead of:
public sealed class Class1
{
public async void testAsync()
{
// do this asynchronously ...
}
}
try:
public sealed class Class1
{
public IAsyncActionWithProgress<Result> testAsync()
{
return AsyncInfo.Run<Result>((token, result) =>
Task.Run<Result>(()=>
{
// do this asynchronously ...
return new Result();
}
));
}
}
public sealed class Result { ... }
}
I copied and pasted the examples from this article by Ronald Widha - http://www.ronaldwidha.net/2012/05/10/winrt-consumer-preview-calling-c-csharp-async-class-libraries-from-javascript-winjs-promises-using-then-clause/ It was written during the consumer preview, so it might have changed between then and the final release
Hopefully that will help you a bit more!
Just for information, if you need to call asyncronous methods inside the procedure, you need to use:
public static IAsyncOperation<IList<string>> DownloadAsStringsAsync(string id)
{
return Task.Run<Type retourned>(async () =>
{
var data = await AsyncMethod(...);
return (somethingOfTypeRetourned;
}).AsAsyncOperation();
}

Categories