In computer programming, the async/await pattern is a syntactic feature of many programming languages that allows an asynchronous, non-blocking function to be structured in a way similar to an ordinary synchronous function. It is semantically related to the concept of a coroutine and is often implemented using similar techniques, and is primarily intended to provide opportunities for the program to execute other code while waiting for a long-running, asynchronous task to complete, usually represented by promises or similar data structures. The feature is found in C# 5.0,^[1]: 10 C++20, Python 3.5, F#, Hack, Julia, Dart, Kotlin 1.1, Rust 1.39,^[2] Nim 0.9.4,^[3] JavaScript ES2017, Swift 5.5^[4] and Zig,^[5] with some experimental work in extensions, beta versions, and particular implementations of Scala.^[6]

History

F# added asynchronous workflows with await points in version 2.0 in 2007.^[7] This influenced the async/await mechanism added to C#.^[8]

Microsoft released a version of C# with async/await for the first time in the Async CTP (2011). And were later officially released in C# 5 (2012).^[9][1]: 10

Haskell lead developer Simon Marlow created the async package in 2012.^[10]

Python added support for async/await with version 3.5 in 2015^[11] adding 2 new keywords, async and await.

TypeScript added support for async/await with version 1.7 in 2015.^[12]

Javascript added support for async/await in 2017 as part of ECMAScript 2017 JavaScript edition.

Rust added support for async/await with version 1.39.0 in 2019 ^[13] with 1 new keyword async and a lazy eval await pattern.^[14]

C++ added support for async/await with version 20 in 2020 with 3 new keywords co_return, co_await, co_yield.

Swift added support for async/await with version 5.5 in 2021, adding 2 new keywords async and await. This was released alongside a concrete implementation of the Actor model with the actor keyword^[15] which uses async/await to mediate access to each actor from outside.

Example C#

The C# function below, which downloads a resource from a URI and returns the resource's length, uses this async/await pattern:

public async Task<int> FindPageSizeAsync(Uri uri) 
{
    var client = new HttpClient();
    byte[] data = await client.GetByteArrayAsync(uri);
    return data.Length;
}

• First, the async keyword indicates to C# that the method is asynchronous, meaning that it may use an arbitrary number of await expressions and will bind the result to a promise.^{[1]: 165–168}
• The return type, Task<T>, is C#'s analogue to the concept of a promise, and here is indicated to have a result value of type int.
• The first expression to execute when this method is called will be new HttpClient().GetByteArrayAsync(uri),^{[16]: 189–190, 344 [1]: 882} which is another asynchronous method returning a Task<byte[]>. Because this method is asynchronous, it will not download the entire batch of data before returning. Instead, it will begin the download process using a non-blocking mechanism (such as a background thread), and immediately return an unresolved, unrejected Task<byte[]> to this function.
• With the await keyword attached to the Task, this function will immediately proceed to return a Task<int> to its caller, who may then continue on with other processing as needed.
• Once GetByteArrayAsync() finishes its download, it will resolve the Task it returned with the downloaded data. This will trigger a callback and cause FindPageSizeAsync() to continue execution by assigning that value to data.
• Finally, the method returns data.Length, a simple integer indicating the length of the array. The compiler re-interprets this as resolving the Task it returned earlier, triggering a callback in the method's caller to do something with that length value.

