5 ms·

In my 30+ years experience of concurrency, the shared-nothing message model makes it relative easy to reason about concurrency (since every actor is single thre

• pjmlp 9y ago
  In a way it is ironic that we went full speed into threads, shared memory and plugins, only to go back into processes, messages and sandboxing as a means to tame multi-core programming and safety.
  • zokier 9y ago
    I thought threads and shared memory were introduced more as performance hacks than superior architecture. It is not surprising that as the performance profile has changed (due both increased core counts and improved software primitives), we are getting back those things that were deemed too expensive previously
  • platz 9y ago
    Concurrency abstractions are still built on primitives that involve locks and memory barriers.
    • pjmlp 9y ago
      Just like the old UNIX process IPC or micro-kernels communication is.
• sametmax 9y ago
  But don't we have thread pools and futures for that ? You can't get a simpler API.
  • amarkov 9y ago
    Futures aren't a natural way to formulate many important concurrency problems. If I want a thread polling an external system and putting records in a work queue for as long as my application is running... well, what's that a future of?
    • sametmax 9y ago
      That's what thread pools are for. They have a work queue you fill and workers depop it. Literally 5 lines in python and i imagine most modern languages.
      • amarkov 9y ago
        Right, but thread pools are simple because they don't offer any sort of API for the tasks in the work queue. You're just writing arbitrary code. So rather than reasoning about an abstract execution model, you have to carefully think about every line to make sure you don't accidentally share mutable state.
    • therealdrag0 9y ago
      In Java with Spring you'd do something like: @Scheduled(fixedRate = 5000) public void poll() { getCrapAndPutOnConsumerQueue(); }