Hacker News Reader

Hacker News

Comment by bullen | Hacker News Reader

Parent Full thread

bullen

If you need to lock when accessing memory between requests you are using the wrong language:

https://eli.thegreenplace.net/2019/on-concurrency-in-go-http...

Erlang, Rust and Go can only be used to solve embarrassingly parallel problems.

View on HN

> Erlang, Rust and Go can only be used to solve embarrassingly parallel problems.

I'm pretty sure each of those have been used for other kinds of parallelism than just embarrassingly parallel problems.

I don't see the problem here. You need to have serial access to the counter. You could use a single-threaded webserver but there is a lot more to that request than actually incrementing the counter. It still makes sense in most cases to use a threaded webserver and lock on incrementing the counter. (Especially if you are using a concurrent hashtable so that you can increment multiple counters in parallel)

Could you expand on this? Mutexes are not the only way to protect shared state in Go.

What language constructs/patterns do you feel are better suited to solving parallelism problems, and what languages exemplify these techniques?

"While I'm on the topic of concurrency I should mention my far too brief chat with Doug Lea. He commented that multi-threaded Java these days far outperforms C, due to the memory management and a garbage collector. If I recall correctly he said "only 12 times faster than C means you haven't started optimizing"." - Martin Fowler https://martinfowler.com/bliki/OOPSLA2005.html

Go has both memory management and a quite performant garbage collector, as you probably know.

Your article is from 2005, so I take it to mean that Java 6 was doing the interesting things you talk about - from my recollection, the go-to at that time was java.util.concurrent. (I haven't kept up with Java, so it could still be state-of-the-art.)

https://www.sciencedirect.com/science/article/pii/S016764230... - this paper describes the implementation as "The heart of the framework is maintenance of queues of blocked threads, which are restricted here to FIFO queues." If you're not familiar, this is exactly what go channels are, just baked into the language rather than in the standard library.

The major differences being that java.util.concurrent in Java 16 is a bit more powerful as the one in Java 6, Java doesn't have one single GC rather multiple vendor implementations to choose from, with virtual threads on the horizon.

Additionally one benefit over Go, is that in Java (likewise in .NET), the scheduler algorithm is replaceable.

That's valid, I didn't mean to imply that Java was stuck in 2005. I'm having a hard time following the clues that bullen is trying to leave in order to divine their meaning, so I was trying to limit the scope.

http://nil.csail.mit.edu/6.824/2016/notes/gomem.pdf

The more you downvote me the stronger I become! :D

You could use the atomic package and forego the lock. You can also have a go routine with a channel that receives the counter messages. No need for a lock there.

But use it if you really need it. Likely that’s not your bottleneck.

What does that even mean?

Reply on news.ycombinator.com