A function using async/await can use as many await expressions as it wants, and each will be handled in the same way (though a promise will only be returned to the caller for the first await, while every other await will utilize internal callbacks). A function can also hold a promise object directly and do other processing first (including starting other asynchronous tasks), delaying awaiting the promise until its result is needed. Functions with promises also have promise aggregation methods that allow you to await multiple promises at once or in some special pattern (such as C#'s Task.WhenAll(),^{[1]: 174–175 [16]: 664–665} which returns a valueless Task that resolves when all of the tasks in the arguments have resolved). Many promise types also have additional features beyond what the async/await pattern normally uses, such as being able to set up more than one result callback or inspect the progress of an especially long-running task.

In the particular case of C#, and in many other languages with this language feature, the async/await pattern is not a core part of the language's runtime, but is instead implemented with lambdas or continuations at compile time. For instance, the C# compiler would likely translate the above code to something like the following before translating it to its IL bytecode format:

public Task<int> FindPageSizeAsync(Uri uri) 
{
    var client = new HttpClient();
    Task<byte[]> dataTask = client.GetByteArrayAsync(uri);
    Task<int> afterDataTask = dataTask.ContinueWith((originalTask) => {
        return originalTask.Result.Length;
    });
    return afterDataTask;
}

Because of this, if an interface method needs to return a promise object, but itself does not require await in the body to wait on any asynchronous tasks, it does not need the async modifier either and can instead return a promise object directly. For instance, a function might be able to provide a promise that immediately resolves to some result value (such as C#'s Task.FromResult()^[16]: 656), or it may simply return another method's promise that happens to be the exact promise needed (such as when deferring to an overload).

One important caveat of this functionality, however, is that while the code resembles traditional blocking code, the code is actually non-blocking and potentially multithreaded, meaning that many intervening events may occur while waiting for the promise targeted by an await to resolve. For instance, the following code, while always succeeding in a blocking model without await, may experience intervening events during the await and may thus find shared state changed out from under it:

var a = state.a;
var client = new HttpClient();
var data = await client.GetByteArrayAsync(uri);
Debug.Assert(a == state.a); // Potential failure, as value of state.a may have been changed
                            // by the handler of potentially intervening event.
return data.Length;

Implementations

let asyncSumPageSizes (uris: #seq<Uri>) : Async<int> = async {
    use httpClient = new HttpClient()
    let! pages = 
        uris
        |> Seq.map(httpClient.GetStringAsync >> Async.AwaitTask)
        |> Async.Parallel
    return pages |> Seq.fold (fun accumulator current -> current.Length + accumulator) 0
}

public async Task<int> SumPageSizesAsync(IEnumerable<Uri> uris) 
{
    var client = new HttpClient();
    int total = 0;
    var loadUriTasks = new List<Task<byte[]>>();

    foreach (var uri in uris)
    {
        var loadUriTask = client.GetByteArrayAsync(uri);
        loadUriTasks.Add(loadUriTask );
    }

    foreach (var loadUriTask in loadUriTasks)
    {
        statusText.Text = $"Found {total} bytes ...";
        var resourceAsBytes = await loadUriTask;
        total += resourceAsBytes.Length;
    }

    statusText.Text = $"Found {total} bytes total";

    return total;
}

import asyncio

async def main():
    print("hello")
    await asyncio.sleep(1)
    print("world")

asyncio.run(main())

async function createNewDoc() {
  let response = await db.post({}); // post a new doc
  return db.get(response.id); // find by id
}

async function main() {
  try {
    let doc = await createNewDoc();
    console.log(doc);
  } catch (err) {
    console.log(err);
  }
}
main();

#include <iostream>
#include "CustomAwaitableTask.h"

using namespace std;

CustomAwaitableTask<int> add(int a, int b)
{
    int c = a + b;
    co_return c;
}

CustomAwaitableTask<int> test()
{
    int ret = co_await add(1, 2);
    cout << "return " << ret << endl;
    co_return ret;
}

int main()
{
    auto task = test();

    return 0;
}

#include <stdio.h>
#include "s_task.h"

// define stack memory for tasks
int g_stack_main[64 * 1024 / sizeof(int)];
int g_stack0[64 * 1024 / sizeof(int)];
int g_stack1[64 * 1024 / sizeof(int)];

void sub_task(__async__, void* arg) {
    int i;
    int n = (int)(size_t)arg;
    for (i = 0; i < 5; ++i) {
        printf("task %d, delay seconds = %d, i = %d\n", n, n, i);
        s_task_msleep(__await__, n * 1000);
        //s_task_yield(__await__);
    }
}

void main_task(__async__, void* arg) {
    int i;

    // create two sub-tasks
    s_task_create(g_stack0, sizeof(g_stack0), sub_task, (void*)1);
    s_task_create(g_stack1, sizeof(g_stack1), sub_task, (void*)2);

    for (i = 0; i < 4; ++i) {
        printf("task_main arg = %p, i = %d\n", arg, i);
        s_task_yield(__await__);
    }

    // wait for the sub-tasks for exit
    s_task_join(__await__, g_stack0);
    s_task_join(__await__, g_stack1);
}

int main(int argc, char* argv) {

    s_task_init_system();

    //create the main task
    s_task_create(g_stack_main, sizeof(g_stack_main), main_task, (void*)(size_t)argc);
    s_task_join(__await__, g_stack_main);
    printf("all task is over\n");
    return 0;
}

// In the crate's Cargo.toml, we need `futures = "0.3.0"` in the dependencies section,
// so we can use the futures crate

extern crate futures; // There is no executor currently in the `std` library.

// This desugars to something like
// `fn async_add_one(num: u32) -> impl Future<Output = u32>`
async fn async_add_one(num: u32) -> u32 {
    num + 1
}

async fn example_task() {
    let number = async_add_one(5).await;
    println!("5 + 1 = {}", number);
}

fn main() {
    // Creating the Future does not start the execution.
    let future = example_task();

    // The `Future` only executes when we actually poll it, unlike Javascript.
    futures::executor::block_on(future);
}

func getNumber() async throws -> Int {
    try await Task.sleep(nanoseconds: 1_000_000_000)
    return 42
}

Task {
    let first = try await getNumber()
    let second = try await getNumber()
    print(first + second)
}

Benefits and criticisms

A significant benefit of the async/await pattern in languages that support it is that asynchronous, non-blocking code can be written, with minimal overhead, and looking almost like traditional synchronous, blocking code. In particular, it has been argued that await is the best way of writing asynchronous code in message-passing programs; in particular, being close to blocking code, readability and the minimal amount of boilerplate code were cited as await benefits.^[37] As a result, async/await makes it easier for most programmers to reason about their programs, and await tends to promote better, more robust non-blocking code in applications that require it. Such applications range from programs presenting graphical user interfaces to massively scalable stateful server-side programs, such as games and financial applications.

When criticising await, it has been noted that await tends to cause surrounding code to be asynchronous too; on the other hand, it has been argued that this contagious nature of the code (sometimes being compared to a "zombie virus") is inherent to all kinds of asynchronous programming, so await as such is not unique in this regard.^[21]

See also

• Coroutines
• Continuation-passing style
• Direct style
• Cooperative multitasking

References