[mc3]

Do you have an example?

If it is single threaded, and we are talking about shared variables, I thought I can assume the runtime is not going to pause my code execution, switch context, and run other code midway through my call back handler.

If we are talking about shared external resources (e.g. who can update a cloud blob) then we could have a proxy for that as a variable. You might need retry logic, and it could get tricky in that respect.

[connicpu]

You can rely on node preventing data races, but those are distinct from race conditions. A race condition in the logic of your code can happen any time two "threads" of execution (in this case a thread could be considered a chain of asynchronous callbacks) interleave their operations. It's possible for one of them to do something with a resource the other was using unless you use some kind of synchronization to prevent the other from using the resource until the first thread is done with it. For example, two callback chains could start using the same database connection object. Perhaps one chain was in the middle of setting up a transaction when it needed to wait for some other async resource to load, and the other chain comes in and does something with it. Now it's in an unintended state because the object was allowed to be used by two different "threads" of callback chains.

[foota]

This is not the case, if your callback then goes off and does something asynchronous.

[mc3]

Yes sorry I was thinking in terms of code that uses callbacks, not the async keyword.

What I mean is that distinct from threading, where the following code could be interrupted between the first and second line of the function, by something that updates global:

    var global

    function addTheseToGlobal(a, b) {
      im = a + global
      return im + b
    }