And since we're particularly talking about adding threads to Javascript, here's the opinion of the creator of Javascript itself on threads:
You must be this tall to hack on threaded systems, and that
means most programmers should run away crying. But they
don’t. Instead, as with most other sharp tools, the
temptation is to show how big one is by picking up the
nearest ST code and jamming it into a MT embedding, or
tempting race-condition fate otherwise. Occasionally the
results are infamous, but too often, with only virtual
fingers and limbs lost, no one learns.
Threads violate abstractions six ways to Sunday. Mainly by
creating race conditions, deadlock hazards, and pessimistic
locking overhead. And still they don’t scale up to handle
the megacore teraflop future.
https://brendaneich.com/2007/02/threads-suck/
Brendan and I have had many discussions about the nature of threading in JS.
The reality is that to get high performance in JS on modern (and future afaict) is that JS will need to have some lower cost threading mechanism than that provided by workers.
If you read the article you'll see that there isn't any way to mismatch lock/unlock.
The other massive footgun is the for whatever reason people insist on creating standard libraries that are not thread safe (collections, apparently bigint in java?). JS is never going to have completely undefined behavior, but non-determinism already exists.
Is concurrent code easier to screw up than single thread? yes. Is that cost enough to discount the possibility of ever having threads? I don't know. The article goes one way, you clearly go the other.
Calling out "argument from authority" when someone posted actual arguments an authority made is even less valid.
>The reality is that to get high performance in JS on modern (and future afaict) is that JS will need to have some lower cost threading mechanism than that provided by workers.
Perhaps, but this is an orthogonal concern as to the issues with threads themselves (not to mention with an environment that has since forever assumed a single thread of execution).
(If you answer just use Erlang, CSP or any other variation, well, my point exactly).
Like I said, WebKit uses threads and it’s great. Maybe some day you will also learn to use threads.
robertwhiuk, responding to you, referenced using "twisted mess"
pizlonator:
I think it would be weird if objects were thread-
restricted by default. Concurrency is most fun when it's
easy for a thread to access an object it wants.
You say fun, but what you mean is twisted mess.
WebKit uses threads. WebKit is not a twisted mess.
WebKit needs tons of extra effort to keep it from being a
twisted mess precisely because it uses threads.
You have some good points in this discussion, generally. But you should at least be honest in your characterization of other people's comments.
Maybe some day you will also learn to use threads.
That's because coldtea (me) never said it IS a twisted mess.
What I said is that with threads, WebKit (and any program for that matter) needs extra effort to not be a twisted mess. Exactly what the parent explained again, and you don't seem to have got even this second time.
Why that is the case (in other words, why parallel programming with threads is harder and requires more effort than without), is CS 101.
Some reasons?
Synchronization and scheduling access to resources. Race conditions -- data Races, deadlocks, etc. Starvation. Balancing the number of threads (diminishing returns). Locking subtleties. VM/state/etc overhead of threading.
In fact you'd be hard pressed to find seasoned programmers that would disagree that threads are problematic and require extra caution.
Heck:
"Although threads seem to be a small step from sequential computation, in fact, they
represent a huge step. They discard the most essential and appealing properties of
sequential computation: understandability, predictability, and determinism. Threads, as a
model of computation, are wildly nondeterministic, and the job of the programmer becomes one
of pruning that nondeterminism" -- https://www2.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdfYou know, drawing stuff to the screen also requires effort. As does file I/O. It’s computing - people get things wrong. The interesting question is: are threads so unusual in this regard that your whining makes any sense?
We have lots of threads but except when we are in the middle of something big and concurrency related like concurrent GC, we have very few bugs of the sort you describe. Most of the bugs that bother me right now are in the compiler and runtime and they are not concurrency bugs at all. It’s true that if someone is deliberately trying to increase concurrency, they will fix some concurrency bugs along the way just like a person writing compiler phases will fix compiler bugs alone the way. We haven’t given up on compilers just because they are might have bugs.
Finally, you said: “WebKit needs tons of extra effort to keep it from being a twisted mess precisely because it uses threads.” You seem to have now significantly walked back from this statement since all you can come up with are reasons why threads are hard that are not related to WebKit or any specific software package. Sounds like maybe you just don’t know how to use threads so you spread FUD to avoid having to learn them.
Exactly, thanks.
Nobody doing threads ever said that they are not messy or that multi-thread access and locking et al are easy.