Why have microwait take an integer?

[Kevin Gibbons]

The non-negative integer argument iterationNumber is a hint to implement a backoff algorithm if the microwait itself is in a loop. It defaults to 0. Atomics.microwait(n) waits at most as long as Atomics.microwait(n+1).

Why not just have engines count how many times microwait has been called since the last microtask or turn of the event loop, so users don't have to remember to track it themselves?

[Shu-yu Guo]

Because my intuition is there's no correlation between microtask checkpoints and event loop turns and how many times a busy loop is performed. The point of a busy loop with a microwait in order to acquire micro-contended locks quickly without sleeping. It seems reasonable that sometimes you'd acquire (and release) multiple such locks in a single run-to-completion, no?

[Kevin Gibbons]

Well, there is a correlation, which is that the number of times the busy loop is performed is upper bounded by the number of times microwait is called in a given turn. But yes, it's true that you might reasonably have multiple such loops within a single turn. I guess since this is designed for low-level stuff it's reasonable to expect the developer to handle this sort of bookkeeping explicitly.