11–15 of 15 posts
Hard to say without knowing what you mean by "if two tasks try to access a variable concurrently it gets marked atomic and they contend for access." People who have worked in depth with multithreaded programs know that there be dragons here, and so unless you've proved your code correct for all cases, the assumption will be that it's broken. Do you handle the case that Thriqon brings up safely, for example? Do you ta…
This is actually not sufficient. As victorNicollet pointed out, JS gives very strong guaranties when executing the code.
Let say
function swap(a, b) {
var swap;
swap = a.amount;
a.amount = b.amount;
b.amount = swap.
}
If you use STM, then you can abstract away locks and have control over the lock taking order so you can avoid dead locks.
For example Clojure language is using STM, but they assume that the variables used in transaction are immutable, as they only manage the control over the references.
Does your concurrent runtime guarantee that scripts will be executed as if they were running on a single-threaded runtime ? Consider a naive function that queries several asynchronous data sources and constructs an array of all distinct responses: function distinct(sources, next) { var left = sources.length; var result = []; for (var i = 0; i This code can only work if each call to `process()` is executed atomically,…
This code can only work if each call to `process()` is executed atomically, start-to-finish, without another call touching `result` or `left`. In any language but JS, this would be an obvious race condition. But JS guarantees that there will be no concurrent access, and plenty of third-party code relies (perhaps unknowingly) on this serial execution property. Wow, this is very strong guaranty. Thanks for this insight…
http://www.ecma-international.org/ecma-262/6.0/index.html#se...
> At any point in time, there is at most one execution context that is actually executing code.
> Evaluation of code by the running execution context may be suspended at various points defined within this specification. Once the running execution context has been suspended a different execution context may become the running execution context and commence evaluating its code.
Suspending the evaluation context is triggered by executing certain constructs, some of which are obvious (calling a function suspends the caller context until that function returns) and some of which are complex (there's a nice game of context switching whenever generators are involved). The general idea is that the evaluation context decides to be suspended, rather than forced to do so by anything else (like a thread scheduler).
However, don't expect everyone to jump on it. The original purpose of Node was to provide a simple way of handling I/O in a non-blocking fashioned without having to deal with the headache of true multi-threaded programming. So you are trying to re-write the engine to do the exact opposite of what it was created for.
People need a compelling reason to switch from the tried and tested to something new and unproven. So you need a compelling feature/benefit. But I cannot see what it is. 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 thre…
Try writing a raytracer using a single thread, now try again with multiple threads working in tandem. Trust me, I tried.