Simple way to get a concurrency issue using async/await

async-concurrency-issue.js

let currentTaskId = 0;

async function promiseMe() {
    return new Promise(resolve => resolve());
}

async function runTask(id) {
    currentTaskId = id;
    await promiseMe();
    if (currentTaskId === id) {
        console.info(`Task ${id} exited successfully.`);
    } else {
        console.info(`Oops! Got invalid state while processing task ${id}.`);
    }
}

function main() {
    runTask(1);
    runTask(2);
}

main();

async-right.js

let currentTaskId = 0;

async function promiseMe() {
    return new Promise(resolve => resolve());
}

async function runTask(id) {
    currentTaskId = id;
    await promiseMe();
    if (currentTaskId === id) {
        console.info(`Task ${id} exited successfully.`);
    } else {
        console.info(`Oops! Got invalid state while processing task ${id}.`);
    }
}

async function main() {
    await runTask(1);
    await runTask(2);
}

main();

Simple way to get a concurrency issue using async-await.md

This is a simple example of how to get a concurrency issue in JavaScript while using async/await.

In the initial example, async-concurreny-issue.js, the main function starts two tasks that were supposed to run asynchronously. The big problem here is that runTask() has side effects and changes an internal state represented by currentTaskId. After going through a function call that requires awaiting on a promise (promiseMe()), the task expects currentTaskId to still have the same id assigned to it a couple of lines above. Even if promiseMe() does actually nothing, it will still execute asynchronously. That should be no problem because we are awaiting on it in runTask(), right? Yeah, but the problem is that main() is not doing its job and await is not being used there. This means that main() fires runTask(2) immediately after calling runTask(1), so it runs before the call to promiseMe() has the chance to return - it can only return in the next event loop tick, since it is behind a promise.

One way to fix it by changing as little code as possible is to turn main() into an async function and make it await on its spawned tasks, like what can be seen in async-right.js.

The example shown here is a simplification of something I saw in real code. With a more complex architecture, spotting this kind of problem can be very difficult. In the real case, I had a class responsible for processing network packets. After processing, the class is supposed to call listeners that had previously asked to be notified whenever the class was done processing a packet. The arrival of a packet is represented by runTask() in the example. To avoid constant memory allocation, the class had an internal buffer that was reused for every packet. The fundamental problem was that this internal buffer was handed to the listeners, which were allowed to read from it. For an extraneous reason, one of the listeners had to await on a promise before it could finish reading the buffer, but the packet processor class was not programmed to await when calling listeners. The promise created by the listerner would thus not be honored by the processor class instance. With this, the arrival of a second packet would end up changing the internal buffer before the listener was able to fully read from the first one, causing the application to malfunction.

Notice that, even though JavaScript code runs in a single thread, concurrency issues can still take place because task executions can be interleaved if you let them (either purposefully or by accident!).