Hacker News Reader

Comment by ilyt | Hacker News Reader

> Frankly, most 35 y/o engineers don't truly appreciate the intricacies of intra-thread concurrent algorithms, unless it's their specialized area.

Frankly those who do would try to avoid it anyway unless it is truly the best/only solution to the problem.

The best way to not have concurrency bugs is to have as little of it as possible. If I have a choice of making single job faster vs just running 64 jobs in parallel on CPU I'd pick the second every time I can because code will be simpler and less buggy every single time.

View on HN

> If I have a choice of making single job faster vs just running 64 jobs in parallel on CPU I'd pick the second every time I can because code will be simpler and less buggy every single time.

I maybe misunderstanding what you're trying to say, don't you mean you'd pick the first one every time? Make the single job faster instead of introducing concurrency with 64 parallel jobs?

I think he is arguing in favor of multiple concurrent processes ("single thread each"), instead of messing around with low-level threads + synchronization primitives (which would achieve a single fast process that uses multiple CPU cores by itself).

Completely, 100% agree.

I believe this also happens because often the most accessible/obvious form of concurrency is the super problematic "shared data by default" kind (C/C++/Java "Threads"), which is basically ASKING for trouble.

Also programming education sometimes even reinforces this in a very harmful way from what I've seen. Telling a student about mutexes/semaphores/atomicity is actively harmful IMO if it is not accompanied by strong discouragement and actual practice in finding subtle race conditions.

Agreed. Many years of effort went into building TSAN because nobody can get shared-memory concurrency right, and whenever someone thinks they can get shared-memory concurrency right, TSAN comes along and proves them wrong. Concurrency needs the same rule of thumb as cryptography: do not try to roll your own.

Rust talks about fearless concurrency, and IME, if you avoid async await it does provide it, potentially at a cost of lovks or mutex that might not be strictly necessary for your actual use case. Actually IME async await isn't a problem either but I've read it can be an issue.

In C++ the patterns I don't see bugs in is thread pools for processing large batches of heterogeneous data, and fine grained parallelism for stuff like vector and matrix operations. But in the latter case it is all library driven, and in the former, it is a really simple pattern.

Yes, these are alternatives to (and/or implemented on top of) shared-memory parallelism, and mostly much better to work with. To continue the cryptography analogy, it's using experts' cryptography libraries. Sometimes you do need to juggle the razor blades yourself (it's not actually turtles all the way down) but it shouldn't be done lightly.

Barely related rant but I think async/await type of concurrency is the worst of the bunch and outright malady on the code that infected the mass's brain by its proliferation in JS ecosystem. Even crude message passing leads to far cleaner code architecture.

> because often the most accessible/obvious form of concurrency

I dunno, I reinvented message-passing concurrency with multiple processes before I knew the terminology or had any formal programming training. It came completely naturally and it was nearly a decade before I understood why people thought concurrency was difficult to get right.

Knowing that though only comes from having an understanding of the uses and limitations thereof

Yeah, it's way too easy to get some new knowledge then just use it everywhere you can because you want to play with your newly gained skill, instead of dozing it in only where it is beneficial. I've created many spaghettis because of that before I realized that.

Or just use Clojure and slap a `p` on your `map` function.

Rust is really good at this sort of thing.

Reply on news.ycombinator.com