3 ms·
> Thread-based concurrency has no future. It's complex and it doesn't scale beyond a certain point. Beyond what point? Every single company that handles petaby
by incepted 11y ago
> Thread-based concurrency has no future. It's complex and it doesn't scale beyond a certain point.
Beyond what point? Every single company that handles petabytes of data, starting with Google, seems to be scaling just fine with thread-based concurrency.
And why shouldn't they? Thread-based concurrency has decades of study behind it, it's very well understood, the tooling is terrific (IDE's even tell you ahead of time when deadlocks can happen and when they do, they can tell you exactly why) and the performances are unmatched.
I'd say thread-based concurrency is going to be around for a while, as opposed to the many fads that come and go trying to replace it, starting with actor-based concurrency and transactional memory.
- icebraining 11y agoNothing like replying hyperbole with more hyperbole. Calling the actor model, which has been around for forty years and has been slowly gaining recognition, a "fad" is frankly ridiculous.
- jondubois 11y agoWe haven't yet seen the limits of thread-based concurrency because CPUs have only just started to scale-out (by adding more cores). You're not going to experience any issues if you just have a small number of threads spread out over a small number of cores. If you had like 100+ cores (just guessing) and several of them tried to access or write to a specific shared memory location, they would spend a lot of time busy-waiting for each other to finish (assuming you're using mutexes). Maybe using semaphores could work but your code will end up looking like a mess. With process-based concurrency, each process can only rely on its own memory pool, so that does use-up more memory, but processes are fully independent from each other (fully parallel) so no time is wasted busy-waiting for anything. See https://en.wikipedia.org/wiki/Amdahl%27s_law https://en.wikipedia.org/wiki/Amdahl%27s_law