6 ms·

> concurrency is still widely regarded as 'too hard'. The question is: by whom? High performance software, like game engines, DAWs or video editors, has been

> concurrency is still widely regarded as 'too hard'. The question is: by whom? High performance software, like game engines, DAWs or video editors, has been heavily multithreaded for a while now. Maybe it's consumer or business software that could profit from more multithreading? I don't know, because I don't work in those areas.

criddell 5y ago
There's been a lot of work done in C++ concurrency. Some higher level libraries that leverage recent (primitive) additions are emerging and they look pretty cool. For example: https://github.com/David-Haim/concurrencpp https://github.com/David-Haim/concurrencpp
bartread 5y ago
> The question is: by whom? I do feel similarly, even though I wouldn't classify myself as a great engineer. I've been writing concurrent software in managed languages, such as Java and C#[0], from the very beginning of my career, up until today. The level of multithreading has varied, but it's always been there. For anything beyond basic CRUD it pretty much becomes a requirement, both on desktop and on the web[1]. That doesn't mean I've never had a tricky race condition to debug (and, yes, they're hard to debug) during development, but I've never shipped a concurrency related bug to production[2]. The canonical examples of concurrency gone wrong are things like giving somebody a deadly radiation dose from a medical device but, in terms of serious software bugs, I do wonder how common concurrency bugs are relative to other types of bug, and whether they're really more serious in aggregate than those other types of bug. [0] Admittedly these languages make it a lot easier to avoid shooting yourself in the foot than C and C++ do. [1] Also worth bearing in mind that an inherent property of most, if not all, distributed software is that it's also concurrent: the moment you have multiple processes running indepedently or interdependently you also usually have a concurrent system, with the potential for "distributed race conditions" to occur. I.e., if you have a SPA that also has a non-trivial back-end, you have a concurrent system - just spread across different processes, generally on different machines. [2] In the context of in-process concurrency. Distributed concurrency is a different matter.
tuyiown 5y ago
The hard part is to improve perceived performance or resource overhead for general software, where each task outcome is tightly coupled with app state, eg. a parallelize a slow task on button click and have guarantee that final state is coherent. Nothing out of reach, but doing that without compromising too much on maintainability is still an opened question.

criddell 5y ago

There's been a lot of work done in C++ concurrency. Some higher level libraries that leverage recent (primitive) additions are emerging and they look pretty cool. For example: https://github.com/David-Haim/concurrencpp https://github.com/David-Haim/concurrencpp

bartread 5y ago

> The question is: by whom? I do feel similarly, even though I wouldn't classify myself as a great engineer. I've been writing concurrent software in managed languages, such as Java and C#[0], from the very beginning of my career, up until today. The level of multithreading has varied, but it's always been there. For anything beyond basic CRUD it pretty much becomes a requirement, both on desktop and on the web[1]. That doesn't mean I've never had a tricky race condition to debug (and, yes, they're hard to debug) during development, but I've never shipped a concurrency related bug to production[2]. The canonical examples of concurrency gone wrong are things like giving somebody a deadly radiation dose from a medical device but, in terms of serious software bugs, I do wonder how common concurrency bugs are relative to other types of bug, and whether they're really more serious in aggregate than those other types of bug. [0] Admittedly these languages make it a lot easier to avoid shooting yourself in the foot than C and C++ do. [1] Also worth bearing in mind that an inherent property of most, if not all, distributed software is that it's also concurrent: the moment you have multiple processes running indepedently or interdependently you also usually have a concurrent system, with the potential for "distributed race conditions" to occur. I.e., if you have a SPA that also has a non-trivial back-end, you have a concurrent system - just spread across different processes, generally on different machines. [2] In the context of in-process concurrency. Distributed concurrency is a different matter.

tuyiown 5y ago

The hard part is to improve perceived performance or resource overhead for general software, where each task outcome is tightly coupled with app state, eg. a parallelize a slow task on button click and have guarantee that final state is coherent. Nothing out of reach, but doing that without compromising too much on maintainability is still an opened question.