Why Doesn't JavaScript Support Multithreading

Why doesn't JavaScript support multithreading?

JavaScript does not support multi-threading because the JavaScript interpreter in the browser is a single thread (AFAIK). Even Google Chrome will not let a single web page’s JavaScript run concurrently because this would cause massive concurrency issues in existing web pages. All Chrome does is separate multiple components (different tabs, plug-ins, etcetera) into separate processes, but I can’t imagine a single page having more than one JavaScript thread.

You can however use, as was suggested, setTimeout to allow some sort of scheduling and “fake” concurrency. This causes the browser to regain control of the rendering thread, and start the JavaScript code supplied to setTimeout after the given number of milliseconds. This is very useful if you want to allow the viewport (what you see) to refresh while performing operations on it. Just looping through e.g. coordinates and updating an element accordingly will just let you see the start and end positions, and nothing in between.

We use an abstraction library in JavaScript that allows us to create processes and threads which are all managed by the same JavaScript interpreter. This allows us to run actions in the following manner:

• Process A, Thread 1
• Process A, Thread 2
• Process B, Thread 1
• Process A, Thread 3
• Process A, Thread 4
• Process B, Thread 2
• Pause Process A
• Process B, Thread 3
• Process B, Thread 4
• Process B, Thread 5
• Start Process A
• Process A, Thread 5

This allows some form of scheduling and fakes parallelism, starting and stopping of threads, etcetera, but it will not be true multi-threading. I don’t think it will ever be implemented in the language itself, since true multi-threading is only useful if the browser can run a single page multi-threaded (or even more than one core), and the difficulties there are way larger than the extra possibilities.

For the future of JavaScript, check this out:
https://developer.mozilla.org/presentations/xtech2006/javascript/

Is Node.js considered multithreading with worker threads?

This makes it sound like JavaScript was actually using multiple different threads the entire time. Why are people calling JavaScript single threaded?

The programming model in Node.js is a single threaded event loop with access to asynchronous operations that use native code to implement asynchronous behavior for some operations (disk I/O, networking, timers, some crypto operations, etc...).

Also, keep in mind that this programming model is not a product of JavaScript the language itself. It's a product of how JavaScript is deployed in popular environments like Node.js and browsers as an event-driven implementation.

The fact that internally there is a native code thread pool that is used for the implementation of some asynchronous operations such as file I/O or some crypto operations does not change the fact that the programming model is a single threaded event loop. The thread pool is just how the implementation of a time consuming task is made to have an asynchronous interface through JavaScript. It's an implementation detail that doesn't change the JavaScript programming model from a single threaded, event loop model.

Similarly, the fact that you can now actually create WorkerThreads does not really change the primary programming model either because the WorkerThreads run in a separate JavaScript VM with a separate event loop and do not share regular variables. So, whether you're using WorkerThreads or not, you still pretty much design your code for an event-driven, non-blocking system.

WorkerThreads do allow you to off-load some time-consuming tasks to get them out of the main event loop to keep that main event loop more responsive and this is a very good and useful option to have in some cases. But, the overall model does not change. For example, all networking is still event driven and non-blocking, asynchronous. So, just because we have WorkerThreads, that doesn't mean that you can now program networking in JavaScript like you sometimes do in Java with a separate thread for every new incoming request. That part of JavaScript's model doesn't change at all. If you have an HTTP server in Node.js, it's still receiving one incoming request at a time and won't start processing the next incoming request until that prior incoming request returns control back to the event loop.

Also, you should be aware that the current implementation of WorkerThreads in Node.js is fairly heavyweight. The creation of a WorkerThread fires up a new JavaScript VM, initializes a new global context, sets up a new heap, starts up a new garbage collector, allocates some memory, etc... While useful in some cases, these WorkerThreads are much, much more heavyweight than an OS level thread. I think of them as if they're almost like mini child processes, but with the advantage that they can use SharedMemory between WorkerThreads or between the main thread and WorkerThreads which you can't do with actual child processes.

Or is JavaScript indeed permanently single threaded, but with the power of worker threads, a process is able to have multiple threads of JavaScript, which still behave single thread?

First off, there's nothing inherent in the JavaScript language specification that requires single threaded. The single-threaded programming model is a product of how the JavaScript language is implemented in the popular programming environments such as Node.js and the browser. So, when speaking about single-threadedness, you should speak about the programming environment (such as Node.js), not about the language itself.

