4 ms·

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-serve

• fwip 6y ago
  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?
  • bullen 6y ago
    "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 https://martinfowler.com/bliki/OOPSLA2005.html
    • fwip 6y ago
      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/S0167642305000663 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.
      • pjmlp 6y ago
        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.
        • fwip 6y ago
          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.
      • bullen 6y ago
        http://nil.csail.mit.edu/6.824/2016/notes/gomem.pdf http://nil.csail.mit.edu/6.824/2016/notes/gomem.pdf The more you downvote me the stronger I become! :D
• Jtsummers 6y ago
  > 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.
• icholy 6y ago
  What does that even mean?
• kevincox 6y ago
  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)
• jamra 6y ago
  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.