Is it possible for a concurrent read/write read/write collision in JavaScript in the browser?
Asked Answered
P

2

6

I have a situation where I am making several (say four) ajax calls (using AngularJS http get, if that matters) and I want each call to callback and increment a counter, so I can know when all (four) of the threads have completed.

My concern is that since JavaScript does not have anything comparable to Java's "synchronized" or "volatile" keywords, that it would be possible for multiple concurrent threads to collide while incrementing a counter, thereby missing some increments.

In other words, two threads come at the same time, and both read the counter, getting the same value (for example 100). Then both threads increment that counter (to 101) and store the new value, and behold, we missed a count (101 instead of 102)!

I know that JavaScript is supposed to be single threaded, but there are exceptions.

Is this situation possible in the browser, and if so, is there any way to guard against it?

Patchwork answered 11/1, 2015 at 5:14 Comment(7)
no need for a counter due to promises. Take a look at $q.all(). $http returns a promise and you can wrap an array of promises and call done when they all completeGambol
it has never happened with me, AFAIR, but i am waiting for an answer! good question!Griseous
@mplungjan that would be very slowGriseous
@mplungjab Your approach is too slow; why should each call wait for the last before calling out. I would like to know if your solution is necessary or if JavaScript handles it for usPatchwork
@VictorGrazi that is not a common approach at all unless the calls are dependent on passing data to each otherGambol
Actually if you just want to know when they are all finished, a counter or the newer promises as mentioned by @Gambol would be ok. If there is no need to see the results in order, then no need to call them one by one as I suggested earlierGlamorous
@Glamorous order isn't an issue either by using promisesGambol
H
5

No, it is not possible (no collision will occur). Each AJAX call response can be considered a message on the JavaScript message queue. The JavaScript runtime processes each message on the queue to completion before processing the next. In other words, it calls the callback for the event and runs the full callback function (and all the functions it calls, and so on) to completion before moving onto the next message in the queue. Therefore, no two messages (e.g., AJAX responses) will be processed in parallel.

Source: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/EventLoop

Also, I've worked in JavaScript for many years and can guarantee this is how it works.

Herald answered 11/1, 2015 at 6:6 Comment(1)
I believe you, but can you please provide some explanation or source for your assertion?Patchwork
R
3

like you mentioned, since javascript is single threaded, I do not think such a scenraio would happen, the only way js becomes multi threaded is when you use webworkers, but even they do not share the same variables( they clone the attribute js objects you pass, i am assuming here), so there should be any case of read/write overlap

EDIT

on second thought, say there is function onCounterIncreament which would do a bunch of operation when counter increments, if you do not call it immediately after you increamenting counter, but use $watch or something timeout fn to check for change in counter, there is a good possiblity you might miss a change.

Respite answered 11/1, 2015 at 5:20 Comment(2)
My understanding is there are exceptions to the single threaded thing. For example, if several ajax calls return at the same time, or things like mouse events and such, where concurrency is required to ensure livenessPatchwork
@VictorGrazi, "JavaScript may be asynchronous, which is true. But basic JavaScript without WebWorkers is never multithreaded. See Már Örlygsson's answer " -- #2734525Respite

© 2022 - 2024 — McMap. All rights reserved.