0

I'm trying to understand how my code works from a macro perspective.

I've learned that parallel programming is possible from this SO Question which links out to an article on web workers by Resig.

I found this confusing because I thought that I had read that JavaScript in the browser is single threaded.

Perhaps I've mis-matched things.

Do some browsers support multi-threading? Is this similar or correlative to parallel processing?

Community
  • 1
  • 1
  • Nearly ever browser is going to use multiple threads in the OS, or the GUI would be completely unusable. (This has nothing to do with JavaScript, though) – Wooble Feb 12 '13 at 19:51

2 Answers2

3

JavaScript in a web browser is always semantically and behaviorally single-threaded. There's a new(ish) facility called "Web Workers" that allows multiple independent JavaScript threads to run, but each sees a world in which semantics are (excepting some particular special cases) exactly what one would expect in a single-threaded, event-driven environment.

Communication between the main "page" thread and each worker are strictly via message passing. Passing a message to a worker (or to the page thread) triggers an event, which must be handled for the message to be received.

Here is the MDN intro to Workers.

edit As I wrote in a comment below, there are different ways of thinking about this question. A browser (or any other JavaScript environment) can run lots of distinct JavaScript threads of execution concurrently. Is that a "multi-threaded environment"? Well, you can call it that if you like I guess. However, from the standpoint of each thread, there are no other threads to worry about: there are only events to handle and actions to initiate via platform APIs (eg, DOM interactions, XHR, and Workers). Those APIs are either synchronous, or they're not. But there are no synchronization primitives to worry about, no sharing of memory with other threads, etc.

Pointy
  • 405,095
  • 59
  • 585
  • 614
  • @pure_code well I think the issue is one of terminology: what exactly does "single-threaded environment" mean? It depends on your point of view. If you think of a multi-tab browser, each page may be running JavaScript code concurrently, possibly on separate physical CPUs. But since the code in each page is completely firewalled from that in other pages, it's effectively an isolated "single" thread. – Pointy Feb 12 '13 at 19:48
  • So my assumption that a single threaded environment would not allow parallel processing was not correct?...or is the term parallel processing being mangled by the SO Post I referenced in my question? I am referring to a single tab in a single browser on a single modern commodity machine. –  Feb 12 '13 at 19:50
  • @pure_code in a single tab in a single browser "process", there can by separate threads of JavaScript via the Workers API. However, each thread has its own private memory, and there's no shared state between the threads other than what's communicated via asynchronous message passing. (Data is always copied between threads; nothing is shared.) – Pointy Feb 12 '13 at 19:54
  • Thanks, the distinction is important to understand, because I'm trying to understand the limitations of not my code, but the limitations of the language and libraries I'm using.... –  Feb 12 '13 at 19:56
  • ...for example if you have two script to load say script1.js and script2.js...and let's say you want them to run at the same time ( nevermind the why), technically the browser has the ability to do this. –  Feb 12 '13 at 20:01
  • ...likewise, if the browser has access to multiple threads, I would say it is multi-threaded, even if they are "firewalled"...my guess is that browser developers do not have this "firewall" in place. –  Feb 12 '13 at 20:06
  • @pure_code yes, but keep in mind that the Worker environment is very strictly defined, and in particular the worker code has no direct access to the DOM. All DOM manipulation is reserved for the "page" thread. The separation between JavaScript threads most definitely exists. – Pointy Feb 12 '13 at 20:13
1

You are right in saying JS is single threaded.

What it actually means is that the javascript code written is read (parsed) and evaluated(executed) by one single process allocated to the browser by the native Operating System.

While there is no restriction in the number of threads that can be given to a browser, but up until some time back, all browsers, mutually used one thread, and which was a safe approach (avoided complex timing issues and cross thread communication).

Since the advent of HTML5, browser makers have been coerced to bring in the cookie features, like Web Workers.

What web workers allows is for the browser to request more than 1 thread from the OS and execute parallel operations in each of those threads.

Hence it is the responsibility of the developer writing the JS code to make sure the processes have no dependency etc, so that they can actually work independently.

Read up here HTML5 official site about it. Pretty similar to Resig's blog though.

Arindam
  • 998
  • 1
  • 8
  • 20
  • The definition of the Worker API makes it **impossible** for worker threads to share state with eachother or with the page thread; the developer can't get around that and therefore it's not a concern or responsibility. – Pointy Feb 12 '13 at 19:57
  • Well the definition does allow objects to be passed between the threads via the postMessage api. In real world use-cases, where there is a lot of code written, which necessitated web workers in the first place, it is natural to pass the objects. Dependencies, in most cases, will arise, if one thread's output/operations depend on the values passed from another thread. – Arindam Feb 12 '13 at 20:00
  • if it has access to multiple threads, I think it would be better to say multi-threaded, but I see the point you are making. –  Feb 12 '13 at 20:05
  • @Arindam Objects passed via `postMessage()` are copied. The spec includes provisions for passing references to buffers as a second argument, but I don't know exactly how that's to be implemented (Firefox doesn't do it yet; not sure about Chrome). The model is really similar to other "actor" systems like Erlang or Clojure. – Pointy Feb 12 '13 at 20:07
  • @Arindam ah [here you go](http://updates.html5rocks.com/2011/12/Transferable-Objects-Lightning-Fast) - Chrome allows buffers to be "transferred" from one thread context to another. Thus, race conditions are avoided by ensuring that only one thread has access to the buffer at a time. – Pointy Feb 12 '13 at 20:12
  • Nice point. Not sure about the dev stage in Chrome/FF right now. I see you are trying to imply that memory references shouldn't be an issue. But in either case, the point is if workerB needs values from workerC, it will either wait or not be able to run to completion, thereby reducing it to sequential, or at best, async processing, not really parallel processing. That is what authors have to be careful about while architecting around WebWorkers. Personally, I find it a little too cumbersome to be useful. Nevertheless, a good feature to build on :-) – Arindam Feb 12 '13 at 20:13