Javascript thread-handling and race-conditions

Question

Lets asume I have a code like the following:

var shared = 100;
function workWithIt(){
    shared += 100;
}

setTimeout(workWithIt, 500);
setTimeout(workWithI         


        

Answer 1

AFAIK, there is no multithreading in JS. I changed your example a bit to try to understand what you mean.

var shared = 100;
function workWithIt(a){
    shared += a||100;
    console.log(shared);
}

setTimeout(function(){workWithIt(5);}, 500);
setTimeout(function(){workWithIt(10);}, 500);
console.log(shared);

With this code, the result is always (in my testing):

100
105
110

This indicates to me that there is no chaotic or random or even interesting process here. There are certain possibilities to create racing conditions with JS in the browser, but your timing example is not that. Racing requires only a breakdown in predictability of execution order. Maybe if you change your delay from 500 to Math.floor(500 * Math.random()) you would have a racing condition.

Answer 2

JavaScript code has a single explicit thread of execution. The scenario you've described will never take place in JavaScript. A timer callback is just another kind of event, and all events are serialized for sequential execution by the same core event loop of the browser UI thread.

Thus, two timer events cannot be processed concurrently, one callback will happen after another.

You still can have real concurrency in JavaScript by means of Web Workers. However, a web worker cannot share any objects with another web worker or the main thread. Instead, web workers serialize their state objects with JSON, and exchange messages with postMessage. So, your scenario is still impossible.

However, consider another case:

var shared = 100;

function workWithIt1(){
    shared += 100;
}

function workWithIt2(){
    shared = shared/2;
}

setTimeout(workWithIt1, 500);
setTimeout(workWithIt2, 500);

Will shared be 150 or 100, once both timeouts have been fired? It probably will be 100, because the workWithIt1 timeout was queued first. However, I would not rely upon this fact though, because both timers have the same timeout value of 500, and implementation of timers might be browser-specific. You may want to avoid side effects like that in your code.