What are the drawbacks of making a multi-threaded JavaScript runtime implementation? [closed]

Question

I've been working on a multi-threaded JavaScript runtime implementation for the past week. I have a proof of concept made in C++ using JavaScriptCore and boost.

The architecture is simple: when the runtime finishes evaluating the main script it launches and joins a thread-pool, which begins picking tasks from a shared priority queue, if two tasks try to access a variable concurrently it gets marked atomic and they contend for access.

The problem is that when I show this design to a JavaScript programmer I get extremely negative feedback, and I have no idea why. Even in private, they all say that JavaScript is meant to be single threaded, that existing libraries would have to be rewritten, and that gremlins will spawn and eat every living being if I continue working on this.

I originally had a native coroutine implementation (using boost contexts) in place as well, but I had to ditch it (JavaScriptCore is pedantic about the stack), and I didn't want to risk their wrath so I decided against mentioning it.

What do you think? Is JavaScript meant to be single threaded, and should it be left alone? Why is everyone against the idea of a concurrent JavaScript runtime?

Edit: The project is now on GitHub, experiment with it yourself and let me know what you think.

The following is a picture of promises running on all CPU cores in parallel with no contention:

Answer 1

1) Multithreading is extremely hard, and unfortunately the way you've presented this idea so far implies you're severely underestimating how hard it is.

At the moment, it sounds like you're simply "adding threads" to the language and worrying about how to make it correct and performant later. In particular:

if two tasks try to access a variable concurrently it gets marked atomic and they contend for access.
...
I agree that atomic variables won't solve everything, but working on a solution for the synchronisation problem is my next goal.

Adding threads to Javascript without a "solution for the synchronisation problem" would be like adding integers to Javascript without a "solution for the addition problem". It's so fundamental to the nature of the problem that there's basically no point even discussing whether multithreading is worth adding without a specific solution in mind, no matter how badly we might want it.

Plus, making all variables atomic is the sort of thing that's likely to make a multithreaded program perform worse than its singlethreaded counterpart, which makes it even more important to actually test performance on more realistic programs and see if you're gaining anything or not.

It's also not clear to me whether you're trying to keep threads hidden from the node.js programmer or if you plan on exposing them at some point, effectively making a new dialect of Javascript for multithreaded programming. Both options are potentially interesting, but it sounds like you haven't even decided which one you're aiming for yet.

So at the moment, you're asking programmers to consider switching from a singlethreaded environment to a brand new multithreaded environment that has no solution for the synchronisation problem and no evidence it improves real-world performance, and seemingly no plan for resolving those issues.

That's probably why people aren't taken you seriously.

2) The simplicity and robustness of the single event loop is a huge advantage.

Javascript programmers know that the Javascript language is "safe" from race conditions and other extremely insidious bugs that plague all genuinely multithreaded programming. The fact that they need strong arguments to convince them to give up that safety does not make them closed-minded, it makes them responsible.

Unless you can somehow retain that safety, anyone who might want to switch to a multithreaded node.js would probably be better off switching to a language like Go that's designed from the ground up for multithreaded applications.

3) Javascript already supports "background threads" (WebWorkers) and asynchronous programming without directly exposing thread management to the programmer.

Those features already solve a lot of the common use cases that affect Javascript programmers in the real world, without giving up the safety of the single event loop.

Do you have any specific use cases in mind that these features don't solve, and that Javascript programmers want a solution for? If so, it'd be a good idea to present your multithreaded node.js in the context of that specific use case.

---

P.S. What would convince me to try switching to a multithreaded node.js implementation?

Write a non-trivial program in Javascript/node.js that you think would benefit from genuine multithreading. Do performance tests on this sample program in normal node and your multithreaded node. Show me that your version improves runtime performance, responsiveness and usage of multiple cores to a significant degree, without introducing any bugs or instability.

Once you've done that, I think you'll see people much more interested in this idea.

Answer 2

A decade or so ago Brendan Eich (the inventor of JavaScript) wrote an essay called Threads Suck, which is definitely one of the few canonical documents of JavaScript's design mythology.

Whether it is correct is another question, but I think it had a big influence on how the JavaScript community thinks about concurrency.

Answer 3

Just guessing here to demonstrate a problem in your approach. I can't test it against the real implementation as there is no link anywhere...

I'd say it is because invariants are not always expressed by the value of one variable, and 'one variable' is not sufficient to be the scope of a lock in the general case. For example, imagine we have an invariant that a+b = 0 (a bank's balance with two accounts). The two functions below ensure that the invariant is always held at the end of each function (the unit of execution in single-threaded JS).

function withdraw(v) {
  a -= v;
  b += v;
}
function deposit(v) {
  b -= v;
  a += v;
}

Now, in your multithreaded world, what happens when two threads execute withdraw and deposit at the same time? Thanks, Murphy...

(You might have code that treats += and -= specially, but that is no help. At some point, you will have local state in a function, and with no way to 'lock' two variables at the same time your invariant will be violated.)

---

EDIT: If your code is semantically equivalent to the Go code at https://gist.github.com/thriqon/f94c10a45b7e0bf656781b0f4a07292a, my comment is accurate ;-)

Answer 4

Atomic access does not translate into thread-safe behavior.

One example is when a global data structure needs to be invalid during an update like rehashing a hashmap (when adding a property to an object for example) or sorting a global array. During that time you cannot allow any other thread to access the variable. This basically means that you need to detect the entire read-update-write cycles and lock over that. If the update is non trivial that will end up into halting problem territory.

Javascript has been single threaded and sandboxed from the beginning and all code is written with these assumptions in mind.

This has a great advantage with regards to isolated contexts and letting 2 separate contexts run in different threads. I also means that people writing javascript don't need to know how to deal with race conditions and various other multi-thread pitfals.

Answer 5

Is your approach going to significantly improve performance?

Doubtful. You really need to prove this.

Is your approach going to make it easier/faster to write code?

Definitely not, multithreaded code is many times harder to get right than single threaded code.

Is your approach going to be more robust?

Deadlocks, race conditions etc. are a nightmare to fix.

Answer 6

Your implementation is not just about introducing concurrency, rather its about introducing a specific way to implement concurrency i.e concurrency by shared mutable state. Over the course of history people have used this type of concurrency and this has lead to many kinds of problems. Ofcourse you can create simple programs that works perfectly with using shared mutable state concurrency but the real test of any mechanism is not what it can do but can it scale as the program get complex and more and more features are added to the program. Remember software is not a static thing that you build once and are done with it, rather it keeps evolving over time and if any mechanism or concept can't cope with evolution of the software then it will only lead to new problems and this is exactly what history has taught us about shared mutable memory concurrency.

You can look at other models of concurrency (ex: message passing) to help you figure out what sort of benefits those models provide.

Answer 7

This is needed. The lack of a low level concurrency mechanism in node js limits it's applications in fields such as math and bioinformatics, etc... Besides, concurrency with threads doesn't necessarily conflict with the default concurency model used in node. There are well known semantics for threading in an environment with a main event loop, such as ui frameworks (and nodejs), and tho they are definitely overly complex for most situations they still have valid uses.

Sure, your average web app will not require threads, but try doing anything a little less conventional, and the lack of a sound low level concurrency primitive will quickly stir you away to something else that does offer it.

Answer 8

I really believe it's because it's a different and powerful idea. You are going against belief systems. Stuff becomes accepted or popular through network affects not on the basis of merit. Also no one wants to adapt to a new stack. People automatically reject things that are too different.

If you can come up with a way to make it into a regular npm module which sounds unlikely, then you may get some people using it.