Race conditions with JavaScript event handling?

Question

We understand that JavaScript is single threaded, but we want to confirm our understanding of asynchronous event handling in JavaScript. More importantly, we want to confirm we're not exposed to potential race conditions.

Conceptually, our mobile app works like this:

We invoke function foo when a mobile page is loaded.
At the end of foo, we use setTimeout to invoke foo again (with one second delay) if a counter is greater than 0. If the counter hits 0, we load a new page. The timeout is saved in a variable.
If a button is tapped, we invoke function do_tap and clear the timeout variable saved in step two (and do other stuff).

do_tap and foo both update the same page element, and we want to confirm that they wouldn't step on each other.

Questions:

Assume a tap occurs during the execution of foo. Will the browser queue do_tap to start executing after foo finishes? In other words, are we guaranteed that once foo starts, we can never see execution of foo and do_tap interleaved?
What if the tap occurs first? do_tap is guaranteed to complete before foo starts, right?

Since the execution is single-threaded, it is simply impossible for `foo` to start executing before `Do_tap` returned (and vice versa). Read this article and you'll understand how the execution queue in the browsers works: http://ejohn.org/blog/how-javascript-timers-work/ — Šime Vidas, Dec 23 '11 at 00:35

score 10 · Accepted Answer · edited May 23 '17 at 10:27

10

Except for web workers and cooperating frames or windows (which aren't being used here), Javascript is single threaded within a given window so there are never two threads of execution running at the same time in that window. As such, you don't ever have to worry about race conditions that might be a typical worry when using threads.

Under the covers, Javascript has an event queue. Your current thread of execution will run to completion and then when it completes, the javascript interpreter will check the event queue to see if there are more things to do. If so, it fires that event and starts up another thread of execution. Pretty much everything goes through that event queue (timers, key events, resize events, mouse events, etc...).

You can read more about it and see a bunch of relevant references in one of my other answers on this subject.

edited May 23 '17 at 10:27

Community

1
1

answered Dec 23 '11 at 01:48

jfriend00

683,504
96
985
979

1

This is almost, true, except that frames have separate contexts of execution, and if they're all accessing the same data, like `top.myVariable`, you could have race conditions. See http://dev.opera.com/articles/view/timing-and-synchronization-in-javascript/ and search for race within that page – Ruan Mendes Sep 16 '13 at 22:32
I want to also mention Chrome extension, where you can have multiple separate contexts of execution. I haven't found race conditions to happen very often, depends very much on what you are building, but it do occur. – holmberd Jul 02 '18 at 02:42

score 6 · Answer 2 · answered Dec 23 '11 at 00:21

Event execution proceeds single-threaded until the event has been handled. Until that time, no other event loop will be initiated.

In other words, while a handler is running for some event, no other handler for any other event will interrupt it.

Thus the answer to both question 1 and question 2 is "Yes." (This is, of course, barring browser bugs, but if you take that into account you can't get very far. It's not like there are any synchronization primitives to fall back on. I say this only because there was a period of time during which Safari could fire a "DOMready" event in the middle of running another "DOMready" event handler. That was, however, quite clearly a bug.)

Thanks, we just wanted to confirm! do_tap() and foo() both update the same page element, and we wanted to make sure they couldn't step on each other. Thanks again for affirmation. — Crashalot, Dec 23 '11 at 00:27

score 0 · Answer 3 · answered Sep 18 '14 at 16:45

I didn't catch anyone else saying this, but I think the answer to #2 is that different browser implementations can and do differ in subtle ways as to which queued events are processed first. No, there is no possibility of interleaving, but whether setTimeout(func, 0) or a mouse event is handled first is not guaranteed by the language spec and in practice can matter. Whereas setTimeout(func, 100) is guaranteed to be processed later than pending events received during the currently handled event.

Just saying.

score 0 · Answer 4 · answered Dec 23 '11 at 00:34

As long as the first thing Do_tap() does is clearTimeout there will be no chance for foo to be running during the execution of Do_tap(). However, if an asynchronous process was initiated in foo() such a database request then there could be a potential wait to access the database in Do_tap() as foo() finishes its request, and if foo() has a callback function that could theoretically be called after Do_tap() was done executing.

Race conditions with JavaScript event handling?

4 Answers4

Linked