Comment by kcl | Hacker News Reader

Comment by kcl | Hacker News Reader

Parent Full thread

I've written on this problem before: https://kevinlawler.com/parallel

One issue is that the pthread model is too low level (think AND and OR gates), but you must include it for completeness.

I agree with the comments here that say higher-level multithreading support needs to be "baked in" to the language. Grand Central Dispatch did a good job of raising the bar here, but has its own problems, and is arguably too low level.

Another issue is that existing, widespread languages are too old to have cooked higher-level threading support in. You really have to do it from the start. C++ bolt-on parallelism might as well be syntactic sugar. Newer languages, like Rust, have attempted to solve concurrency problems but failed - it's not clear that the designers genuinely understand concurrency at all. Goroutines solve one limited issue of many and seem about as difficult as asking programmers to write threaded programs.

To do this correctly you need a new language that cooks it in from the start. There is a laundry list of things that have to be done precisely. It might be possible to do this by rewriting a reference implementation of an existing popular language, but the development overhead and performance concerns involved in backwards-compatibility make that probably infeasible. (Python can't even escape it's global-interpreter lock.) So likely the language that solves this problem is either unwritten or unknown.

Other mentions in the comments here:

ThreadSanitizer: It's not very good, nor can it be.

Erlang: solves the problem, but the actor formulation is too awkward for all but Erlang-specific use-cases.

>> Erlang: solves the problem, but the actor formulation is too awkward for all but Erlang-specific use-cases.

Err? I mean, it requires rethinking a bunch of the lessons you learn when concurrency is hard and expensive and to be minimized, sure. But when concurrency is easy and cheap and to be embraced, a bunch of things become a lot easier and more natural to write.

My go to example, from a production system, was a complicated task scheduling system (with user and hardware interrupts to handle). Sure, we could have written it using threads and a priority queue or something...instead we just had one Erlang process per task, with interrupts routed to that process as messages (and linked timer processes that fired messages to those processes for the scheduled stuff, essentially just another type of interrupt/message). Super simple to write, super simple to reason about, never had any sort of race condition or locking issues, across years of development and production use.

The problem with concurrent computing is not a lack of Erlang awareness or message passing awareness. If either was the solution we wouldn't be having this discussion since they both pre-date the 90s.

There ought to be a codeword where you can invoke the shortcomings of Erlang without getting dragged into a conversation with someone desperate to talk about Erlang. Next time I will rot13 it.

There are plenty of shortcomings of Erlang. They even post a bunch on the main website - https://www.erlang.org/faq/introduction.html#idm53

-You- said "But the actor formulation is too awkward for all but Erlang-specific use-cases". I was simply commenting that it's not awkward at all, for all sorts of use cases that aren't Erlang specific. Perhaps you'd like to define your terms better if you want to avoid people saying "hey, that statement as it comes across is flawed". Maybe you meant Erlang isn't the right tool to generalize to all use cases - no one would disagree. Maybe you meant what it sounds like, it's too awkward to use except for certain degenerate cases, in which case I strongly disagree; it's quite easy, and switching back to running N isolated units of execution on < N threads, and sharing memory between them, feels like a chore. Or maybe you meant something else entirely.

Maybe if you don't want to "get dragged into" a conversation on something...don't mention it on a public forum with such a badly worded statement?

>The problem with concurrent computing is not a lack of Erlang awareness or message passing awareness

It most certainly is.

We have been so thoroughly fed/brainwashed with Shared-Memory concurrency that most people don't even think beyond it unless forced by circumstances (or from curiosity). That is where Message Oriented Concurrency languages like Erlang can help. Just reading Joe Armstrong's thesis Making reliable distributed systems in the presence of software errors will teach one a simple approach to robust Concurrency that works and can be emulated in another language if you don't want to learn Erlang (the difficulty may vary based on language support).

PS: Folks may find Foundations of Multithreaded, Parallel, and Distributed Programming by Gregory Andrews a good reference for most major forms of Concurrency.

> It's completely feasible, from a programming standpoint, to imagine an architecture where each core has its own private RAM, the cores communicate through perfectly reliable IPC, and the device runs applications written in a successor to the distributed computing technology being developed now.

It is called processing in memory. What you have described was actually inverted. Instead of giving each core private RAM, you give each RAM chip a CPU core.

> Erlang: solves the problem, but the actor formulation is too awkward for all but Erlang-specific use-cases.

Play with Erlang a bit and you'll find the modern band-aid pattern of async / await awkward.

Reply on news.ycombinator.com