In Node.js, a process is able to have multiple threads of JavaScript now (using WorkerThreads). These run independently so you can get true parallelization of running JavaScript in multiple threads concurrently. To avoid many of the pitfalls of thread synchronization, WorkerThreads run in a separate VM and do not share access to variables of other WorkerThreads or the main thread except with very carefully allocated and controlled SharedMemory buffers. WorkerThreads would typically communicate with the main thread using message passing which runs through the event loop (so a level of synchronization is forced on all the JavaScript threads that way). Messages are not passed between threads in a pre-emptive way - these communication messages flow through the event loop and have to wait their turn to be processed just like any other asynchronous operation in Node.js.

Here's an example implementation using WorkerThreads. I was writing a test program whose job it was to run a simulation of an activity several billion times and record statistics on all the results to see how random the results were. Some parts of the simulation involved some crypto operations that were pretty time consuming on the CPU. In my first generation of the code, I was running a smaller number of iterations for testing, but it was clear that the desired several billions iterations was going to take many hours to run.

Through testing and measurement, I was able to find out which parts of the code were using the most CPU and then I created a WorkerThread pool (8 worker threads) that I could pass the more time consuming jobs to and they could work on them in parallel. This reduced the overall time of running the simulation by a factor of 7.

Now, I could have also used child processes for this, but they would have been less efficient because I needed to pass large buffers of data between the main thread and a workerThread (the workerThread was processing data in that buffer) and it was a lot more efficient to do that using a SharedArrayBuffer than it would be to pass the data between parent and child processes (which would have involved copying the data rather than sharing the data).

why Javascript SetTimeout() is not multithreaded

Javascript is not multithreaded nor non-multithreaded per se. However, the specific implementations of Javascript that currently are implemented in major browsers mostly ARE single-threaded.

