Are locks and mutable shared memory a good thing? Advances in modern programming languages aim to abstract threads away (e.g. .NET's Task Parallel Library), because mutable memory shared between threads is a minefield (atomic, locks, mutexes, compare-exchange, etc.).

Not only are these difficult to reason about and program against, introducing locks over mutable memory causes performance problems and are a speed bump to high concurrency. (Heck, just yesterday on HN, a story was published "24-core CPU and I can't move my mouse" [0] - the culprit? Low-level locks.)

Creating too many threads introduces performance problems, too, thanks to CPU context switching; pools must be created and threads reused from those pools.

And now in JS land we're trying to introduce threads and mutable shared memory? Are we just going to learn these lessons over again?

[0]: https://randomascii.wordpress.com/2017/07/09/24-core-cpu-and...

You can only send strings to webworkers in javascript. Without shared memory you have to send a serialised copy of your data to the other process which then has to deserialise it. In most cases this is perfectly fine. But if you have a lot of data then moving it around might take more time than the computation itself. In this case you're forced to use shared memory.

Not true, you can send ArrayBuffers to webworkers as transferable objects without copying: https://developers.google.com/web/updates/2011/12/Transferab...

TPL abstracts threads away, but not mutable shared memory, nor any primitives used to synchronize access to such from concurrent tasks.

TPL (and PLINQ) raise the level of abstraction. They discourage the use of mutable shared memory and low-level locks. They encourage the use of immutable or thread-safe data structures.

Joe Duffy, who had originally done quite a bit of initial work on the TPL, argues in favor of this paradigm[0] of raising the abstraction level.

I feel like introducing the low-level tools without providing a raised abstraction level may be beneficial in the long run (you need low-level tools to build high-level abstractions), however, without these abstractions I suspect a generation of JS developers will need to re-learn all the multi-threading lessons of the last few decades.

[0]: http://joeduffyblog.com/2016/11/30/15-years-of-concurrency/

I don't see how TPL discourages the use of mutable shared memory any more so than a simple thread pool. Note: I'm not saying that it's not a higher level of abstraction, only that it's abstraction in a different direction (the one that has nothing to do with sharing or mutability).

I'm not surprised that TPL author discourages mutable shared memory and locks - this is the conclusion to which anyone dealing with concurrency a lot arrives sooner rather than later. But that's orthogonal to TPL design.

Now, PLINQ does attack the whole mutable shared memory thing head-on. But it's a much higher level of abstraction on top of TPL.

We have the great benefit of stewards having already learned those lessons.

Shhhh node people still pretend threads don't exist

Hmm... can't tell if this is an attempted Node slam, but figured I would add that you can mimic threads / concurrent tasks by utilizing the child_process or cluster modules.

As a matter of fact, it certainly makes things a fair bit more pleasant than the current state of affairs as they -- shared array buffers -- are another data primitive on top of bidirectionally passing strings/buffers.

Not sure that anybody is "pretending" anything. Seems like you're just going out on a limb to be condescending.

I hope those kinds of comments do not start making their way towards HN. Reddit is getting so bad lately, an influx is probably due.