4 ms·

What exactly is multi-threaded programming in this context?

• debacle 11y ago
  Programming that explicitly creates and manages threads.
• grayrest 11y ago
  I interpret it as shared state concurrency. That is, multiple threads sharing the same address space performing reads and writes on shared data: atomics, mutexes, etc. From the update I understand that he's considering things like Actors, Communicating Sequential Processes (goroutines), and data partitioning divide+conquer (MapReduce) approaches as different even if they happen to be implemented on different threads sharing the memory space. I'm not sure on the relative prevalence but I can say that I've read relatively little about what he's calling multi-threaded programming. Mostly just a handful of lock-free data structures from the C++ guys and Rust's take on how they can do it while avoiding data races due to the type system. The alternatives, on the other hand, have been on HN pretty much continuously since HN started up.
  • GFK_of_xmaspast 11y ago
    c++11 added a ton of support for that kind of stuff tho, with language-level atomics, mutexes, etcetcetc.
  • wvenable 11y ago
    And this is in direct contrast to how much hype there was for programmers to use multi-threaded programming due to leveling off of single-core performance and the prevalence of multi-core systems.
  • dbaupp 11y ago
    I'm not sure about this, e.g. concurrent data structures are a form of shared state concurrency and "worker pools" may or may not use shared state, it seems orthogonal.
• aidenn0 11y ago
  My reading of it based on his grading is "preemptive multitasking with shared state"
  • eloff 11y ago
    Well that's just as popular as ever including in his examples (e.g. Go) so your interpretation is wrong.
• antod 11y ago
  Anything around scaling across multiple cores I suppose. It wasn't as nuanced back then. In 2004 single core computers were still quite prevalent, and the idea of steady significant performance improvements coming from increasing clock speeds was in its death throes. From memory it was about then that Intel had given up on the P4 Netburst architecture and stepped back to improving the P3 to release the new Core and Core Duo architectures. Nowadays multicore has been reality for a long time and the number of cores in a CPU has increased a lot, and we're thinking much more about different competing ways of achieving better concurrency. Back then it was just about getting better multicore concurrency at all using bog standard threads.
• brusch64 11y ago
  I still think that he assessed this point favorably for himself. If you read the whole point he made he may be right. But for me all these asynchronous methods are used more and more, so I'd say multi-threaded programming is much bigger than it was 10 years ago. If you look at some languages / frameworks I see now this: If you are programming now in C# you have keywords like "await" which make background processes much easiert. When you are programming Android in AndroidStudio you are warned if you try to call a web service in a GUI thread. 15 years ago, when I've started programming commercially (MFC and C++) most of the books said something along "well this is multi-threaded programming, but 'There be dragons'.."