In addition, for proper multithreading, the language needs to have facilities for shared memory, locks, semaphors and other concurrent programming tools, which JavaScript as is currently defined does not have (for example, there is no way to describe how concurrent JS threads would control who gets to update DOM objects that are of course, shared since there's only one DOM in a window).

There are attempts to make JS more parallelized - look at web workers, Intel's River Trail, Google's HTML5 work and more.

Javascript: How multiple threads are implemented in javascript?

A JavaScript program runs on a single thread of execution using a "run to completion" semantic.

Operations that would normally block in other languages are non-blocking, and simply handed off to the host (in this case, the browser), with your program notified of progress asynchronously via events.

When the host raises an event to be consumed by your program (eg. an inbound message), it puts a notification of that event in a queue as a "job". When that job reaches the front of the queue, and as soon as the call stack is empty (ie. the current script being run has run to completion), the JavaScript runtime dequeues the job and invokes the continuation function associated with it (ie. the part of your program configured to handle the event).

Your game will be sending messages over the network (eg via WebSocket). Your program will simply hand each message to the browser. This process is not computationally expensive or time consuming. The browser is multithreaded and will handle the low-level and time consuming networking concerns for you.

JavaScript is an event-based language. If you wish to be notified of future events related to a message you sent, then you can supply a callback (or use a promise) to be invoked by the runtime in the future at the appropriate time, rather than simply waiting for it. In this way the time available on the main thread of execution is used efficiently.

Your game loop will probably use requestAnimationFrame. That gives you about 16 milliseconds of computation per frame. Computation of game state might take a few milliseconds. Handling scheduled and time-based events might take another few milliseconds. Finally rendering needs some time too. In effect your program cooperatively multi-tasks on a single thread of execution.

For long-running, computationally expensive tasks you can use the Worker API to create new threads of execution with which you can communicate in a controlled way, but you will probably not need this here.

There is plenty of information online already about this topic. Search for "how the event loop works".

Relevant questions here, here, here, here, and here.

It is said that python doesn't support multithreading, then why does it have a threading module?

Python's single-threaded nature is due to the GIL (Global interpreter lock). When people refer to python being single threaded, they are describing how python operates when not using the threading or multiprocessing libraries. You can still make python use more threads, or spin up multiple processes, but for each instance of the code that you are running, it will only be using a single thread.

Javascript for example can make use of multiple threads and doesn't require any additional "work" to make this happen.

Check out this video for some more info: https://www.youtube.com/watch?v=m2yeB94CxVQ

JavaScript and Threads

See http://caniuse.com/#search=worker for the most up-to-date support info.

The following was the state of support circa 2009.

---

The words you want to google for are JavaScript Worker Threads

Apart from from Gears there's nothing available right now, but there's plenty of talk about how to implement this so I guess watch this question as the answer will no doubt change in future.

Here's the relevant documentation for Gears: WorkerPool API

WHATWG has a Draft Recommendation for worker threads: Web Workers

And there's also Mozilla’s DOM Worker Threads

---

Update: June 2009, current state of browser support for JavaScript threads

Firefox 3.5 has web workers. Some demos of web workers, if you want to see them in action:

• Simulated Annealing ("Try it" link)
• Space Invaders (link at end of post)
• MoonBat JavaScript Benchmark (first link)

The Gears plugin can also be installed in Firefox.

Safari 4, and the WebKit nightlies have worker threads:

• JavaScript Ray Tracer

Chrome has Gears baked in, so it can do threads, although it requires a confirmation prompt from the user (and it uses a different API to web workers, although it will work in any browser with the Gears plugin installed):

• Google Gears WorkerPool Demo (not a good example as it runs too fast to test in Chrome and Firefox, although IE runs it slow enough to see it blocking interaction)

IE8 and IE9 can only do threads with the Gears plugin installed

Does a NodeJS server use multithreading?

Some of it's underlying C++ components do but that capability is not exposed to you so you can't write threaded code yourself. The Javascript language itself doesn't provide support for threads.

To take advantage of multiple CPU's you can either spawn separate child processes or run a lot of parallel instances of the same process.

In other words you cant do multithreading; but you can still do multiprocessing.

...does one call get blocked until the other call completes or are they handled simultaneously.

They are accepted in parallel, assuming your requests are primarily I/O-bound (use the database, filesystem etc..) instead of CPU-bound (perform encryption, decryption, compression etc..).

Node.js offers a type of pseudo-concurrency facilitated by using an Event Loop and the programmer writing code in an Event-driven programming style (callbacks, Promises etc...), instead of creating separate threads for each request.

An oversimplification would be like this:

• Request A arrives and is put on the event queue.
• Request A requests data from the database.
• Request B arrives and is put on the event queue.
• Request B requests data from the database.
• Request B's database request arrives and request B is served with data.
• Request A's database request arrives and request A is served with data.

As you can see, Node accepts concurrent requests and serves each when necessary. It doesn't stop accepting incoming requests until another is served. It's non-blocking.

However the above scenario is a primarily I/O-bound example, where the Node.js concurrency model shines.

In contrast, if your requests are primarily CPU-bound (instead of I/O bound) then you freeze the single thread (remember Node.js is single-threaded) it runs on, requests cannot be accepted and your server "freezes" for the duration of that single request CPU computation.

...In other words, is multithreading enabled?

I assume that a lot of Node's underlying libraries (libuv for example) do use multiple threads, however the ability to directly control threads is not exposed to the user (although in theory you can write native C++ addons where you can harness multithreading).

If you're worried that you're not utilising all CPU cores, you should look into the cluster module to spin up multiple Node.js server processes. In this case the problem is taken off your hands; the O/S scheduler should, in most cases, spread the processes across available cores; this however is called multi-processing, not multithreading.

Since JavaScript is single-threaded, how are web workers in HTML5 doing multi-threading?

As several comments have already pointed out, Workers really are multi-threaded.

Some points which may help clarify your thinking:

• JavaScript is a language, it doesn't define a threading model, it's not necessarily single threaded
• Most browsers have historically been single threaded (though that is changing rapidly: IE, Chrome, Firefox), and most JavaScript implementations occur in browsers
• Web Workers are not part of JavaScript, they are a browser feature which can be accessed through JavaScript

Threads (or something like) in javascript

Get rid of the new keyword for the function you're passing to setTimeout(), and it should work.

function update(v2) {
 try {
     dump("update\n");
 } catch(err) {
     dump("Fail to update " + err + "\n");
 }
 setTimeout(function() { update(v2); }, 100);
}
update(this.v);

Or just use setInterval().

function update(v2) {
 try {
     dump("update\n");
 } catch(err) {
     dump("Fail to update " + err + "\n");
 }
}
var this_v = this.v;
setInterval(function() {update(this_v);}, 100);

EDIT: Referenced this.v in a variable since I don't know what the value of this is in your application.

---

Related Topics