async and await in JavaScript: event loop and races

Problem

The last item, sold twice

The sale is in full swing. One pair of headphones is left. checkout checks the stock, waits for the bank to confirm the payment and only then decreases the stock. Two buyers press "Buy" at the same moment:

// The bank confirms the payment in 100 ms.
async function pay(buyer) {
  await sleep(100);
}

let stock = 1;
let sold = 0;

async function checkout(buyer) {
  const left = stock;
  if (left === 0) return;
  await pay(buyer);
  stock = left - 1;
  sold++;
}

await Promise.all([checkout("Ann"), checkout("Bob")]);
console.log(`Sold: ${sold}, stock: ${stock}`);

Sold: 2, stock: 0

Two are sold, and there is one item. One buyer will get an e-mail "Your order has been shipped" for headphones that do not exist.

In JavaScript this looks impossible: the code runs in one thread. In the lesson on race conditions two threads collided on count++. Here there is no second thread.

The output is the same on every run: this is not bad luck, it is the order in which the code runs. To see it, we need to know what await does.

The idea

One thread and many waits

Most of the work in an online shop is work that waits (see work that waits and work that computes): the payment waits for the bank, the e-mail waits for the mail server, the stock waits for the warehouse. A thread that sits and waits is wasted.

An event loop is one thread and a queue of pieces of code that are ready. The thread takes the next piece and runs it to the end. When the code reaches a wait, it does not hold the thread: it says "wake me up when the bank answers" and lets go. The thread takes the next ready piece. When the bank answers, the rest of the function (the continuation) goes into the queue and waits for its turn.

In Node the event loop is built in. await is exactly that place: the function stops, the thread is free, and the continuation will go into the queue when the promise is ready. Timers, the network and files wait outside your JavaScript.

Three requests to three services, started at once:

let waiting = 0;
let most = 0;

async function call(name, ms) {
  waiting++;
  most = Math.max(most, waiting);
  await sleep(ms);
  waiting--;
  console.log(`${name}: done after ${ms} ms`);
}

await Promise.all([
  call("payment", 300),
  call("e-mail", 100),
  call("warehouse", 200),
]);
console.log(`Waiting at once: ${most}`);

e-mail: done after 100 ms
warehouse: done after 200 ms
payment: done after 300 ms
Waiting at once: 3

Each call runs up to await sleep(ms) and returns a promise. Promise.all waits for all three.

"Waiting at once: 3": all three requests wait at the same time, and there is only one thread. Everything takes about 300 ms (the longest), not 600 (the sum). The thread did not wait for any of them.

Try it

How many wait at once

The same call, but the first request is awaited on its own:

What will the program print?

await call("payment", 300);
await Promise.all([call("e-mail", 100), call("warehouse", 200)]);
console.log(`Waiting at once: ${most}`);

Answer

payment: done after 300 ms
e-mail: done after 100 ms
warehouse: done after 200 ms
Waiting at once: 3

payment: done after 300 ms
e-mail: done after 100 ms
warehouse: done after 200 ms
Waiting at once: 2

e-mail: done after 100 ms
warehouse: done after 200 ms
payment: done after 300 ms
Waiting at once: 3

The first await call(...) waits for the payment to the end. Only after that does Promise.all start the other two at once, so the most is 2. The whole thing takes about 500 ms.

await right after the call means "wait for this before you go on". For them to wait together, start them all first, then wait.

See it

A race between two awaits

Back to the last item. This is how the two orders interleave:

let stock = 1;
let sold = 0;

async function checkout(buyer) {
  const left = stock;
  if (left === 0) return;
  await pay(buyer);
  stock = left - 1;
  sold++;
}

Step by step, in words

One item is left. Two orders arrive at the same moment: Ann and Bob.
Ann's checkout reads the stock: left is 1. At await it lets go of the thread while the bank answers.
The thread is free, so Bob's checkout runs. It reads 1 as well: Ann has not written anything yet.
The bank answers Ann. Her code goes on after the await: stock = left - 1 = 0, sold = 1. Correct so far.
Bob goes on with his old left = 1: stock = 0 again, sold = 2. One item, two sales, with only one thread.

Between two awaits the code runs without interruption. But at an await the function lets go of the thread, and meanwhile anything else can run. When it goes on, the world may be different: left is a value read before the wait.

This is the same "read, change, write" as with threads, only the interruption is not just anywhere, it is exactly at the await. That is also why the output is the same on every run: the interruption is not random.

The idea

The fix: reserve the item before the await

The check and the decrease must be one piece of code with no await between them. The order reserves the item at once and only then waits for the bank:

let stock = 1;
let sold = 0;

async function checkout(buyer) {
  if (stock === 0) return;
  stock--;   // reserve the item before the await
  await pay(buyer);
  sold++;
}

Sold: 1, stock: 0

There is no await between if (stock === 0) and stock--, so no other order can get in between. Bob sees 0 and leaves.

If the payment fails, the item must be returned. That is the exercise at the end.

More precisely, if you are curious

Sometimes the whole piece must be locked together with the wait: for example, only one order at a time may write to an old warehouse system that cannot take two. Then you need a lock that understands await:

Node has none built in. You write one with a promise (a queue of waiters) or take the async-mutex package.

How it is in the other languages: in JavaScript and in asyncio there is one thread, and the piece between two awaits runs alone. In C# the continuations are in the thread pool, so a lock is needed there too. Java has no await: there the same thing is done with CompletableFuture, and since Java 21 also with virtual threads, where you write ordinary blocking code and the JVM unmounts the thread by itself while it waits.

Try it

Find the bug

The cart adds up the prices of three orders. The price comes from the warehouse with await. The three orders cost €25 each, and the total comes out as 25:

let total = 0;

async function addOrder(id) {
  total += await priceOf(id);
}

await Promise.all([addOrder(1), addOrder(2), addOrder(3)]);
console.log(`Total: €${total}`);

Total: €25

Pick the line with the bug.

total += await priceOf(id) is total = total + await priceOf(id): JavaScript reads total before the await. All three read 0 and write 0 + 25. Wait first, then add: const price = await priceOf(id); total += price;.

The bug is not in the threads but in the order: a value read before an await is stale after it.

The idea

Do not block the event loop

The event loop works only if no piece of code holds the thread for long. The sales report is made with a loop that computes for 300 ms. At the same time a buyer opens a product page, which waits 50 ms for the warehouse:

function buildReport() {
  const end = Date.now() + 300;   // computes for 300 ms without a single await
  while (Date.now() < end) {}
}

async function report() {
  buildReport();
  console.log("The report is ready");
}

async function productPage(buyer, start) {
  await sleep(50);
  console.log(`${buyer} waits over 0.25 s: ${Date.now() - start > 250}`);
}

const start = Date.now();
await Promise.all([report(), productPage("Ann", start)]);

The report is ready
Ann waits over 0.25 s: true

The page waited over 0.25 s instead of 50 ms. While the report holds the thread, no other continuation can run: not this page, not payments, not timers. On a server with thousands of buyers, they all freeze at once.

The fix is to keep the heavy work out of the event loop's thread. It goes to a thread pool or a Worker, and the event loop only waits for the result:

async function report() {
  const worker = new Worker(new URL(import.meta.url));
  await once(worker, "exit");
  console.log("The report is ready");
}

async function productPage(buyer) {
  await sleep(50);
  console.log(`${buyer}: the page is ready`);
}

if (isMainThread) {
  await Promise.all([report(), productPage("Ann")]);
} else {
  buildReport();
}

Ann: the page is ready
The report is ready

The report is made in a Worker: the same file, where isMainThread is false. The main thread only waits for the exit event. The page is ready after 50 ms, the report after 300.

Try it

Fill in

Start the three requests at once and wait for them together:

await ([
  call("payment", 300),
  call("e-mail", 100),
  call("warehouse", 200),
]);
console.log(`Waiting at once: ${most}`);

Exercise

Reserve, pay, return

Solve it in your own editor.

Two items are left. Four buyers order at once: Ann, Bob, Vera and Gina. The payment takes 100 ms. Bob's card is declined: the payment throws an exception with the text "card declined".

checkout reserves the item before the await, then pays. If the payment fails, the item is returned. Print each buyer's result in the order of the orders, and at the end the stock and the number sold:

Ann: paid
Bob: card declined, the item is returned
Vera: out of stock
Gina: out of stock
Stock: 1, sold: 1

Vera and Gina see "out of stock", because Bob's item is still reserved until the bank answers. That is fair: the returned item goes to the next buyer.

More tasks

Try again. If a buyer finds no stock but another one may return an item, let them wait up to 200 ms and try again.
Timeout. The bank sometimes does not answer. If the payment takes over 1 s, decline the order and return the item. (AbortSignal.timeout)
Report. Work out the total of the sales (€25 each) and print it at the end.

Test

Check yourself

1. In how many threads does your code run in JavaScript (Node) and in Python asyncio?In one: the event loop runs the pieces of code one by oneIn one thread per awaitIn as many as there are cores

2. Three requests wait 100, 200 and 300 ms. How long in total if you await them one by one, and how long with Promise.all, gather, Task.WhenAll or allOf?About 300 ms both waysAbout 600 ms and about 300 msAbout 600 ms both ways

3. In JavaScript and Python an async function reads shared data, then awaits, then writes. When can other code change the data?Only while it waits at the awaitNever: there is one threadBetween any two lines

4. Handling a request includes a computation that takes 2 seconds, without a single await. What happens to the other requests in Node or asyncio?Nothing: the async function runs separatelyThey move to another threadThey wait 2 seconds: the event loop is busy

5. How do you avoid selling the last item twice?Run the orders in two threadsCheck and decrease the stock with no await between them, then pay; if the payment fails, return the itemAdd one more await before the write

async is not a thread

Cookies